Xamarin technology helps in creating multi-platform mobile applications. However, like any technology, it can help more or less. It all depends on how much we can use it in practice.
The most important factor when choosing Xamarin technology in the context of creating mobile applications is its maturity. At Leaware, we have built over one hundred mobile application projects using this technology. So far, we have not encountered the case that Xamarin prevented something in our projects.
As part of Xamarin technology, many approaches to application development are available. You can use it, among others, as facilitation to use the C# language, but also in the context of the full use of this technology 70 or 90 percent of the shared code.
Fuller use of Xamarin is usually manifested in the amount of shared code between platforms.
The basic approach in which we use only C# does not allow code sharing. However, even this approach in itself has many advantages over native application development for many platforms.
Here are the most important of them:
We do not need to have specialists who know all three programming languages - objective c, java, C#
We create applications using one tool, Xamarin Studio, or Visual Studio, depending on the needs.
The implementation of algorithms is the same on all platforms - thanks to this, it is easier and easier to manage application development.
The whole snag is that Xamarin technology gives a lot more than one programming language for creating cross-platform applications. The power of this technology lies in enabling code sharing between platforms. Imagine an app that connects via a web server to a server, downloads data from it, saves it to a local database, then generates unique QR codes based on this data, which are then displayed on the screen of your smartphone. Now imagine that when writing an application for iOS, Android, and Windows the following functionalities:
local database
webservice support
code generation logic
are common to all platforms. The unique thing is how we display this data on the smartphone screen.
Xamarin technology, which draws a handful of .NET, allows you to share code between platforms in several different ways. At Leaware, we use two methods. The first is the use of the MvvmCross framework, and the second is the increasingly popular Xamarin.Forms. Both approaches have their pros and cons. The most important is the correct choice of development method that should be tailored to the requirements of the application.
Xamarin Native and Xamarin.Forms
In the beginning, I will briefly introduce what Xamarin Native is and what Xamarin. Forms are.
Xamarin Native
Xamarin Native allows you to write so-called native applications, i.e., those intended for one specific platform, such as Android or iOS, except that you write these applications using C #, not Java, Kotlin, Objective-C, or Swift. You can write the entire application as a single project, but if we have to write apps for both platforms, then it is enough to create projects containing business logic and share them between both platforms. However, UI and platform-specific functions must be established separately in each platform project.
Xamarin.Forms
Xamarin.Forms were created to make application development more cross-platform, and you can share even more percent of code so that just writing the application takes less time. Theoretically, most of the code responsible for the logic and appearance of the application can be shared between all platform applications. Only more advanced controls or platform-specific functions must be created for each platform separately.
Comparison of both approaches to building mobile apps.
Code sharing
As I mentioned earlier, using the Xamarin environment, we can share most of the code. Using Xamarin Native or Xamarin.Forms, you can share parts of the application, such as business logic, database layer, and network layer. For Xamarin.Forms, you can additionally share the application UI.
Creating UI
In Xamarin Native, we create application views separately for each platform, so for Android, we create standard layouts, as if we were creating them in a native project. Creating a UI for iOS also looks the same as in the case of a native project, i.e., we create them using Xcode Interface Builder. In both cases, you can also use Android Designer or iOS Designer, respectively, which are built into Visual Studio.
In Xamarin.Forms, views are created in XAML, which is then converted by the environment into native controls suitable for each platform. However, not all view elements have their counterparts on the other platform (e.g., Segmented Control with iOS). Then libraries that contain such controls come to the rescue. Although, although there are a lot of them and there are more and more of them, we will not always find one that suits us. Then we can use Custom Renderers that allow you to add small stylistic changes (although in this case, it's better to use so-called effects), or create more sophisticated controls — besides, using Xamarin.Forms, we have the option of using the so-called Hot Reload, which is intended to refresh the view when we save it in Visual Studio, so you can quickly see changes in the UI, without having to recompile the entire application.
Platform functions
If we want to use in our application functionalities that are implemented in a different way on a given platform, such as access to a file system, camera, or location, etc., they must be handled appropriately on each platform separately. There are, of course, libraries and plugins, such as Xamarin. Essentials, which support most platform functions, but nevertheless, many of these functions need to be handled by themselves, such as notification support or integration with Facebook. There is a mechanism in Xamarin.Forms called DependencyService that allows you to use these functions from a shared project. In Xamarin Native, there is no such built-in mechanism, and to be able to use it, it is best to use ready-made libraries that add this mechanism to our application.
In which cases should you choose Xamarin Native and in which Xamarin.Forms?
If the application is to have sophisticated or suitably adapted views for a given platform, use many native functionalities that are not available for both platforms, or contain complex animations, I would recommend using Xamarin Native. However, if the application is not very complicated, we have a smaller budget, and we want to release the app quickly, then I would use Xamarin.Forms. Of course, you can use Xamarin.Forms to make a beautiful and large application, but in my opinion, it will take more time and will cost more than when we use Xamarin Native. It is also worth remembering that applications created in Xamarin.Forms take up more space and are slightly slower than those written natively.
Is it easy to start programming with Xamarin.Forms if you are an experienced Xamarin Native developer?
This is not a complicated process. First of all, you need to learn how to create views in XAML. If someone has ever dealt with the Windows Presentation Presentation or Universal Windows Platform, then there will be no significant problem in creating UI in Xamarin.Forms. Writing applications in Xamarin.Forms are different from what Xamarin Native allows. However, I used Xamarin with the MvvmCross framework for most projects, which will enable us to use mechanics such as DI (dependency injection), IoC (inversion of control) ) and much more, so some of the Forms techniques were much easier for me to learn. The only thing I had to learn so from the beginning were mechanics available only in Xamarin. Forms such as custom renderers, effects, etc., although they may seem complicated at first when you get to know them, they are not at all so terrible, but this is probably the case with learning every other thing.
Summary
It remains to ask the question, "is it worth it?" In my opinion, yes, although I would not recommend that you switch entirely to Xamarin.Forms because although both approaches have both their advantages and disadvantages, although because each application and the resources that we have at its disposal are different, it is worth knowing the different approaches that we can use and select them according to the needs of the application, client or own.
Top comments (0)