ReactNative, Xamarin, PhoneGap, and Qt architectures. Part 2

We continue the analysis of the architecture of mobile cross-platform tools. Today, Xamarin and Qt frameworks are on the agenda. Recall that in the first part we covered the general architectural patterns of cross-platform frameworks, as well as the architecture of PhoneGap and ReactNative.

This article is an abbreviated version of the manual, available at the end of the link.

I give the floor to Vyacheslav Chernikov.

Qt

Qt is one of the oldest cross-platform frameworks and is used very widely for developing embedded and desktop applications. The Qt architecture allows you to port it to those operating systems that have an API for C ++. Both iOS, and Android (NDK), and Windows have this feature, although all with their own features.

One of the main advantages of Qt is its own efficient user interface rendering system either on the basis of a raster engine (for example, CoreGraphics on iOS) or on the basis of Open GL (ES). This is what makes the framework portable. That is, Qt uses its own UI rendering mechanisms - the application will look native as much as you stylize it.

As you can see, iOS uses standard CoreGraphics and UIKit modules for drawing the user interface. In Android, the situation is a bit more complicated, since Qt uses the NDK mechanisms to draw the UI, and the JNI bridge already known to us is used to access the Java API and control the application. Also in iOS and Android, Open GL ES can be used to render QML or work with 3D.

On Windows, there is direct access to the C ++ API and everything would work fine if it were not for the need to use Open GL ES to convert calls to DirectX (raster rendering does not satisfy the performance, and Open GL ES does not exist in Windows UWP). This helps library ANGLE.

The Qt-based application interface is not native, but is only made similar to it by styling.

In general, Qt could be recommended as a thing in itself - only ready-made modules of the framework itself, plus platform-independent C ++ libraries. But in real projects it will be very difficult to use it - a non-native UI, there are no third-party components (just out-of-the-box libraries), difficulties in building and debugging the application, as well as accessing native functionality. Of the benefits - high performance code in C ++.

')
So, Qt can be recommended for developing applications for iOS, Android and Windows UWP only if you already have extensive experience with Qt and an understanding of complex system mechanisms. It should be borne in mind that the interface in any case can only be similar to the native one.

Xamarin

Xamarin is now available in open source and has emerged as a development project for Mono, an open implementation of the .NET infrastructure for Unix systems. Mono was initially supported by Novell and allowed to run .NET applications on Linux and other open source operating systems.

Mono uses the P / Invoke mechanism to interact with native (for C) interfaces of operating systems. MonoTouch and MonoDroid frameworks were created based on Mono, which were then renamed Xamarin.iOS and Xamarin.Android, and are now collectively referred to as “classic Xamarin” (Xamarin Classic).

Classic Xamarin provides full access to native APIs, that is, you can create native iOS / Android applications using C # without a single line in Objective C and Java. Native libraries are connected through the Native Library Binding mechanism. The interaction with the OS occurs through the bridge and the wrappers mechanism; however, there is no need to serialize data, since automatic marshaling is performed and there is the possibility of direct transfer of links between Mono Managed and Native environments. You can also use a large number of .NET libraries from NuGet.

The .NET / Mono infrastructure assumes the use of JIT by analogy with Java, when an application is packaged into intermediate bytecode and then compiled later during execution. But due to the limitations of iOS, it is not possible to use JIT, and therefore the byte-code of Xamarin.iOS applications is compiled into native binary and statically linked with the libraries. This compilation is called AOT (Ahead Of Time) and is mandatory in Xamarin.iOS. In Xamarin.Android, in addition to AOT, JIT mode is also available, when the Mono virtual environment runs in parallel with Dalvik / ART.

As you can see, the common code base between platforms is limited to business logic and data handling mechanisms. Unfortunately, the UI and platform functionality have to be implemented separately for each platform. As a result, no more than 30% -40% of the total code base of mobile applications can be fumbled. To achieve a better result, you need to use Xamarin.Forms, which we will discuss in Chapter 3.5 .

The key advantage of classic Xamarin is the use of the C # language for all the code and, as a result, developers who are already familiar with .NET. Also essential is a good knowledge and understanding of iOS / Android mechanisms, their class models, architectures, object life cycles, and ability to read examples in Objective-C and Java.

The performance of the C # code is comparable to the performance of native code in iOS / Android, but when interacting with the OS, a bridge is used, which can slow down the application if used inefficiently.

Classic Xamarin is a fairly mature solution and provides the most close to native development experience for C # programmers and using familiar tools like Visual Studio.

So, if the task is to implement a fully native application and at the same time there are experienced C # -developers, then Xamarin can be a good choice for a wide range of tasks, both large (more than 40 screens) and small (up to 10 screens).

Xamarin.Forms

If your goal is to maximize the overall code base, then classic Xamarin here clearly loses to all other frameworks (PhoneGap, ReactNative, Qt and their counterparts). This was understood in Xamarin itself, so they released a solution that allows using a single description of the UI and simple mechanisms for accessing platform features - Xamarin.Forms.

The Xamarin.Forms library runs on top of the previously described classic Xamarin and in fact provides user interface virtualization mechanisms and additional infrastructure.

In order to better understand how XF works, let's consider a simple button. One of the basic mechanisms are renderers, due to which, when displaying the Xamarin.Forms button, the native control is actually added to the screen, and the properties of the XF button are dynamically thrown into the properties of the native button on each platform. ReactNative uses similar mechanisms.

The shared part on Xamarin.Forms is usually implemented as a library (Portable / PCL or .NET Standard) and has access to the component base in NuGet. The platform part is implemented on the basis of Xamarin Classic and has full access to the native API, as well as the ability to connect third-party libraries. In this case, the total percentage of code between the platforms usually reaches 85%. You can also use Xamarin.Forms in Embedded mode to create separate screens and View inside applications on the classic Xamarin.iOS and Xamarin.Android.

So, Xamarin.Forms can be recommended for the rapid development of prototypes in C #, but Xamarin.Forms can also be used for corporate and business applications of any scale (80 or more screens). Appearance, performance and application behavior will be completely native, but you should not forget about the effective interaction with the operating system through the bridge.

Conclusion

In our article, we reviewed the features of popular mobile frameworks in terms of architecture. Cross-platform applications themselves are very fast and comparable to native ones, but the need to use the bridge slows down a bit when interacting with native APIs.

General conclusion : in all popular cross-platform frameworks, a bridge is used, which reduces the speed of interaction with the native part. Bottlenecks (specific to each framework) should be optimized when creating the user interface. The final choice of the framework will depend on the competences available in the team and the requirements for the final result.

When choosing a framework, you should take into account not only the programming language, but also the necessary level of knowledge of the target operating systems (iOS, Android, Windows), and also draw on the experience of your development team. For example, when using PhoneGap, you can get away with superficial knowledge of the OS if you do not need to manually implement the platform functionality. And for Xamarin Classic you will have to become an expert in iOS and / or Android.

As a result, let's collect all the recommendations on the choice of frameworks in one place:

• PhoneGap - if you need to quickly make a simple application or a prototype and the team has experience developing single-page web applications (HTML, JavaScript, CSS). In most cases, you can get by with ready-made plugins for native functionality. Of the minuses - non-native interface with frequent twitching and sticking and difficult access to the native part. The percentage of shared code - up to 95%.
• ReactNative is great for experienced JavaScript developers and teams, but will require fairly good knowledge of the iOS Objective C API and Android Java API. Applications look and work natively, but you should also take into account the youth of the framework. The percentage of shared code - up to 90%.
• Xamarin Classic - if you have experienced C # developers, they will need to deeply master iOS and Android. Applications will be completely native, although written in C #. The total code base in rare cases exceeds 40%.
• Xamarin.Forms - for experienced C # developers, especially with knowledge of XAML. For applications with a simple interface (standard controls or ready-made components), you will not need in-depth knowledge of iOS / Android / Windows. The percentage of shared code - up to 90%.
• Qt - this framework can be recommended only if you already have an existing application (for example, embedded) and need to run it on iOS / Android. High requirements for the qualifications of developers, difficult access to native functionality and non-native UI are noticeable disadvantages of the framework. The percentage of shared code can go up to 95%.

---

Ps I thank Roman Zdebsky and Ahmed Sheriev for valuable additions, as well as Elizaveta Shvets and Maria Gorelkina for their help with publishing.

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 .

Stay in touch and ask your questions in the comments!