预热篇- 总结Delphi Xe4 做App的的可行性分析. ios平台的问题还需要自行学习

首先澄清一个问题, 很多同学其实是误会了, 以为只要搞定了Delphi 就能很快写快餐程序了.  ios 本身的知识还是需要一些的, 并没有什么捷径可以走. 但如果一个团队有分工协作的话, DelphiXe4 也可以考虑作为一种技术方向.  用对了地方, 就可以发挥Delphi的长项了. 数据库程序和应用应该是不成问题的. 数据处理什么的. 毕竟有很多高质量的组件. 只要是平台无关的, 都会很容易在多个平台上得到支持. Mac上应用市场还是挺大的.  得找对了方向. 或者说需求. 

虽然对Andriod的支持目前还没有, Free Pasacal 的方案已经有了. 鉴于我还没有实际折腾过 Andriod 就不做评论了,  只记录一下自己的期待.

既然同时支持 Andriod 和 iOS 甚至于其它设备. 就要想办法弥补Native UI的裂痕. 以及UI Style . 如果不能完全统一成一个中间层, 比如FMX . 那就只能 M V C分离了, 对应平台去设计窗体样式等, 逻辑代码是一份.   其实Xe2的方式已经支持andriod ios 了. Xe4换了个方案, 走编译器底层.  我觉得这是一种意识, 毕竟如果100%依靠Xcode工作的话, 只有pascal语法有价值了. Delphi Ide 以及组件资源优势都没办法发挥.  当然, 现在也不是100% 所见即所得的, 越多的使用 原生的接口 ,越多的依赖于iOS 本身. 距离跨平台就越远. 举个例子：同样是http操作, 用 idHttp 就是跨平台的, 以后会支持andriod的. 而用 ios 自带的 NSURL 什么的 就不行了.  Xe4 有个概念是  PropertyAcess ,现在看概念的意思多一些. 

真的用起来,你会发现如果想发挥长处,就不可避免的会深度耦合于某个平台. 毕竟不是所有的功能都可以实现. Apple 又不允许使用私有Api.

通过IDE设定的方式的确 可以节省很多代码的编写, 而加载和释放也无需操心过多 . 要是objective c 还得熟悉整个流程, 还要为delegate的函数编写代码. 自己加载图片什么的. 

这些在delphi里还是老路子, 拖拽就ok. 

说到UI了,其实现在连FMX自己的很多细节也都不够IOS, 比如 没有轮菊花, 耗时一点的, 用户都不知道干啥呢. 

还有UI定制的功能, 比如重设界面的背景图, tableview的cell的样式什么的 我还在摸索中.  

Delphixe4开发App是一点问题都没有. 就是看功能了. 就是看能做什么就做什么.别想着不着边的事. 

说到这里, 我现在发现其实 游戏是最容易达到跨平台的. 游戏UI部分肯定是平台无关的. 所以只要拿到系统的 opengles的接口, 剩下的就顺理成章了.

但游戏最终也是个软件产品, 所以要整合平台的功能, 广告啥的,还是需要平台的知识的. 

最后的就是一句话: 该delphi的事 就是提高开发效率, 组件优势明显, 减少非核心代码.   该是ios andriod的事, 还得去学习去解决, 甚至多了一层ios 到 delphi的事.

做游戏的话,也有一些选择, zengl, asyphre hge(pascal) 但想不出来有什么优势. 现在各种engine framework 都很多. js 的 vb的 c++的   as 的.  所以不用太担心跨平台的事, 更应该专注于游戏产品本身. 不如就中规中矩的用 cocos2d-x /iphone , 或者学学Unity3d 做画面更亮的.  但归根到底你会发现， 游戏的结构啊, 数据管理, 乃至公式什么的, 都是一样一样的.  跟上面那些引擎啥的一点关系也没有.  做游戏的确是个很挑战的事.