我想做的是用native创建所有View(UI部分),但共享逻辑代码(控制器模型).
在我发现的所有内容中,有3件事似乎相当不错：
1)C – >构建库文件使用c对于逻辑,我将能够在2个平台中使用.dll文件
2)Azure移动应用程序服务.是否有可能成为网络服务中的所有逻辑？问题是,如果我没有访问互联网,我的应用程序将无法使用,对吧？
3)我听到很多关于Facebook使用的React本地,但它似乎用于创建UI,但我更喜欢用原生的方式创建它.我可以只对逻辑做出反应吗？
解决方法
1. C.
你不仅可以拥有一个已编译的.dll,并希望它适用于iOS和Android.它们都必须在不同的体系结构中编译,并且必须是iOS上的静态库.
DropBox是这样做的,他们已经提供了很多笔记和示例代码,以及你可以使用的代码,所以你can take a look.
优点
•设置完成后非常简单
•没有额外的依赖,错误等层(如Xamarin / React Native)
缺点
•设置和使用它需要大量的额外工作：您需要设置其他编译步骤并为两个平台编写包装器.
•在尝试为两种不同的体系结构编译相同的代码时,您肯定会遇到一些其他挑战
Here’s a SO post on how to do it in detail…
2. Xamarin
在这种情况下,此选项似乎极端使用.您被迫使用C#并引入另一层依赖项和错误.你说你不想为UI使用其他语言,所以我不推荐它.
3.反应原生
现在这是一个可行的选择.您可以在JS中编写脚本,并在Android和iOS中使用本机代码.
Here’s an article on how to share code with code examples…
不幸的是,它使用React Native for UI,但你可以使用easily call React Native functions from native code.
使用它有很多不足之处,包括调用是异步的,因为它们是在另一个线程上执行的,所以你必须为返回某些东西的函数实现某种回调系统.
优点
•似乎易于设置和编写
缺点
•您必须为返回某些内容的每个函数实现本机回调
•使用它有很多文件描述的垮台：
•As events can be sent from anywhere,they can introduce
spaghetti-style dependencies into your project.• Events share namespace,which means that you may encounter some name
collisions. Collisions will not be detected statically,what makes
them hard to debug.• If you use several instances of the same React Native component and
you want to distinguish them from the perspective of your event,
you’ll likely need to introduce some kind of identifiers and pass them
along with events (you can use the native view’s reactTag as an
identifier).
结论
我想我会选择C,主要是因为一家大公司(DropBox)尝试过并成功实际使用它.你可以试试React Native作为一个实验,它会成为一个很好的研究案例！
