Xamarin Forms – To use or not to use

I came across Xamarin Forms soon after developing for Xamarin, it was an early version of Forms and was, let’s say, basic. Apart from very simple internal apps or prototypes it wasn’t much use and reminded me of other cross platform solutions…poor.

However as more releases were made it improved (its currently on Xamarin Forms 2.3.x) but when deciding with a client how to build something, and discussing all the options pure native, Xamarin or Xamarin Forms, I usually steered them away from Xamarin Forms.

I then started working for a client who had built one of their apps using it and ended up maintaining it. It was built with 100% XAML UI, something I wasn’t really familiar with but after some time became fairly proficient with, and in doing so learnt lots of new techniques, although as it wasn’t compiled I was caught out quite a few times by typos in XAML code and obscure exceptions being thrown.

We were then hired by a startup to build their iOS and Android apps, remit was rapid dev in both iOS & Android simultaneously, server was REST API based and it was customer facing and there were some early screen designs. If we could build the UI in Xamarin Forms I thought it was worth a try, so quickly set about prototyping some of the designs and Forms handled them well.

I carefully explained the downside to using Forms, for example there may be some compromise on UI, luckily I knew the UX/Designer very well and was sure we could work through most UI issues if and when they arose.

The customer in this case was Jobhawk, a recruitment service for the construction industry, both iOS and Android apps were available at launch, the initial build time for both apps was 3-4 months with a single developer.

The Build

UI

Although now fairly familiar with XAML (and can see the advantage of XAML with your UI being clearly defined in XML), I found trying to do everything in XAML took me longer as it wasn’t the way I was used to developing and this client was against the clock.  I could have gone either way but decided to stick with what I knew best, code, so the UI was built in C#, adding all the binding at the code level.

IOC

Autofac, for no other reason than I had used it before and therefore felt familiar with it.

AutoRest

After some persuading I managed to get the server dev to supply the swagger file to document the REST API, this was a bit fiddly and not well documented itself, but once it was done it could be used to generate the client library using AutoRest (there was no automated service for Netty they used). Once we had this process defined it was plain sailing, with any change made to REST API contracts resulting in a new swagger file being provided, and I had a 1 line script to run to re-generate the client.

Local Mock

As soon as we had AutoRest working we created a local mock implementation of the client generated by AutoRest which can be injected into the apps, each REST API call being used in the app returns a canned set of objects, that evolved into an in-memory data set to test editing of data. The mock was used for unit testing and developing the UI. It is so much easier developing a complicated UI if you can mock all the API calls and provide realistic test data and not rely on real REST api calls and test objects added on the actual server which may just be empty data or non functional end points until the server backend is completed.

Charles Proxy

If you invest in any bit of software, invest in Charles Proxy. Once you move onto the real REST api, Charles is invaluable in tracing all the REST requests and responses; allowing you to intercept and breakpoint api calls, along with injecting responses and Status code results etc.

PCL Project

Nearly all common code was added into the main PCL project. Including business logic, UI, services, providers, models, view models, caching, commands.

Common Project

Any code depending on build parameters requires a common Shared DLL project that will be built for the target platform (rather than PCL), it’s usually pretty lightweight compared to the PCL.

Caching

Simple caching of the REST calls was built around Akavache, storing json collections using key pairs. Some of the calls into the PCL were even pre-cached as they changed rarely.

Unit Tests

Unit tests were built with Moq against the Mock implementation of the client.

SVG’s

Although not a visual app there was a lot of iconography, particularly trades that appear throughout the app, building them for all screen resolutions, in different sizes depending on use for both platforms would be a huge pain, so decided to try the SVG route, something I hadn’t used since Symbian days, there was a library available Xamarin Forms Plugin Library that supported SVG’s, but it wasn’t kept up to date, so I did what others suggested on forums and rolled our own based on code found there and using NGraphics as the SVG parser. The project UI designer and I learnt a few things on the way to make this process smoother, like what not to export into the SVG, and even wrote an app that loaded all the SVG’s in the PCL into a ViewController to easily test them. All the actual SVG assets were added into the main PCL as EmbeddedResources. There were only a few assets that could not be supplied this way, apart from icons and splash screens of course, but also burger menu and tab icons.

Localisation

Client requested from day one that the app should be easy to localise, so a localisation project was added to the solution using a RESX file, which made it easy to maintain and added only a very small overhead in developing. Using a RESX XML file for all the language resource strings also meant the file could be given to translators directly to work with.

Xamarin Plugin’s and nugets

There are various Xamarin Plugins available that make developing cross platform much easier, always check if what you need isn’t already available as a plugin.

We used :-

Autorest – Generates REST client library for comms with server from YAML

Xam.Plugin.Connectivity – Data connectivity availability api

Akavache – Keypair caching using SQLLite.

Xam.Forms.CarouselView – Cool component for doing native like carousel view in forms.

Xam.Plugin.DeviceInfo – Information about the device app is running on, i.e. iOS version, phone, model etc

Xam.Plugins.Settings – Persistent local storage using key pair

Xam.Plugins.Messaging – Creating SMS’s using native built in UI.

Plugin.Share – Sharing links to various social media using platforms built in share menus.

Xamarin.Firebase.iOS.CloudMessaging – PNS using GCM for iOS

Xamarin.Firebase.Messaging – PNS using GCM for Android

Xamarin.FFImageLoading – Added after initial release for loading thumbnail images from remote URL’s in cells. Great performance, and much more reliable than built in alternatives.

But what is the compromise?

We did have to make some compromises. The designer asked for lists with cells with variable heights, that expanded and closed on tapping, I tried this, but just couldn’t get it to work nicely, especially on iOS, android was OK. So we compromised on opening a detailed view. The client was fine with this.

Pros/Cons?

Con’s

  • Bundle Size – The bundle sizes are much larger than native apps, but only an issue when downloading over data networks.
  • UI – Compromises will probably need to be made on UI, so an understanding UX, design and product teams are essential.

Pro’s

  • Single language
  • Single UI
  • Single IDE
  • Shared unit tests
  • Rapid development on both platforms simultaneously.

Summary

There is always a trade off. As mentioned before, the pitfalls of using Xamarin Forms are if your objective is to make one of the most beautiful apps in the AppStore with lots of custom animations & interactions, if so, then Forms is not for you, stick with pure Xamarin Native and develop the UI for each platform separately.

However if functionality and rapid development is your aim then consider Xamarin Forms –  get the product owner and designer on board and explain the trade offs, do what I did and prototype some of your key screens to show the customer and designer. If you find a key screen difficult, don’t rule it out yet, if 95% of the app is simple, but one screen needs to be custom, still consider building using Forms but build that screen natively with a custom renderer. For example I am currently building an app for another client where most of the screens are simple, but one screen is a map with lots of interactions. There is a map plugin in forms, but it is basic and simply enables pins on a map (fixed colour). For this new app the customer wants a very rich maps experience so we chose the map plug in carefully for each platform and then built custom renderers, giving a great native maps experience whilst still using and gaining all the advantages of Xamarin Forms.

Introduction – The road to Xamarin

My name Is Neil Pepper, I’m one of the two co-founders of elementfortynine Ltd and I’ve been a developer for over 20 years and a mobile apps developer for over 15 years. Yes, 15, way before iOS and Android, in the early days developing mobile apps for Windows CE, then onto Symbian S60/UIQ, Brew and some proprietary platforms for manufacturers all in C++.

In those days I was working for a company called ShoZu – it was the world’s first photo sharing service and was installed on about 2 million phones, pretty good for a time with no AppStores. As all these platforms shared a common language it was possible to write cross platform code, sharing much of the business logic, data layer etc, and then building the UI layer natively (sound familiar?). Then the revolution came and these platforms were swept away and I moved onto iOS using Objective-C. We ported the ShoZu UI to UIKIt/Objective-C, while reusing all the C++ cross platform bits,  ShoZu was one of the first apps into the AppStore (for a whole 10 mins after AppStore was launched we were at the top of the best sellers list!)

After ShoZu’s sad demise, I moved onto developing pure Objective-C iOS apps for about 5 years and submitted multiple apps to the AppStore, but I never felt 100% comfortable with Objective-C. I didn’t find it a particularly elegant language, it wasn’t shared with any other platforms other than Apple ones. I also really missed C++ but still wanted to develop mobile apps. I had dabbled with cross platform tools, most were appalling, but had used Corona to develop some games for children and liked its simplicity, it felt like how games were developed for the Spectrum or Commodore. Of course having never developed for these platforms in reality it was probably very different, but I liked the speed of development for 2 platforms but this was just a game, no native controls, it didn’t need to look like an iOS or Android app.

I was then (early 2013) asked by my client (a big UK retailer) to research cross platform solutions, I wrote a few PoC’s in a few of them to see what we could do, but none of them were much use, none of them felt like you were producing a native mobile app, there were always compromises and when you got stuck you got really stuck. It was during this research that I was introduced to Xamarin by Gareth Pym, a long time fellow developer (and subsequent co-founder of elementfortynine Ltd). I was very sceptical at first, having never been a fan of C# managed code, but after spending some time researching Xamarin and fewPoC’s later discovered it was a revolution, I could write shared business logic code and then just build the UI natively and in a single language and there is little or no compromise. WOW!

If you shop at Tesco using the Tesco Groceries app on your iPhone, iPad, Android phone or tablet, you are using a Xamarin app because of that journey.

Once my time at Tesco was over I decided I wanted to continue to develop using Xamarin and by that time Gareth Pym had also been working at Tesco for sometime too, so having known each other for a long time we decided in 2015 with the help of Xamarin to form our own mobile consultancy specialising in helping companies build Xamarin based cross platform mobile apps.