Technologies Used
We’ve recently built a nice cross platform app using Xamarin Forms deployed to Android and iOS. It is a social networking app available on both Google Play and the Apple AppStore. The app is called bSeen and allows you to discover people who are nearby that are also using the app. You can also tag people and get notifications when someone is close to you. The app works within a 100m radius making it different to other apps available and is less about dating and more about bringing a social virtual network in to a real life context.
The app utilises the following functionality
- Facebook Integration
- Geo Location Services / GPS
- Custom API Integration
- Messaging System
- Remote Push Notifications
- Dependency Services
- Custom Renderers
- Background Modes / Location
Overall Experience using Xamarin Forms for this App
The overall experience of using Xamarin Forms has been up and down and the general conclusion has been that this app suits Xamarin very well. Where Xamarin Forms has fallen down is if you want to do anything fancy with graphics or animation or nice visual effects it isn’t a good platform to use. For functional and straight forward user interfaces like this app the UI code has been perfect on many levels. Firstly using xaml for the UI layer with an MVVM code pattern and the use of bindings work well. We had some issues with bindings and the use of custom renderers which struggled to update values to the UI in this case. The fact that you only have to have an understanding of Xaml for user interface design to deploy to both Android and iOS is a massive bonus and makes life a lot easier. There has, however, also been discrepencies with the way that certain aspects of layouts and navigation is handled on the various platforms. For example, when you push a modal on iOS and then make it disappear, the underlying view gets it’s “OnAppearing” method called but on Android it doesn’t so you would have to make use of the Device.OnPlatform(Android: (() dosomething)); in the disappearing method of the modal to get that working on Android. Various things like this reduce the percentage of shared code across platforms and requires more need for platform specific code, but generally the use of renderes and the dependency service has been a good workaround for these kinds of problems.
Admittedly there is a sense of liberation with native development that is hidden by building with Xamarin Forms. Although you’re getting Xamarin to automatically render user interfaces to the different platforms, you kind of feel as though you’re behind a wall that restricts you to immediate access to all the native functionality. The way of handling this is by the use of NuGet packages like the GEOLocation plugin built by one of Xamarin’s developers James Montemagmo. It’s a great plugin that gives you quick access to native location functionality for each platform in GPS tracking but it is only interfacing in to the features of location and so you may find that if you want to do anything particularly complicated on one platform e.g. use significant location service for iOS instead of the constant GPS tracking system, it might fall short and you are behind a bit of a wall where unless you write custom code you’re not going to be able to get away with good code efficiency. On the flip side the significant location change is an iOS specific feature so this is understandable, it’s just that when you want to levergae this service on top of using the plugin it might mean not using the plugin at all and then writing it specific for each platform.
An Example Bug in Xamarin Forms
We also discovered a bug in Xamarin Forms platform which is repeatable as of today 25/02/2016 which we believe to be a farily fundamental issue but has certainly existed for at least one year of Xamarin Forms. The bug exists on iOS when using navigation pages as the root pages of a tabbed page. When you go to use the second tap of a tab bar item which natively pops to the root controller, you get a app crash and there’s nothing you can do about it. The only work around was to use modals instead of pushing through the navigation page and using a generic contentpage as the root view of the tab bar instead of navigation pages. This is less than ideal as it unwantingly hides the tab bar for usability.
Future of Xamarin Forms
If Xamarin don’t end up being the primary source of cross platform code and ui development then someone else will. The idea that you have to write an application individually for each platform is shocking and destined to become a dying art. That being said there are still situations where writing a native app in it’s native language is perfectly appropriate. For example, if the app needs intense animation or visual effects and is only required for one platform then this is a suitable situation in which you would want to write the application natively, but this is increasingly becoming the exception rather than the rule. People don’t want an app on iOS, Android and whatever other platforms, they just want an app and that means it is the developers responsibility to meet this requirement by building it to all platforms. It’s not financially cost effective to have to build an app multiple times. Not to mention the inconsistency of code and inefficiency of code usage.
iOS Screenshots
Android Screenshots
