Xamarin.Forms – real life stories

During last 12 month I was part of small but very mighty team. Our goal was implement mobile tablet-optimised application supporting 3 major platforms: iOS, Windows, and Android. At this stage, this project is almost completed, application is published in Apple, Windows stores and in Google Play. A lot of lessons have been learnt during this year and this what I want to share.

1. Why Xamarin?

OK. Why Xamarin? Let’s see which options are available and applicable to the requirements.

Requirements as defined by client:

Create three mobile applications (downloadable from application stores) which are :

  • Responsive
  • Have good performance (in user’s eyes)
  • Able to reliably cache large amount of data for a long period of time
  • Able to communicate securely with server (located either on customer intranet or in the cloud)
  • UI/UX on different platforms must be very close to each other. The reason for this requirement is the fact that most of end-users are not technical people and some customers have more than one device type. E.g.: mix of iPads and Microsoft Surfaces.

One aspect that we need to take into account is that the client has large C# code base and legacy Windows Forms application which contains most of business logic to the new mobile client.

Let’s review our options for this project

  1. 100% native – 3 completely separate mobile application need to be created
    iOS – Using Objective-C or Swift language with XCode as a development environment
    Android – Using Java language and one of many Java dev environments
    Windows – Using C# as a language and Visual Studio as  development environmentIn this case three applications above will be completely different. From one side it is a positive factor, as changes/bug fixes on one platform won’t affect another. From the other side it is a big negative factor, as it forces us to duplicate such platform agnostic functionalities as client-server communication, business logic, etc. Also, it is very hard to find single developer who is very good on all three platforms. It could also lead to creation of three separate teams, necessity to maintain three separate backlogs, etc.
  2. HTML5 + Javascript mobile app wrapped up my native application
    In this case most of UI, business, and communication layers will be re-used across different platforms. It is valuable option for companies with HTML5/Javascript expertise. From the other side application becomes dependent on platform specific implementation of device internet browser. Sometimes operating system update changes browser behaviour that can break the application.
  3. Xamarin – 3 native application written using C# language.
    This approach allows different degree of code re-use across different platforms. In most cases, business, data, and communication layers could be shared without any changes. In case of Xamarin.Forms, large part of UI can also be shared.

So, why did we select Xamarin as a platform for a new application?

First of all, initial scope of the project was defined as a re-write of existing WinForm C# application. Obviously we didn’t want to re-use UI and communication layers of 7+ years old app, however some of business logic could be re-used as is.

In addition, ability to work completely offline for number of days was one of the main requirements. It means that any browser-based solution risky and vulnerable to operating system updates.

As three platform release was originally planned, maximum re-use was one of main factors.

Based on all above, Xamarin  framework was selected as a platform. But which flavour: Xamarin native or Xamarin.Forms ?


Read part 2 od this blog series: Xamarin.Native vs. Xamarin.Forms

Readify has upcoming events on Xamarin, Mobility and Cross Platforms: visit Readify.net/events to find out more or follow Readify on Twitter

Advertisements

2 thoughts on “Xamarin.Forms – real life stories

    • I agree. There are multiple potential sources of performance problems.
      I will blog in more details later, but in a nutshell some of them are:
      – Memory leaks
      – Navigation. Try to disable animation when navigating on Android

      In general, if some of Xamarin.Forms controls are not performing as fast as you need – you can always create Custom Renderer and get performance very close to native.

      Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s