< Previous post of this series
Let me start this post with a small incident that happened in our organization a couple of years back. We had switched our insurance provider and the representative of the new provider was giving a presentation of the benefit plan. Then came a slide that had their “mobile app” mentioned, among other things. While they talked how one could look up health care providers and other information via the app, someone mentioned that they couldn’t find the app in the store. After a few seconds of confusion, the presenter assured to get back with the information about the app.
The disconnect was – the app they were talking about was a mobile web site, where as people were instinctively searching in the app store. This brings out many interesting points. One of the most important being – the discoverability of your application. When you look for an app that provides a functionality do you open the browser and search online? Maybe, depending upon what are you searching for, but it is highly likely that you will look for it in the App Store of your device.
Which leads us straight to the ultimate option of targeting multiple devices and platforms:
Publishing the application in the app store of the platform.
There are a few ways to go about it
One would be to choose the device/platform and re-write an app using the platform’s API and language. But given that right now we are talking about targeting multiple devices and platforms, I would not recommend it.
The second will be to abstract the business logic / functionality to a restful service and write multiple UI clients (AKA Apps) using the native platform. That is a decent option, however there is a cost associated with hiring multiple developers each with their own platform skills (Objective C with iOS, Java with Android, C# with Windows 8/Phone etc.). The cost for development and maintenance adds up, every time a new version of the platform is released and newer devices stop supporting older platform versions.
The ultimate goal is to implement this option using the existing skills and without re-writing the entire application. This can be achieved in two ways. But to achieve either, the application has to be well structured. Any well written application defines the boundaries of at least the three traditional layers – UI, Business layer and Data access later. To be able to reuse most of the code across apps, it is rather required to separate out at least the UI layer from the rest of the application logic.
Let’s take a look at these options now:
1 – Speak the Universal language – HTML5
To get the full benefit, the reusable business and data access logic should be abstracted into a RESTful service which would be consumed by your application that will be consuming the PhoneGap framework.
2 – Hire an interpreter – Xamarin
Xamarin allows you to write native iOS, Android and Windows store apps using a single application platform (Microsoft .NET) and language (C#). Applications build in Xamarin enjoy full native access to platform APIs, get native performance and user interfaces. Xamarin provides the ultimate ease of development and maintenance by integrating its tools right into Visual Studio and by extending Microsoft tooling. Microsoft released Portable Class Library (PCL) to develop functionality using C# to be used across a verity of platforms. This was initially created to support Microsoft platforms like .NET and Windows, Windows 8 Store, Windows Phone, etc. In 2013 the PCL feature was extended to iOS, Android and Mac using Xamarin. Since PCL is independent of the platforms it does not support some platform specific features, like certain encryption. Also Entity framework 6.X is not supported PCLs, but as per the forums, EF 7 will be.
That said, you can create the shared business logic of the using PCLs, which each separate client application can use. The new release of Xamarin includes a new feature – Xamarin Forms which allows the sharing of UI logic across platform too.