Porting Obstacles:  5 Considerations with Xamarin Android

Porting Obstacles:  5 Considerations with Xamarin Android

Many customers I’ve met who are using Windows Mobile devices in their organizations are considering switching to Android devices. However, before making decisions on a new operating system, they are concerned about the effort it would take to port their Windows Mobile apps to Android – and to ensure they can do so without having to go through a complete rewrite.

In making smart decisions in application porting, I have been asked if the Xamarin development environment would be a suitable alternative for porting existing Windows Mobile applications to Android. Xamarin has created a subset of Microsoft’s .NET framework and a C# compiler that allows C# .Net apps to be developed for Android and iOS. Would Xamarin potentially lessen the porting effort by allowing some subset of an existing C# .Net code to run as-is on an Android device? Well, it would allow development staff to continue to use a language they know with a very similar app framework, and it would provide the ability to share portions of code between Windows Mobile and Android versions of the same app. However, there are obstacles to consider…

User Interface

At a minimum, the Xamarin documentation indicates that the user interface (UI) for Windows Mobile apps – Windows Forms – does not exist in the Xamarin framework for Android, so the UI would need to be rewritten.  The UI objects and events used to build a Windows Mobile app are very different from those available to build an Android app. Consequently, developers must understand how to use Android user interface components to properly program the Android UI separately from an existing Windows Forms UI.

Missing .Net components

Xamarin has implemented a core set of the components of the Microsoft .NET Framework, but not all of it.

A .Net Windows Mobile (.NetCF) app may use .Net assemblies that are not compatible with the Xamarin environment. Since the Xamarin.Android framework is only a subset of the Microsoft .Net framework, the more use one makes of the Microsoft Framework in a Windows Mobile app, the less likely it will be that the app will be directly portable to Xamarin without some additional rewrite.

Use of Native Libraries (PInvoke)

The Xamarin.Android environment supports the PInvoke mechanism for accessing native libraries from .NET code, but on an Android this would only work for Android native libraries. If a Windows Mobile app makes use of PInvoke to access native Windows Mobile code, then the functionality of those native modules would have to be created for Android. Depending on what the native functions provide, they may or may not be able to be developed in C# in Xamarin.Android, and may need to be developed in Java and then PInvoked from the .NET code.

Motorola EMDK

Many Motorola Solutions’ customers have made use of the Motorola EMDK for .Net. The components in the Motorola EMDK are not available in the Xamarin.Android environment, but it’s possible that some of the EMDK could be made available just by rebuilding it for Xamarin.Android using the Xamarin toolset. Although most would have to be rewritten to allow for differences in the Windows Mobile and Android architectures.

Implementing Missing EMDK functionality

In the absence of EMDK functionality, replacement functionality in C# would have to be developed. For instance, without the Symbol.Barcode classes, separate scanning functionality for Android devices would have to be implemented. Motorola Solutions provides documentation and samples for accessing scanner functionality available on Motorola android devices, but those examples are for java code. Some effort would be required on the part of developers to properly interpret that for Xamarin.Android using C#.

Summary

Although the Xamarin framework and tools provide some capabilities to assist in porting Windows Mobile apps to Android, it is certainly not just a recompile to run on an Android device. There are several general types of obstacles to overcome as well as a requirement for an in-depth code analysis.

In addition, even if the effort to port an app to Xamarin.Android seems acceptable, would the resulting app have reasonable performance on the device? Well-written Xamarin.Android apps are just as fast as their java equivalents since the Mono.VM generates code as efficient as the Dalvik VM on Android and in some cases the Mono.VM runs faster. Some literature has indicated that well-written Xamarin. Android applications are faster than their Java counterparts. However, each specific app would have its own performance characteristics and it would be wise to choose a heavily-used app and pilot it as a Xamarin.Android application on an MSI device.

My recommendation to customers who are making these choices is first to always understand that any tool used to assist in porting an application is going to have some shortcomings – there is no silver bullet by any means.  Depending on a customer’s existing application and future direction some customers would be better to use Xamarin and some would be better using something like Motorola’s RhoMobile. Motorola Solutions also has in-house consulting experts in our Professional Service practice who can also do assessments to help make an informed decision.  I see customers faced with these challenges all the time, and while porting applications can be challenging, with a trusted partner, it doesn’t have to be painful.

Brian Reed is Principal Software Engineer, Professional Services Release Management Group, Motorola Solutions.

Learn more about developing for Android in our Launchpad Developer Community.