Cross-platform mobile development practice (I)-overall architecture and technical route

After two months of work, we have been doing one thing, that is, migrating our current products to mainstream mobile platforms. In fact, the demand is very simple, that is, to make existing products have an end on various major mobile platforms, so that customers can work on their own. This demand is also a general demand for popularization, so I have studied it in depth as a topic with great interest. I made a decent product and covered iOS, andriod, WebOS, chrome, and Windows Phone (still under development ), basically, I have explored the path of cross-platform mobile development. In the past few days, I have summarized my experiences and gains over the past two months as a blog.

There is a big difference between the development of the mobile platform and the server. Currently, there is no solution to cross-platform problems on the server as in Java, however, this cross-platform is more demanding than the server. Currently, the most popular platforms are iOS, Android, and WP, which are evenly matched, as a result, mobile products must cover at least these three platforms. In addition, the traditional B/s advantage is not obvious on the Mobile End, and C/S is still the mainstream on the mobile end, which will inevitably cause heavy workload on mobile developers, java, C #, objective-C, C ++ ......, not everyone has done this across so many technical routes. Now it seems that the more reliable cross-platform development language is JavaScript, and only this language is originally supported by all platforms. As a result, JavaScript has not been popular in recent years. There are also various JavaScript-based cross-platform solutions on the market. The combination of phonegap and HTML5 is a mature and feasible solution. In the past two months, I have achieved products that can cover several platforms based on this overall route.

However, phonegap + HTML5 is not omnipotent, and not all types of products are suitable. Through their own practical experience, only those products with poor interactivity are suitable for adopting such technical routes. The key issue is that it is not directly available without native. In order to achieve high performance loss caused by cross-product platforms, it is impossible to make highly interactive and efficient applications. Therefore, do not expect to use it to develop amazing games. Companies that develop mobile web games based on HTML5, such as ucweb, cannot make too many things than native games. However, it is okay to use it to develop some information applications or products that are transplanted from enterprise to mobile terminals. Therefore, the technical architecture and route discussed here are also based on this premise. If it is to develop game products, it should be another scene.

A lot of nonsense. Let's take a look at how to start cross-platform mobile development.

Regardless of product design and requirement analysis, as far as development is concerned, two problems must be solved. One is the establishment of the Development Platform. The second is to solve major technical barriers.

Development Platform Construction:

• IOS: Mac + Xcode
• Android: Eclipse + Android SDK
• WP:. net studio
• WebOS: Eclipse + WebOS SDK + VirtualBox
• Chrome: Chrome Developer Tools
• HTML5: editing and debugger for various platforms

Major technical barriers and solutions:

• UI: JQuery Mobile and other UI Components
• Native: Support for HTML5 by Phonegap + platforms
• Server-side Data Communication: Jetty (HTTP) + Netty (Websocket)
• Mobile Data Communication: Ajax (client-to-Server Request) + Websocket (server-to-client push)
• Mobile storage: HTML5 (Localstorge) + File System Access
• Integration with other mobile products
• Product Packaging and project structure on each platform
• Security
• Efficiency

After the above problems are verified, we can probably determine whether this path works. I will also describe the details based on the above content, this is the basis for future technical selection. After all, not everyone has two months to select the technology.