The best work opportunities ask you to use what you know in a new way. Recently, I had that opportunity when a new contact approach Springthrough with a unique scenario. He works in the R&D department of a local company. His department routinely builds prototype software to set their products apart.

Of course, one of the biggest challenges for any team is bandwidth. His team was no different. They started a project but needed help to meet their deadline. This contact knew of Springthrough and knew that we are primarily a .Net shop. He thought with our experience, we could easily jump in to help complete their prototype.

You see, they had already completed the iOS portion of a Xamarin Forms application. What they needed from us was the Android app completed. Our .Net expertise set us apart since Xamarin uses .Net (C# or F#) as its development language.

I had some knowledge of Xamarin Forms before we started this project but hadn't utilized it in any business projects. So when I saw this one come through, I was excited to build something new using the system. The R&D team had already gone through the process of setting a baseline, so we could charge forward. For example, their selection of Xamarin in the first place gave us several key advantages in the prototyping process.

1. A Single Programming Language

We leveraged a single programming language (C#) for multiple platforms. In this case, the prototype only needed to be built for Android and iOS, but UWP and Windows Phone are also supported.

2. Development Environment

You can use Xamarin Studio and develop on a Mac, or you can install the Xamarin Form extension into Visual Studio 2013 or Visual Studio 2015. It’s great to not have to learn the ins and outs of another IDE. You can use one you are already familiar with.

3. Licensing

You probably already have a license for Xamarin. Now that Microsoft has purchased Xamarin, the license is included with your MSDN subscription. It is available at any level from Community Edition on up.

4. Nuget Package Manager

There are many Nuget packages available for cross-platform development in Xamarin Forms. For example, there is a nice package for geolocation that we wound up using. Just add the package, add a reference and there it is, just like any other C# app.

5. Shared Code

One of the best features of Xamarin Forms is that you can share code across platforms. As long as the code isn’t dealing with something that is platform specific, it can be shared across them. So, what’s not platform specific? Any business logic you may have in your application. You can write your business logic in a PCL (Portable Class Library) and that can be used by both the IOS and Android projects. And, believe it or not, most of your UI can be written once, in either C# or Xamarin’s version of XAML. The great thing is, even though you write the UI once, it is rendered into native platform controls. So, a tabbed control on Android has the tabs across the top, on iOS it has them across the bottom. The bottom line is, you have the look and feel of a native app on each platform, but you only had to write the UI once.

So What Did We Build?

Basically, we had to identify the platform-specific aspects of the application. What is platform specific? You can think of that as anything that interacts with hardware. So things like taking a picture, getting GPS coordinates, or connecting to Bluetooth devices. Each platform has its own set of APIs for those kind of interactions. You need to write specific code for each platform to accomplish those tasks.

This is where the majority of the work we had to do took place. The application needed to access geolocation data and read advertisement data from certain Bluetooth Low Energy (BLE) devices.

The geolocation turned out to be very straight forward. With the Nuget package mentioned above, getting GPS coordinates was a breeze and the code for iOS and Android were almost identical.

Getting at the advertisement data turned out to be a bit more of a challenge. As I mentioned before, the iOS version of the app was already up and running. The original developer had written his own wrapper around the iOS Bluetooth APIs, following the lead of some other open source projects. This left us with the choice of trying to find an existing open source project and/or Nuget package that handled both iOS and Android BLE and switch the iOS app to that, or follow the original developer’s lead and write a wrapper around the Android BLE SDKs. In the interest of time and not wanting to re-write working code, we opted to wrap the Android SDKs. With a couple open source projects as guidelines, we were able to interact with the BLE devices, parse the manufacturer specific advertisement data in fairly short order.

In the end, the client now has two native apps, one for Android and one for iOS that share a significant portion of the code base.

In the future, we will be helping this client with another major iteration of the application. We will be adding several new features, this time in both the iOS and Android side. While it's not a perfect tool for every scenario where you have an app that needs to run on multiple platforms, it's certainly worth checking out. We will be evaluating it for some of our other clients who currently have separate iOS and Android apps. As a developer, it was a pretty good experience and I look forward to diving deeper into it in the future.