Processware, as we explained in this post, has elected Xamarin as its platform of choice for cross-platform mobile apps development. As so, we would like to share with you some of the lessons learned through our journey using this new technology.
Xamarin was founded in 2011, and in 2016 Microsoft announced its acquisition. Microsoft played hard: they included Xamarin into Visual Studio (including the free edition) and they open sourced it.
One of the most appealing characteristics of using Xamarin is that regular .NET developers don’t need to step out of Visual Studio, and they benefit from all the goodies provided by the C# language like LINQ, async/await, XAML, strong types and garbage collection, just to name a few, almost removing the learning curve of targeting completely different devices (Android/iOS versus Windows Servers).
With this favorable scenario and strong technological trend, Processware decided to migrate its Mobile App, developed in C# for Windows Mobile, to Xamarin Forms platform. In this journey, we learn a lot about this new technology, so we would like to share with you what to-do and not to-do with Xamarin.
Project Types
When you start developing with Xamarin, during the project creation stage, you will need to decide what kind of project will be used: PCL (Portable Class Library) or SAP (Shared Asset Project).
The SAP project shares code across the specific platform projects at compilation-time, and when there is a need to use a platform-specific API some runtime errors can occur since the IDE doesn’t block the access to these APIs. Therefore the team (developers and testers) need to be extremely careful during the tests.
On the other hand, the PCL project will generate a DLL referenced between the platform-specific projects, containing business rules and everything that is common to all platforms (including the screens), leaving the maintenance and development of the App easier and safer because it’s not possible to directly access a specific platform API.
So, our advice is to try to create the screens just with PCL components because when we use them you will know that these components exist, they are available and they’ll have similar behaviors across all platforms, avoiding duplicated code and exhaustive testing for each platform.
Standard Components
Xamarin comes with a lot of standard components that prevent developers to start everything from scratch. The good thing is: we can customize these components. But we need to pay attention with these customizations of standard PCL components because any change must be very well tested on ALL platforms, generating a huge amount of tests, increasing the development cycle of the App.
Platform-specific components
Whenever you need to use a component that isn’t available as a Standard Component, you are free to create a platform-specific component.
But “with great power comes great responsibility”: The use of platform-specific components can be dangerous because these may not be available or may not even exist on other platform(s), thus generating a divergent App behavior.
Sometimes some specific platform development may be necessary, and in this case we should avoid introducing business rules into those components because we’ll need to replicate them to each platform generating duplicate code and a maintenance nightmare.
MVVM
One of the interesting Xamarin Forms resources is the components binding using MVVM architecture. The separation of the business data from the display rules on the screen, facilitates the maintenance of both, avoiding exhaustive work of creating screens because the MVVM model leaves the code simpler, organized and short with separate responsibilities.
Device Features
Another challenge was the use of platform-specific APIs to access device hardware like GPS, camera, Bluetooth, etc. However, with PCL project and dependency injection, and by using DependencyService (provided by Xamarin) we get access to these APIs in a safe way without taking the risk of causing a runtime error. Once it has been implemented in the platform-specific projects, and, using an interface, the code is directed to platform-specific implementation.
Deployment
One of the hurdles of developing mobile apps, especially for Android and iOS, is the deployment during the test phase. Everybody knows that, for production, you should rely on App Store or Google Play, but what about the frequent deployments during the tests? The answer is HockeyApp.
HockeyApp is integrated into the Visual Studio environment, and lets you control the App distribution as well as version control, usage statistics and mainly crash reports with stack trace, that helps us a lot with debugging and patching.
Summarizing all this, here’s a short list with the dos and don'ts when using Xamarin Forms:
Dos
- Use PCL (Portable Class Library) project type
- Use native components whenever possible
- Use MVVM design pattern
Don’ts
- Avoid using SAP (Shared Asset Project) project
- Avoid customizing standard components
- Avoid developing platform-specific components, whenever possible
- Avoid developing business rules in platform-specific projects
Summary
Xamarin is a great platform, where you can do rapid prototyping and development, targeting multiple devices/OSs, with native performance, using a single shared codebase which reduces the development and maintenance costs.
According to our experience, following these suggestions will make your life much easier when using Xamarin platform for mobile App development.
