The cross-platform development era (again) coming?

This article mainly wants to talk about the recent wind of the mobile development cross-platform, and emphatically introduces and contrasts things like Xamarin,nativescript, React native and Deviceone. There will be no special in-depth technical discussion, you can see as a popular article.

The beginning of the story

"Once coded, running everywhere" is always the ideal township for programmers. 20 years ago, Java was the banner of this big flag, defeating many of its rivals. But to this day, it has been proved that Java's cumbersome size and slow development has clearly been difficult to seize the era of rapid pace of movement. In the new era of the movement of the tide, an application to win, the perfect experience can be said to be essential. While using native is a great way to improve the user experience, the move is a reality that must be developed for different platforms, at least IOS and Android. This is a hidden danger and an additional burden for development: not only do we need to work on different projects to synchronize the same code in different languages, but also to take on the subsequent maintenance tasks. If it's only limited to IOS and Android, but if you continue to expand to a platform such as Windows Phone, the cost and the number of jobs will grow at a geometric level, which is obviously unacceptable. So, a concept that has been said to be intermittent but never dominated has once again come into the vision of the mobile developers, that is, cross-platform development.

Local HTML and JavaScript

Because each platform has a browser and there are WebView controls, we can use HTML,CSS and JavaScript to move the content and experience of the web locally. By doing so, we can unify the logic and UI rendering parts to reduce development and maintenance costs. Apps developed in this way are commonly referred to as Hybrid apps, and solutions like PhoneGap or Cordova are typical applications. In addition to using a set of tips developed by the front-end to build pages and interactions, such frameworks typically provide access to the device's interfaces, such as cameras and GPS.

Although the use of Web-page development strategy and environment can bring code maintenance convenience, but this approach is a fatal weakness, that is slow rendering speed and difficult to control the animation effect. Both are deadly and unacceptable for the user experience. As the iconic event that Facebook used the native code to rebuild Facebook's mobile app three years ago, the app that once occupied half of the web's shell has been growing. Especially now, the pursuit of user experience is almost harsh, the dull animation effect and the blunt interactive experience have completely failed to meet the people's psychological expectations of high-quality apps.

What do we do when we're not going to die in a cross platform?

To solve the problem of user experience, basically still need to go back to native to develop, but this kind of behavior must be bound with the platform. There are always smart people in the world, and they always use computers that look smarter but are actually stupid to do stupid things. One thing is to automatically switch the code of one platform to another. A small British company is doing something like this, and the thing Myappconverter wants to do is to automatically turn IOS code into Java. But it's a pity that if you try, you know that their product is still in a state of no practical use.

On the other fork of the road there is a company that goes further, it's called apportable. They have made great achievements in the conversion of games, such as Kingdom Rush or Mega Run, which uses this service to convert games from IOS to Android and is very successful. It is no exaggeration to say that apportable is a cross-platform solution that uses an enticing set of games, except for direct use like Unity or cocos2d-x. Basically you can use OBJECTIVE-C or Swift to develop on a familiar platform without having to touch monsters like C + + (although in the game development you will not encounter difficult C + +).

But the good news ended up in game development, because the game is not very different on various platforms and rarely uses different features of different platforms, so it's relatively easy to handle. When we want to develop a non-gaming app, things are going to be a lot more complicated. Although Apportable has a plan to make the app transition feasible, it will take some time before we can see its launch.

New Hope Xamarin

In fact, the biggest problem of cross-platform development is the different platform UI and experience. If you ignore this most difficult problem, just share the logical part of the code, the problem is a lot easier. More than 10 years ago, when. NET was unveiled, and everyone was looking forward to the development of a new era, a group of Hacker were figuring out how to move. NET and C # to Linux. And this is the origin of mono. Mono runs. NET Intermediate code by implementing the same Common Language runtime on other platforms as the Windows platform. The Mono community is now strong enough to support not only the Linux platform, but also mobile devices. The support enterprise Xamarin behind Mono is also a logical and timely launch of a comprehensive set of mobile cross-platform solutions.

The idea of Xamarin is relatively simple: use C # to complete all platform-agnostic app logic parts, and then, because of the different UI and interactions of each platform, use the C # API, which is pre-packaged by Xamarin, to access and manipulate native controls, respectively, for UI development with the same platform.

Although only the logical part implements True cross-platform, and the presentation layer has to be developed separately, it is indeed a good way to take care of the user experience as a whole-at least the development language is unified. This project is now supported and valued by Microsoft because of the pure C # environment in the Xamarin solution and the deep support of the. NET technology background.

The fatal problem, however, is that the APIs you can use for a particular platform are determined by Xamarin. This means that once the IOS or Android platform launches the new SDK and adds new features, you have to wait for the Xamarin engineer to encapsulate it before it can be used in its own project. This delay can often be fatal, because now AppStore for the new features of the home page is often only a new system after the launch of a two-week, Miss this time, it may be your app will never roll over the day. And if you want to use some third-party frameworks, you'll have to pack them into binary, and write the binding to give them a C # package, unless someone else has done it for you.

In addition, because the UI part is still fighting each other, different code libraries are still present in the project, which has limited help in reducing the workload, and there is still the potential for synchronization and version differences in subsequent maintenance. But in general, Xamarin is a great way to solve cross-platform development. (If the price factor is thrown aside)

Nativescript

Nativescript is an obscure Bulgarian company named Telerik, just announced the project. Although Telerik is not very well known, it has been on the hybrid app and cross-platform development path for a long time.

JavaScript has a eminence trend because of its extensive mass base and easy-to-learn language features. And now the mainstream mobile platform has a strong ability to handle JavaScript (IOS 7 JavaScriptCore and Android's own V8 JavaScript Engine), because using JavaScript to cross platform naturally For an optional option.

Here to spit a notch, JavaScript is really a company, a project to save the language of the back. V8 before who can think of JavaScript can have today ...

Nativescript's idea is to use the JavaScript engine of the mobile platform for cross-platform development. The logical part is naturally needless to say, the key is how to use the platform features, JavaScript How to call native things. Nativescript's answer is to get all the platform APIs through reflection, precompile them, then inject them into the JavaScript runtime, then intercept the call after the JavaScript call and run the native code.

Here is not going to expand to say nativescript detailed principles, if you are interested in it, you may wish to see Telerik's staff wrote this blog and the release of Keynote.

The biggest benefit is that you can use the latest platform APIs as well as a variety of third-party libraries. By reflecting and injecting the metadata, the Nativescript JavaScript runtime always finds them, triggering the appropriate calls and finally accessing the platform code for IOS or Android. The latest version of the platform SDK or third-party library content can always be retrieved and used without restrictions.

For example, if you create a file that is developed for IOS, you can write code like this directly in JavaScript:

var fileManager = NSFileManager.defaultManager();  fileManager.createFileAtPathContentsAttributes( path );  

and the corresponding Android version might be:

new java.io.File( path );  

You don't need to worry NSFileManager or java.io exist for such things, but you can use them arbitrarily!

If only this is the case, it is very inconvenient to use. With a package management system like node, Nativescript uses modules to encapsulate the code of these different platforms in a unified package. The above code, for example, can be replaced with the following form of unification:

var fs = require( "file-system" );  var file = new fs.File( path ); 

The classmate who wrote node must be familiar with this form, here is the nativescript of the file-system Unified platform package. Now the complete list of packages can be found in this repo. Because it's simple to write, developers can create their own packages if they need to, and even use NPM to publish and share (and, of course, get a package that someone else writes). Because it relies on existing mature package management systems, scalability can be considered guaranteed.

For UI processing, Nativescript chose to layout using Android-like XML, and then used CSS to control the style of the control. This is an interesting idea, although the layout of the UI cannot be as flexible as the native layout for different platforms, but it's actually close to the traditional Android layout. An example of a layout file can be seen:

<PageLoaded="Onpageloaded" ><GridLayoutRows="Auto, *" ><Stacklayoutorientation="Horizontal"row="0" ><TextFieldWidth="200"text=' {{task}} 'Hint="Enter a Task"Id="Task"/><Buttontext="Add"tap="Add" ></button> </ stacklayout> <ListView items= "{{tasks}}" row=  "1" > <listview.itemtemplate> Span class= "Hljs-tag" ><label text=  "{{name}}"/> </ listview.itemtemplate> </listview> </gridlayout></ page>             

Readers familiar with Android or Window Phone Development may feel the organization is found. You may have noticed that nativescript is inherently supportive of MVVM and data binding compared to the way Android is laid out, which is very handy in development (but temporarily unknown in performance). A Button ListView control such as this is a system standard control that is mapped by modules to the corresponding platform. These controls use CSS to specify the style, which is not much different from the traditional web page development.

The Nativescript representative's idea is to use a lot of web development techniques to do app development. This is a very desirable direction, and I believe it will be welcomed by many front-end developers-because the toolchain and language are very familiar. But the biggest challenge still facing this direction is the UI, which now seems to be limited to pre-defined UI controls, rather than using HTML5 elements like traditional Hybrid apps. This makes it possible to develop a highly customized UI and interaction becomes a problem. Another possible problem is the size of the final app. Because we need to inject the entire metadata into the running environment and there are many compilations in different languages, it inevitably results in larger app sizes. The last challenge is that for projects like apps, without the help of type checking and compilers, it can be quite difficult to develop. In addition, during debugging, there may be problems that are not encountered in traditional app development.

Overall, Nativescript is a promising solution. If it can achieve its own vision, it will be a strong competitor of the big cake across the platform. Of course, Nativescript is still too young, and there are still many problems. Give this project a little time to look at the performance of the official version on-line.

React Native

Facebook released React Native a few months ago, and today the project is finally being released in anticipation.

React Native is somewhat similar to the concept of Nativescript: Using JavaScript and the Native UI to implement the app (so JavaScript really has a barrel of paste in the trend.) If you do not write a few JavaScript now, it is advisable to learn it as soon as possible. But their starting point is slightly different, React Native on the home page is written, using this library can:

Learn once, Write anywhere

And not "run anywhere." So the goal that React Native want to achieve is not a cross-platform app development solution, but a tool that allows you to use similar approaches and the same language to develop on different platforms. In addition, the main work of React Native is to construct a responsive view, which has the advantage of determining the view's performance state based on the state of the application. And for some other system platform API, it seems to be more weak. And precisely because of these factors, make React Native is really not a cross-platform good choice.

So why are we talking about React Native in this article on "Cross-platform" topics?

Because although Facebook is not a cross-platform, it's not going to stop engineers from trying to use it. In principle, React Native inherits the idea of React.js's virtual DOM, but this time it becomes a virtual View. In fact, this framework provides a set of native implemented view (a series of classes that begin on the IOS platform RCT ). We're writing JavaScript (more precisely, for React Native, we're writing a javascript:jsx with XML), by adding and binding the virtual View to the registered module, using JavaScript on the Native side of the environment (for IOS, which is JavaScriptCore), compile and inject good JavaScript code, get its call to the UI, intercept it, and bridge to the rendering of the corresponding part in the native code. But in the layout aspect, still is realizes through the CSS.

The whole process and ideas here are similar to the Nativescript, but the strategy is exactly the opposite of the native bridge. React Native is an entity that takes the Native side as a rendering backend to provide the View required by the unified JavaScript side. The basic nativescript of the daoxing is to write separate layers in JavaScript to correspond to different platforms.

For non-View processing, the protocol is provided for Ios,react Native RCTBridgeModule , and we can provide access to JavaScript by implementing this protocol on the Native side. In addition, the return harmonic event sending, etc. can also be done by the corresponding native code.

To summarize, if you want to see React Native as a cross-platform scenario (and it shouldn't), it's hard to do it on the JavaScript side, because a meaningful app is unlikely to be completely out of the way of the platform API. But after all, Facebook is behind the project, and if Facebook wants to be self-reliant on its own, it will certainly be guided by the evolution of the app and the way it is developed. For developers who used react.js, the framework lowered their entry threshold for app development. But for those who are already doing native app development, it is worthwhile and need to devote their energies to learning, as well as observing Facebook's next move.

But now that the official release of React Native has passed less than 24 hours, I think we have plenty of time to think and review such a framework.

Deviceone

Cup technology announced the deviceone about two months or so.

Deviceone a whole new paradigm: breaking all the previous patterns, implementing the entire native UI to implement the app. But their starting point is slightly different, deviceone on the home page is clear, using this platform can:

Write once, run anywhere

Instead of "Learn once, Write Anywhere". So the goal that Deviceone wants to achieve is a new cross-platform app development that allows you to use the same language to develop tools on different platforms. And for some other system platform API, it seems to be more weak. And precisely because of these factors, make deviceone really is a cross-platform good choice.

Summarize

Of course, there are some other programs, such as Titanium. There are not many cases of developing apps using cross-platform scenarios, but cross-platform is always a temptation, whether in project management or maintenance. They all address some of the legacy issues of Hybrid apps, but they all have some of the most common shades of non-native apps. Who can find a good way to solve problems like custom Ui,api extensibility and app size, who will be able to lead or win in this market, leading to the development trend after.

But who knows who will win the final? It is also possible for everyone to fail again on a cross-platform path. It may be a good choice for developers now, but my advice is to learn a little bit of JavaScript in advance and never make mistakes.

The cross-platform development era (again) coming?