ReactNative, Xamarin, PhoneGap, and Qt architectures. Part 1
This article is an abbreviated version of the manual, available at the end of the link.
I give the floor to Vyacheslav Chernikov.
Introduction
Now there are a lot of frameworks themselves, but from an architectural point of view they are basically similar to PhoneGap, ReactNative and Xamarin, so we will focus on this top three. We added Qt to the review, since we are often asked about this by active Qt-developers or those who have worked with it and heard about support for iOS and Android.
As target platforms, we will focus on iOS, Android and Windows UWP.
Native and cross platform development tools
Historically, there has always been competition in the computer market, and each manufacturer has provided an optimal set of so-called “native” (native) tools for developing applications for their operating systems and devices. “Native” development tools provide optimal performance and access to operating system features.
However, it often turned out that these tools were incompatible with each other, not only at the level of the development language, agreements and architectures adopted, but also at the level of operating systems and libraries. As a result, in order to implement the same algorithms, user or business scenarios, it was required to write an application for several environments in different programming languages. For example, if you need to support 2 platforms, you need an increase in labor costs and teams 2 times. Plus 2 times more budgets for support and development. It can be added that in many companies a large base of code has already accumulated, which I would also like to inherit in new solutions.
The second important point is the presence of the necessary competencies (knowledge and experience) within the team - if they are not there, then it will take time to train.
In order to solve both of these problems, cross-platform development tools appeared on the market, offering:
- maximize the common code base in a single programming language to make the product easier to develop and maintain;
- use existing competencies and specialists to implement applications on new platforms.
Since there are a lot of programming languages ​​(and environments) now (and specialists who speak these languages), there are a fair amount of tools for cross-platform development. In this book, we are only interested in tools for creating mobile business applications, so in the following chapters we will take a closer look at how they work. In the meantime, a little more detailed each of the advantages of cross-platform development:
General code base. Depending on the selected tool, the developer will be able to fumble between the platforms: application resources (images, fonts and other files), data processing logic, business logic and interface description. And if with resources and logic (data processing and business) everything is quite simple, then you should be more careful with the interface, since each platform has its own recommendations and requirements.
Use existing competencies and teams. Here it is necessary to take into account not only the programming language, but also an understanding of the mechanisms of operation of the iOS / Android / Windows operating systems, as well as a set of additional libraries and development tools.
So, the “native” tools are provided by the ecosystem owners themselves and allow you to get the most out of the capabilities of the target operating system, have full access to native APIs, optimal performance and require a separate development team for each platform.
Cross-platform frameworks can reduce labor costs and speed up the release of applications in the event that support for multiple platforms is required at the same time, and the necessary competences are available (or developed). In the long term, cross-platform solutions will help to save a decent amount of man-hours, but for this you should take into account the features of the selected tool.
IOS / Android architecture and native APIs
The main principle underlying cross-platform solutions is to divide the code into 2 parts:
- cross-platform , living in a virtual environment and having limited access to the capabilities of the target platform through a special bridge;
- native , which provides application initialization, management of the life cycle of key objects and having full access to system APIs.
In order to connect the “native” world and the “cross-platform” world, it is necessary to use a special bridge . And as we will see in Chapter 3, it is the bridge that determines the capabilities and limitations of cross-platform frameworks.
Using bridge always affects performance by converting data between “worlds” as well as converting API calls and libraries. By itself, the “cross-platform” world has a comparable performance to “native”.
So, all cross-platform applications must have a native part, otherwise the operating system simply can not run them. And iOS, Android and Windows UWP themselves provide the necessary APIs for cross-platform frameworks:
- WebView is used in PhoneGap-based hybrid applications or analogs for launching applications and in fact serves as a web application runtime environment;
- JavaScript engines are used in ReactNative and analogs to quickly execute JS code and exchange data between Native and JS;
- OpenGL ES (or DirectX) is used in games and applications on Qt / QML or analogues to draw the interface;
- The UI subsystem is responsible for the native user interface of the application, which is important for ReactNative and Xamarin.
A more detailed description of these subsystems in various operating systems can be found in the full version of the manual at the link at the end of the article.
Cross-Platform Framework Architecture
All operating systems have certain technical capabilities for launching cross-platform applications. The simplest from a technical point of view is the use of WebView, which all operating systems have (relevant for PhoneGap). The second option is to use low-level mechanisms like OpenGL ES and C / C ++ language - this will allow to share most of the logic between projects (in games or Qt), but it will work limitedly (or not) on Windows UWP. If you need a fully native user interface and native performance with minimal overhead, then the system’s top-level APIs are used - this approach is implemented in Xamarin and ReactNative.
To better understand the capabilities and limitations of each of the frameworks, let's look at how they are designed architecturally and which of these features and limitations follow.
Phonegap
PhoneGap solutions use WebView and are fairly simple in terms of implementation - a small native application is created that actually simply displays the embedded web browser and single-page HTML. There are no native controls and direct access to the API - all interface elements inside the web page are simply styled as native ones. To access system functionality, special plugins are connected that add JS methods to the inside of a web browser and link them to the native implementation on each platform.
As you can see, PhoneGap allows you to share almost all the code between platforms, but implementation of the native part in Objective C and Java (and C # for Windows) is still required. The entire life of the application passes inside WebView, so web developers will feel like a fish in water. Until there is a need for platform functionality, a good understanding of iOS and Android will already be needed here.
Also PhoneGap (aka Apache Cordova) is used in the popular Ionic framework, which provides a large number of ready-made plugins for system functionality.
The interface of applications based on WebView is not native, but is only made similar to it using HTML / CSS styles.
Developing applications on PhoneGap requires HTML, JavaScript, CSS, and Objective-C, Java, and good engineering knowledge to integrate native and cross-platform parts. The user interface is organized on the principle of one-page HTML - in real applications with a complex interface there will be twitching and slowdowns (features of mobile WebView, which may also differ from different manufacturers). To transfer data across the bridge, they must be serialized / deserialized into Json. In general, the bridge is rarely used, since the entire life of the application passes inside the WebView.
To transfer complex data structures and classes between the native part and WebView, they must be serialized / deserialized in JSON format.
Finally, we note that PhoneGap is already a fairly mature solution with a large number of ready-made plug-ins.
So, PhoneGap can be recommended for the rapid development of simple applications (up to 15 screens) with a small user audience (for example, a solution within a company) or prototypes.
')
ReactNative
One of the interesting solutions in the field of cross-platform development of mobile applications is ReactNative, created in Facebook. This framework makes it possible to use JavaScript to describe the native interface and application logic. By itself, JS-engine provides performance comparable to native. However, one should not forget that there is a bridge in the ReactNative architecture, which reduces the speed of work with platform functionality and UI.
When creating applications on ReactNative, the developer will also need to implement the native part in Objective C, Java or C #, which initializes the JS engine and its JS code. Then the JS application takes control in its own hands and with the help of ReactNative begins to create native objects and manage them from JavaScript. It is worth adding that the ReactNative architecture allows updating the JS code without restarting the application (hot reloading). This allows updating the cross-platform part without the need to republish applications in the AppStore and Google Play. You can also use libraries from Npm and a large number of third-party plug-ins.
It is necessary to take into account that due to the limitations of iOS (there is no possibility to implement JIT), JavaScript code is interpreted on the fly and not compiled. In general, this does not greatly affect the performance in real applications, but it’s worth remembering.
To transfer complex data structures and classes between the native part and the JS engine, they must be serialized / deserialized in JSON format.
Creating applications on ReactNative requires JavaScript experience, as well as good knowledge of iOS and Android. The integration of native and cross-platform parts is easy to do according to official documentation. The user interface is completely native, but it has limitations and features when styling from JS code, which you will have to get used to. To transfer data across the bridge, they must be serialized / deserialized into Json. Plus, the bridge is used to manage native objects, which can also lead to a drop in performance when used inefficiently (for example, often changing the properties of native UI objects from a JS code during manual animations).
You should also take into account the youth of the framework - there are bottlenecks or errors that you learn about only during development. And almost always requires the implementation of the native part in Objective C and Java.
So, ReactNative can be recommended for rapid development of applications of medium complexity (up to 40 screens), the team should not only have experienced JS developers, but also good iOS (ObjC / Swift) and Android (Java / Kotlin) specialists.
You can find the full tutorial on GitBook .
October 31, Vyacheslav will also speak at our Mobile DevOps webinar for Xamarin developers, speed up testing and delivery . Participation as always free.
We remind you that in the second part of the review we will focus more on Xamarin and Qt, as well as general recommendations in the choice of framework. Stay in touch and ask your questions in the comments!
about the author
Vyacheslav Chernikov - head of development at Binwell , Microsoft MVP and Xamarin Certified Developer. In the past, he was one of the Nokia Champion and Qt Certified Specialists, currently he is the Xamarin and Azure platform specialist. He came to the sphere of mobile in 2005, since 2008 he has been developing mobile applications: he started with Symbian, Maemo, Meego, Windows Mobile, then switched to iOS, Android and Windows Phone. Articles Vyacheslav you can also read the blog on Medium .Other articles of the author can be found in our column #xamarincolumn .
UPD: The second part is here .
Source: https://habr.com/ru/post/340116/
All Articles