Miaoshen Talk: The era of cross-platform development has arrived (again)

[[135054]]

This article mainly wants to talk about the recent cross-platform trend of mobile development, and focus on introducing and comparing things like Xamarin, NativeScript and React Native. There will not be a particularly in-depth technical discussion, you can treat it as a popular science article.

The beginning of the story

"Code once, run everywhere" is always the ideal of programmers. Twenty years ago, Java came on the stage with this banner and defeated many competitors. But today, the facts have proved that Java's bulky size and slow development are obviously difficult to keep up with the fast pace of this era. In the new era of mobile, if an application wants to win, the best user experience can be said to be indispensable. Using native methods is certainly helpful to improve user experience, but the current situation of mobile is that it must be developed for different platforms (at least iOS and Android). This is definitely a hidden danger and an additional burden for development: we not only need to work hard to synchronize the same code in different languages ​​between different projects, but also bear the subsequent maintenance tasks brought about by this. If it is limited to iOS and Android, it is fine, but if it continues to expand to platforms such as Windows Phone, the cost and number of people will increase exponentially, which is obviously unacceptable. Therefore, a concept that has been mentioned intermittently but has never dominated has once again entered the vision of mobile developers, that is, cross-platform development.

Local HTML and JavaScript

Because every platform has a browser and a WebView control, we can use HTML, CSS, and JavaScript to move web content and experience to the local platform. By doing this, we can unify the logic and UI rendering parts to reduce development and maintenance costs. Apps developed in this way are generally called Hybrid apps, and solutions like PhoneGap or Cordova are typical applications. In addition to using a set of front-end development techniques to build pages and interactions, this type of framework generally provides some interfaces for accessing devices, such as cameras and GPS.

Although the use of full web development strategy and environment can bring convenience to code maintenance, this method has fatal weaknesses, that is, slow rendering speed and difficult-to-control animation effects. Both are fatal and unacceptable to user experience. With the landmark event of Facebook using native code to rebuild Facebook's mobile app three years ago, the development of web shell apps, which once occupied half of the market, has gradually declined. Especially now that the pursuit of user experience is almost harsh, rigid animation effects and stiff interactive experience can no longer meet the people's psychological expectations for high-quality apps.

What should we do if we still want to cross platforms?

To solve the user experience problem, you basically need to go back to native development, but this behavior is bound to 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 (just right). One of the things is to automatically convert the code of a certain platform to another platform. There is a small British company doing this. MyAppConverter wants to automatically convert iOS code into Java. But unfortunately, if you have tried it, you will know that their product is not yet practical.

At the other fork of the road, there is a company that has gone further. It is called Apportable. They have achieved great results in game conversion. Major games such as Kingdom Rush or Mega Run have used this company's service to convert games from iOS to Android, and they are very successful. It is no exaggeration to say that Apportable is another attractive game cross-platform solution besides directly using 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 fact, you will not encounter difficult C++ in game development).

But the good news ends with game development, because the experience of games on different platforms will not be very different, and they rarely use the different features of different platforms, so it is relatively easy to handle. When we want to develop a non-game app, things are much more complicated. Although Apportable has a plan to make app conversion feasible, it will probably take some time before we see its launch.

New hope

In fact, the biggest problem of cross-platform development is the differences in UI and experience on different platforms. If you ignore this most difficult problem and just share the code for the logic part, the problem will be much simpler. More than ten years ago, when .NET was just announced and everyone was looking forward to the development of the new era, a group of hackers who liked to tinker were thinking about how to move .NET and C# to Linux. And this is the origin of Mono. Mono runs .NET intermediate code by implementing the Common Language Runtime on other platforms with the same functions as the Windows platform. Now the Mono community is strong enough and supports not only the Linux platform, but also mobile devices. Xamarin, the supporting company behind Mono, also launched a complete set of mobile cross-platform solutions in a timely manner.

Xamarin's idea is relatively simple, which is to use C# to complete the platform-independent app logic part that is common to all platforms; then, since the UI and interaction of each platform are different, use the C# API pre-packaged by Xamarin to access and manipulate native controls, and develop UIs for different platforms.

Although only the logic part is truly cross-platform, and the presentation layer needs to be developed separately, this is indeed a good way to take full care of the user experience - at least the development language is unified. Because of the pure C# environment in the Xamarin solution and the deep .NET technology background, this project is now supported and valued by Microsoft.

However, the fatal problem is that the APIs you can use for a specific platform are determined by Xamarin. That is to say, once the iOS or Android platform launches a new SDK and adds new features, you must wait for Xamarin engineers to package it before you can use it in your own project. This delay can often be fatal, because now the AppStore's homepage recommendation for new features is often only one or two weeks after the new system is launched. If you miss this period, your app may never be able to make a comeback. And if you want to use some third-party frameworks, you will have to package them into binaries yourself and write bindings to provide C# encapsulation for them, unless someone else has already done this for you.

In addition, because the UI part is still independent, different code bases still exist in the project, which is of limited help in reducing the workload, and there are still hidden dangers of synchronization and version differences in subsequent maintenance. But overall, Xamarin is a very good solution to cross-platform development. (If you put aside the price factor)

#p#

NativeScript

NativeScript is a project just announced by a little-known Bulgarian company called Telerik. Although Telerik is not very well-known, it has been on the road of hybrid app and cross-platform development for a long time.

JavaScript has a tendency to dominate the world because of its broad mass base and easy-to-learn and easy-to-use language features. Now mainstream mobile platforms also have strong JavaScript processing capabilities (JavaScriptCore after iOS 7 and V8 JavaScript Engine that comes with Android), so using JavaScript to cross-platform has become a natural option.

I want to complain here that JavaScript is really a language saved by a company and a project. Before V8, who could have thought that JavaScript would be what it is today...

The idea of ​​NativeScript is to use the JavaScript engine of the mobile platform for cross-platform development. The logic part is self-explanatory, the key is how to use the platform features, how can JavaScript call native things. The answer given by NativeScript is to obtain all platform APIs through reflection, precompile them, and then inject these APIs into the JavaScript runtime environment, then intercept the call after the Javascript call and run the native code.

I am not going to elaborate on the detailed principles of NativeScript here. If you are interested in it, you may want to take a look at this blog written by Telerik employees and the Keynote at the time of the release.

The biggest advantage of doing this is that you can use the latest platform APIs and various third-party libraries at will. Through reflection and injection of metadata, the NativeScript JavaScript runtime environment can always find them, trigger corresponding calls, and finally access the iOS or Android platform code. The latest version of the platform SDK or third-party library content can always be obtained and used without any restrictions.

For example, if you create a file for iOS development, you can write the following code directly in JavaScript:

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

The corresponding Android version might be:

 new java.io.File( path );

You don't need to worry about the existence of things like NSFileManager or java.io, you can use them freely!

If it is just like this, it is still very inconvenient to use. NativeScript uses a package management system similar to node to use modules to uniformly encapsulate the codes of these different platforms. For example, the above code can be uniformly replaced with the following form:

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

Those who have written node must be familiar with this format. The file-system here is the unified platform encapsulation of NativeScript. The complete list of current encapsulations can be found in this repo. Because the writing method is simple, developers can also create their own encapsulations if necessary, and even use npm to publish and share (of course, they can also obtain encapsulations written by others). Because it relies on an existing mature package management system, it can be considered that scalability is guaranteed.

For UI processing, NativeScript chose to use an XML method similar to Android for layout, and then use CSS to control the style of the controls. This is an interesting idea. Although the UI layout flexibility cannot be compared with the native layout for different platforms, it is actually very close to the traditional Android layout. An example of a layout file can illustrate this:

 <Page loaded= "onPageLoaded" >
 <GridLayout rows= "auto, *" >
 <StackLayout orientation= "horizontal" row= "0" >
 <TextField width= "200" text= "{{ task }}" hint= "Enter a task" id= "task" />
 <Button text= "Add" tap= "add" ></Button>
 </StackLayout> 
 
 <ListView items= "{{ tasks }}" row= "1" >
 <ListView.itemTemplate>
 <Label text= "{{ name }}" />
 </ListView.itemTemplate>
 </ListView>
 </GridLayout>
 </Page>

Readers who are familiar with Android or Window Phone development may feel that they have found organization. You may have noticed that compared to Android's layout method, NativeScript naturally supports MVVM and data binding, which is very convenient in development (but the performance is unknown for the time being). Controls such as Button or ListView are mapped to the system standard controls of the corresponding platform by modules. These controls are all styled using CSS, which is not much different from traditional web development.

nativescript-ui

The idea represented by NativeScript is to use a lot of web development skills for app development. This is a direction worth looking forward to, and I believe it will be welcomed by many front-end developers--because the tool chain and language are very familiar. However, the biggest challenge facing this direction is still UI. Now it seems that developers are limited to pre-defined UI controls, and cannot use HTML5 elements like traditional Hybrid apps. This makes it a problem to develop highly customized UI and interaction. Another possible problem is the size of the final app. Because we need to inject the entire metadata into the runtime environment, and there are also many compilations in different languages, it is inevitable that the app size will be larger. The first challenge is that for projects like apps, without the help of type checking and compilers, it will be more difficult to develop. In addition, there may be problems during debugging that have never been encountered in traditional app development.

Overall, NativeScript is a promising solution. If it can realize its vision, it will surely be a strong competitor in the cross-platform market. Of course, NativeScript is still too young and still has many problems. It might be a good idea to give this project more time and see how it performs after the official version is launched.

React Native

Facebook announced React Native a few months ago, and today the project was finally released amidst much anticipation.

React Native is similar to NativeScript in concept to some extent: both use JavaScript and native UI to implement apps (so JavaScript is really a mess.. If you don't know how to write a few sentences of JavaScript yet, it is recommended to learn it as soon as possible). However, their starting points are slightly different. React Native states on its homepage that using this library can:

 learn once, write anywhere

It is not "run anywhere". So the goal of React Native is not to be a cross-platform app development solution, but to be a tool that allows you to use similar methods and the same language to develop on different platforms. In addition, the main task of React Native is to build responsive Views. Its strength is that it determines the performance of Views according to the state of the application. It is relatively powerless for APIs of other system platforms. It is precisely because of these factors that React Native is not a good choice for cross-platform.

So why do we still talk about React Native in this article with the theme of "cross-platform"?

Because although Facebook did not start with cross-platform, it is impossible to stop engineers from using it in this way. In principle, React Native inherits the idea of ​​virtual DOM of React.js, but this time it becomes virtual View. In fact, this framework provides a set of native-implemented views (a series of classes starting with RCT on the iOS platform). When we write JavaScript (more precisely, for React Native, we write JavaScript with XML: JSX), we add and bind the virtual View to the registered module, and use the JavaScript runtime environment (JavaScriptCore for iOS) on the native side to compile and inject the JavaScript code, obtain its call to the UI, intercept it and bridge it to the native code to render the corresponding components. In terms of layout, it is still implemented through CSS.

The whole process and ideas here are similar to NativeScript, but the strategy adopted when bridging with native is completely opposite. React Native uses the native side as the rendering backend to provide a unified View entity required by the JavaScript side. NativeScript basically does the opposite, writing separate middle layers in JavaScript to correspond to different platforms.

For non-View processing, for iOS, React Native provides the RCTBridgeModule protocol, which we can implement on the native side to provide access in JavaScript. In addition, callbacks and event sending can also be done through the corresponding native code.

In summary, if you want to view React Native as a cross-platform solution (which is not the case), it is difficult to achieve it with JavaScript alone, because a meaningful app is unlikely to be completely independent of the platform API. But after all, Facebook is behind this project. If Facebook wants to establish itself through its influence, it will surely guide the direction of app development to its own level through continuous improvement and improvement of the tool chain. For developers who originally used React.js, this framework has lowered the threshold for them to enter app development. But for those who are already doing native app development, whether it is worthwhile and necessary to invest energy in learning it still needs to observe Facebook's next move.

But now that React Native has been officially released for less than 24 hours, I think we have plenty of time to think about and review such a framework.

Summarize

Of course, there are some other solutions, such as Titanium. There are not many cases of using cross-platform solutions to develop apps now, but cross-platform is always a temptation in terms of project management and maintenance. They all solve some legacy problems of Hybrid apps, but they all have some common shadows faced by non-native apps. Whoever can find a good way to solve problems such as custom UI, API scalability and app size will be able to take the lead or win in this market, thereby guiding the subsequent development trend.

But who knows who will win? It is also possible that everyone will fail again on the road to cross-platform. Waiting for the opportunity may be a good choice for developers now, but my suggestion is that it is always a good idea to learn some JavaScript in advance.