October 18, 2017 at 10:09ReactNative, Xamarin, PhoneGap, and Qt architectures. Part 2
This article is an abridged version of the manual, available at the end of the link.
I pass 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 ++. And iOS, and Android (NDK), and Windows have such an opportunity, although all with their own characteristics.
One of the main advantages of Qt is its own effective system for rendering the user interface either based on a raster engine (for example, CoreGraphics in iOS) or based on 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 style it yourself.
As you can see, on iOS, standard CoreGraphics and UIKit modules are used to draw the user interface. In Android, the situation is a bit more complicated, since Qt uses the NDK mechanisms to draw the UI, and the familiar JNI bridge is used to access the Java API and manage the application. Also on iOS and Android, Open GL ES can be used to render QML or work with 3D.
Windows has direct access to the C ++ API and everything would work fine if it weren't for the need to convert calls from Open GL ES to DirectX calls (bitmap rendering is not satisfactory in performance, and Open GL ES is not in Windows UWP). The ANGLE library helps with this.
The interface of Qt-based applications is not native, but only becomes similar to it with the help of 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 (only libraries “out of the box”), difficulties arise when building and debugging the application, as well as when accessing native functionality. Of the pluses is the high performance of C ++ code.
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 in any case, the interface can only be similar to the native one.
Xamarin
Xamarin is now available in open source and has emerged as a development of the Mono project, an open implementation of the .NET infrastructure for Unix systems. Mono was originally supported by Novell and allowed you to run .NET applications on Linux and other open operating systems.
Mono uses the P / Invoke mechanism to interact with native (for C) operating system interfaces . Based on Mono, the MonoTouch and MonoDroid frameworks were created, which were then renamed to Xamarin.iOS and Xamarin.Android, and are now called the “classic Xamarin” (Xamarin Classic).
Classic Xamarin provides full access to the 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 via the Native Library Binding mechanism. Interaction with the OS occurs through the bridge and the wrappers mechanism, however, there is no need to serialize the 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, similar to Java, when an application is packaged in intermediate bytecode and only then compiled at runtime. But due to iOS limitations, it is not possible to use JIT, and therefore the bytecode of Xamarin.iOS applications is compiled into the native binary and is statically linked with the libraries. This compilation is called AOT (Ahead Of Time) and is required 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 by business logic and data processing mechanisms. Unfortunately, UI and platform functionality have to be implemented separately for each platform. As a result, you can fumble no more than 30% -40% of the total code base of mobile applications. To achieve a greater result, you must use Xamarin.Forms, which we will discuss in Chapter 3.5 .
A key advantage of classic Xamarin is the use of C # for all code and, as a result, developers who are already familiar with .NET. Also required is a good knowledge and understanding of the iOS / Android mechanisms, their class models, architectures, object life cycles and the 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 that can slow down the application if it is used inefficiently.
Classic Xamarin is a mature solution and provides the closest 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 the classic Xamarin here clearly loses to all other frameworks (PhoneGap, ReactNative, Qt and their analogues). This was also 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 classic Xamarin described earlier and actually provides user interface virtualization mechanisms and additional infrastructure.
In order to better understand how XF works, let's look at a simple button. One of the basic mechanisms is renderers, thanks to which when the Xamarin.Forms button is displayed, 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 database 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. Moreover, the total percentage of code between platforms usually reaches 85%. Also, Xamarin.Forms can be used 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 rapid prototype development in C #, however, Xamarin.Forms can also be used for corporate and business applications of any scale (80 or more screens). The appearance, performance and behavior of applications will be completely native, but do not forget about the effective interaction with the operating system through the bridge.
Conclusion
In our article, we examined the features of popular mobile frameworks in terms of architecture. Cross platform applications themselves are very fast and comparable to native ones, however, the need to use a bridge slows down a bit when interacting with native APIs.
The general conclusion : in all popular cross-platform frameworks, a bridge is used that 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 competencies available in the team and the requirements for the final result.
When choosing a framework, it is worth considering not only the programming language, but also the necessary level of knowledge of the target operating systems (iOS, Android, Windows), as well as drawing on the experience of your development team. For example, when using PhoneGap, you can do with superficial knowledge of the OS if you do not need to manually implement 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 for choosing frameworks in one place:
- PhoneGap - if you need to quickly make a simple application or prototype and the team has experience in developing single-page web applications (HTML, JavaScript, CSS). In most cases, you can do with ready-made plug-ins for native functionality. Of the minuses - a non-native interface with frequent twitching and sticking and difficult access to the native part. The percentage of shared code is up to 95%.
- ReactNative is great for experienced JavaScript developers and teams, but it requires a good knowledge of the iOS Objective-C API and Android Java API. Applications look and work natively, but you should also consider the youth of the framework. The percentage of shared code is up to 90%.
- Xamarin Classic - if you have experienced C # developers, then they will need to deeply master iOS and Android. Applications will be completely native, although written in C #. The volume of the general code base in rare cases exceeds 40%.
- Xamarin.Forms - Suitable 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 is up to 90%.
- Qt - this framework can be recommended only if you already have an existing application (for example, embedded) and you 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 express my gratitude to Roman Zdebsky and Akhmed Sheriev for valuable additions, as well as to Elizaveta Shvets and Maria Gorelkina for help with the publication.
You can find the full version of the guide on GitBook .
On October 31, Vyacheslav will also speak at our Mobile DevOps webinar for Xamarin developers, we will speed up testing and delivery . As always, participation is free.
We remind you that in the second part of the review we will focus on Xamarin and Qt, as well as general recommendations in choosing a framework. Stay in touch and ask your questions in the comments!
about the author
Vyacheslav Chernikov is the head of development at Binwell , Microsoft MVP, and Xamarin Certified Developer. In the past, one of Nokia Champion and Qt Certified Specialist, currently a specialist in Xamarin and Azure platforms. He entered the mobile sphere in 2005, and since 2008 he has been developing mobile applications: he started with Symbian, Maemo, Meego, Windows Mobile, then switched to iOS, Android and Windows Phone. You can also read Vyacheslav's articles on the Medium blog . Other articles by the author can be found in our #xamarincolumn column .
Stay in touch and ask your questions in the comments!