Mobile Development today is what Web development was in the late 90’s – it’s what all the cool kids are doing! However if you’ve become attached to Visual Studio and C#, the viable options for jumping into Mobile in recent years were limited. In mobile, ObjectiveC and Java rule. An open-source project called Mono Touch has been around for some time, but it had limitations…
The last couple of years have seen the rise of a commercial successor to Mono Touch: Xamarin – and it is hot! Its success has been accompanied by strong community interest and unprecedented support from Microsoft. (In fact, there are rumors that Microsoft may buy Xamarin and integrate it into its suite of .NET tools.) The income generated by that success drives new investment in growing and maturing the product in a way that would take much longer via open source.
This week saw the release of Xamarin 3. Is now the time to make the leap to mobile development? Is Xamarin a mature environment? Is it reliable enough to support development of Enterprise applications?
The Tools of the Trade: A Mix of the Familiar and the Less So
Xamarin has its own development environment that works much like Visual Studio. But it also has an add-on for Visual Studio that gives you all the features of Xamarin in your favorite IDE. As I suggested, the language you’ll use for development is C# (or, new with 3, F#). You also get access to the Microsoft .NET Framework! That’s quite a boon on a non-Windows platform. And it assures that existing code can easily be swiped and used as is, or with few changes.
But don’t get too excited – there’s still plenty to learn! The subjects you may need to study may include (depending on the type of project):
- New user interface approaches, including new controls, new layout approaches and maybe multi-touch and gesture recognition
- Mobile APIs to leverage device features like GPS location, cameras and network/internet/wireless communications as well as cloud storage
- Graphics APIs for image, animation and video
Interfacing with the User: Go Native!
Obviously any project will require some level of knowledge of device UI and unfortunately this knowledge is typically not portable across mobile platforms. That’s also true for Mobile APIs to device features and Graphics APIs. So although Xamarin allows you to write applications for iOS, Android, Kindle and Microsoft Surface, it does not provide the ability to drive them all from a single source. This can be mitigated some if you decouple the user interface from the rest of the code. Database access and business rules code may be portable with few or no changes. (For example, SQLLite is the built-in database for both iOS and Android and is available for Surface as well.)
However Xamarin is different from these tools in an important way – it is a real, directly native programming environment. If you’re writing for iOS, you’ll use the same controls that an ObjectiveC developer would and you’re creating natively compiled applications for the iOS platform. Same for Xamarin projects targeting Android. This gives you a native user interface look/feel and maximum speed with no layers between your code and the hardware. But wait – did I say natively compiled? Isn’t .NET code compiled into IL to be run via the JIT? Usually, yes. But that’s not the way Xamarin does it. Instead it pre-compiles the .NET code into native executables that are indistinguishable from their ObjectiveC/Java counterparts.
That said, the new version of Xamarin provides some helpful support on the user interface front. Xamarin.Forms is a new feature that provides a single user interface structure – one that’s very similar to Microsoft’s outstanding XAML approach. However this isn’t a re-implementation of the user interface that results in a UI that isn’t native to the platform (as many of the other tools do). Instead it’s a middle-layer that generates the appropriate native control code for each platform. So, for example when you add tabs to a screen and then compile your app for iOS, the tabs are generated as an iOS tab bar at the bottom of the screen. When the code is compiled for Android, the same tabs are rendered as action bar tabs at the top of the screen. In addition, it provides an easy method to write platform-specific UI code that only gets executed when running on the specified kind of device.
Another important new feature in this iteration of Xamarin is a full-blown UI designer for iOS. Previous versions provided a designer for Android, but forced iOS developers to use XCode on a Mac for UI design. Now it’s all available in Visual Studio and provides all the features provided by XCode.
There’s Gotta Be a McDonald’s Around Here Somewhere!
With the user interface issue mostly resolved, it’s time to figure out what the learning curve (and redundant code) cost will be for making your application location-aware and able to use other device features. Here Xamarin also has a strategy to help manage the complexity: Xamarin.Mobile. With this library, you get an abstracted layer for accessing the user’s contacts, the camera and the geo-location features. As with Xamarin.Forms, the appropriate platform specific code is generated for each.
However this library is still in preview release, so there are bugs and it’s limited to the features just mentioned. Features not included, but planned, include notifications and accelerometer services. Further, the abstraction layer will necessarily only implement common features available on most platforms. Device-specific features will naturally still require device-specific code.
So what about graphics and animation? These features are likely to remain platform specific for a while. Although abstraction is possible, you will usually want to stay as close to the metal as you can with these features. Current device CPUs and graphics processors are still well below PC standards so media and gaming apps will need all the speed they can get – especially if they need to support older models.
What about Third-Party Library Support?
Whenever possible it’s a good idea to leverage third-party libraries and controls to accelerate your development rather than creating similar code from scratch. And since .NET is a mature, widely-used platform the options are tremendous. Unfortunately most .NET libraries can’t be used as-is in your iOS and Android apps. If you have the source code, you can compile it to native with the rest of the application. But pre-compiled libraries contain IL and can’t be directly converted to a mobile-platform executable.
However all is not lost. Xamarin, in cooperation with Microsoft, now supports Portable Class Libraries. Libraries like this can be used in a .NET application for any platform – Windows, iOS or Android. With official support, third-party library developers will likely jump on the bandwagon and soon put a host of options at your fingertips.
Until then? Well, as I mentioned, Xamarin has seen broad interest and support since its release and there’s a respectable number of components and libraries made specifically for it. These are all conveniently browsable and searchable at the Components store on the Xamarin site. To give you an idea of the variety available, here are a few of the options featured on their site: Signature Pad which makes it easy to capture and save signatures; TeeChart Charting Library, ActionTray, which provides a dockable, customizable, slide-out tray for controls or navigation options in your app; and Amazon S3 to store and retrieve data using Amazon’s cloud storage service.
What’s the Verdict?
I haven’t covered all the features and capabilities of Xamarin 3 by a long shot. But hopefully I’ve given you a glimpse into the world of C# mobile development, both the good and the not-so-good. Xamarin 3 is a strong platform and with serious Microsoft support it only promises to get stronger. In the end, if you want to leverage your existing C#/Visual Studio skills to create fast, native applications for iOS, Android, Microsoft and others, Xamarin is well worth your consideration.