Introduction

When Cap started way back in 1979 as an alternative provider of vehicle valuations to the industry, information technology was in its infancy and the only valid way for customers to receive the data so vital to their company was through the printed medium. Cap was all about data and books.

Over the years, the access to technology has allowed many other data delivery methods to be provided and even though many of the larger fleet and finance companies began to receive their data exclusively by electronic means, the book has continued to be invaluable to 1000’s of loyal dealers. Until recently, it has been the only valid method of instantly valuing a vehicle on the multitude of dealer forecourts or windswept auction houses the length and breadth of the country.

But times change and the recent rise of the smartphone and data connectivity has provided an ideal opportunity to hold all this information (and more) in a device that is smaller than the book yet providing infinitely more data. Book sales have also been in decline as more and more small dealers moved over to other forms of delivery so the decision was made last year that February 2017 would be the swansong of the printed book.

The Project

As a result of this decision, it was proposed that there should be a smartphone app that would mimic the behaviour of the book whilst adding to its features. It should be able to operate offline as there are still many areas of the UK with poor data connection, yet if such a connection was available, it should offer enhanced search facilities allowing the user to identify a vehicle through its Registration mark (or VRM).

It was with this remit that the development of such an application was assigned to our team and the search began for the ideal platform. As the design stipulated that the application should be available on both iOS (Apple) and Android devices we began investigating the many options open to us for cross-platform development. The principle being that although there were differences between the two platforms, we wanted to keep the code-base as consistent as possible.

Cross platform development has become a trending topic in mobile applications over the past few years. While using a native app platform offers many benefits and great features, cross-platform development software simplifies the mobile application creation. When we consider developing mobile apps we generally think of using Objective-C, Java and/or Swift languages to develop it. That said, learning a new language requires extra effort and time for any developer not acquainted to it. The list of cross-development environments is getting larger all the time with Sencha, PhoneGap, Titanium, Xamarin and Corvdova to name but a few. Which one you choose depends on your preferred programming language and the needs and goals for your app.

The Solution

In our case, we took a serious look at Xamarin due to its familiar language base and development environment. CAP has only used the Microsoft stack and as Xamarin has recently been acquired by Microsoft, it seemed the obvious starting point for us. Microsoft have also confirmed that Xamarin will be completely open-source moving forward so hopefully there would be no surprises with unforeseen charges being applied to future developments.  Our team was well versed with C# and .NET, both of which were provided by Xamarin and it also had the added advantage of compiling down to the target devices’ local language before deployment. Although this will always give a slight performance hit when compared with native programming Xamarin keeps that loss to a minimum and was always going to be sufficient for our particular purposes.

We did look briefly at the idea of using C++ for development as it is the only language that both platforms officially support through the recognised development environments, but as we would have to drop back to Objective-C (iOS) or Java (Android) to access the official library calls, that meant code reuse would only have been about 50% which was way too low for our needs.

One further recent development that sold it for us was the introduction of Xamrin.Forms. As explained in the Xamarin developer forum:

"The Xamarin.Forms is a cross-platform framework that allows developers to create user interfaces which can be shared across Android, iOS, Windows and Windows Phone. The user interfaces are rendered using native controls of the target platform. For different platform, Xamarin.Forms applications can retain the native look and feel.

When writing Xamarin.Forms application, large portion of codes can be written in the shared code, platform specific codes can be written in each platform. There are two approaches to handle the shared code. One is to use Portable Libraries, the other is to use Shared Projects. In Portable Class Library (PCL), when code is compiled, assemblies (dlls) are generated for each platform. In Shared Project, a number of different application projects can reference common code. There are two methods to create user interfaces. One is to use C# code, the other is to use XAML. So it’s easier to get Xamarin.Forms started for those who have WPF experience. Though controls are enough in Xamarin.Forms, you can also implement renderers in each platform to create the appropriate user interface."

 In short, this allows a single piece of code to perform the same function on all target devices but still give the appearance of running natively. For example, the usual methods of deleting an object on the iPhone (swipe) and Android (press and hold) are very different, but with Xamarin.Forms we can use the same C# source code to provide this functionality.

There are obviously certain areas where the platforms differ and for these sections, Xamarin provides Xamarin.Android and Xamarin.iOS to provide direct access to these features.

The Learning Process

This article won’t go into the details of setting up Xamarin as there are an abundance of examples already out there, including the official Xamarin one. For us, the process of setting up Xamarin for our existing Visual Studio setup was relatively painless. Most of the issues came from the idiosyncrasies of various PC setups and the fact that we are hiding behind a proxy.

At the time we were using vs2015 update 3 and the first stage was a simple matter of running the setup again and ensuring Xamarin is included…then waiting & waiting & waiting… An essential part of the setup is the download and installation of the latest version Android studio which in itself if a 9GB package but in addition to this, it’s also worth checking the “Microsoft Visual Studio Emulator for Android” option in the setup process. The existing Android Emulators which come as part of Android Studio are Java based and struggle to perform on even the most powerful of PCs. The Microsoft Emulator uses Hyper-V technology to execute as a VM ensuring that on even i3 devices, the emulator will still run at the speed of the target platform. On a side note, it’s worth checking your BIOS setup at this point to ensure virtual machine functionality is setup as it should be. For supposedly similar PCs there were a startling number of differences at this level.

So that got us to the point of being able to produce applications for Android, but for iOS, Apple require all deployments to go through the official signing process which is only available on a computer running Xcode7 (or above) and therefore OSX11. In other words, a Macintosh.

Luckily we already had an existing Apple Mac in the company and the setup process for that was if anything, even less painful than for the Visual Studio side of things. Once the Mac was setup on the same network as the PCs running Visual Studio, any iOS device (or emulator) available to the Mac under Xcode was available as a target device would appear similarly as a target device under Visual Studio. As the Mac was only being used for compiling and deployment our own setup had a team of 4 people running vs2015 on Windows PC with a single Mac acting as an agent to build and deploy to a number of iOS devices.

What Went Right?

To a certain extent our aim of producing the application went as planned. Our code reuse was approximately 90% and as with most mobile applications, we spent the last 30 percent of the time adjusting the application for various screen sizes and layouts. iOS typically has around 3 screen aspects and sizes as base targets whilst Android targets around 4 which meant the occasional issue with misplaced buttons or grids. For data storage we used SQLlite because it is a standard format that both target platforms support and we already had a relevant set of SQLlite databases containing all the information we required.

What Went Wrong?

Most of the issues we had were due to the constant upgrading of the Xamarin platform as we developed the application. Visual Studio is already a behemoth of an application and the constant updates created a few small edge cases as we went along and causes the odd IDE crash and compilation failure. The typical reaction after finding out that there was a Xamarin update was…”Good luck”…but being fair, all went well in the end. Hopefully these issues will be ironed out in time as the development reaches a plateau and Microsoft are able to deal with bug fixes rather than adding features.

It’s also worth noting that Xamarin does have a limited coverage of the official library calls so there are still a fair number of features available in the official libraries which cannot be accessed directly with Xamarin. In these cases it is possible to drop back to use those official libraries and link them into the Xamarin code but such situations do cause a further divergence of the final code.

We also had a couple of issues where the forms provided by Xamarin (and the target frameworks as well) didn’t match our UI expert’s mock-ups. In this case we had to write custom code for each of the target platforms to provide the functionality required but on the whole, the UI was designed with the target platform in mind.

 

Conclusions

So, to sum up, is Xamarin worth it and would we use it again?  For us yes, depending of the project and requirements we would be happy to us Xamarin again. It will never reach the pure performance of native development but overall as a method of providing our customers with online, always available and fully portable access to our data it was an ideal solution and one that worked extremely well.