Need to build a mobile app across multiple devices? We can help.
As VDS continues to enter technology shows like Techbash and ITPalooza we wanted to have way of running a raffle at these events. The typical style that you will see at the Vendor booths is for Vendors to ask for a business card to be placed in some sort of container which they will then draw from later. This lets them run a simple raffle and get the information for potential clients.
We noticed early on in our first show that a lot of people will just walk right by your table if there is only business information present. They will even walk by if there is only business information present. What we noticed some other booths doing was giving prizes based on the results of spinning a spinner. We decided that we wanted to get a spinner and offer multiple entries into the raffle based on the results of the spin. However we wouldn’t be able to do this if we were only putting business cards in the bowl because we couldn’t ask people to add more than one business card.
We came up with the idea for a mobile app that we called Winffle. It would let us run raffles for a variety of events and importantly allow us to add multiple entries per person. It has a database in the backend with a Web API we can use to communicate with it. This gave us the added benefit of having the potential client information stored in a database.
However we faced an issue. Some of our team is experienced with Java and Android while other are experienced with Objective-C and iOS. How could we create a solution that everyone would be able to work on? There is also the question of Windows Phone which runs on C# which the whole team is familiar with.
This is where Xamarin comes in.
Xamarin’s roots are in the Mono project which is a project to bring C# to Linux and OSX. With Android being based on Linux and iOS being based on OSX Xamarin allows users to write code in C# and compile them for the platform they are targeting. That’s right, you can create a solution that can run on iOS and Android using only C#. Windows Phone will of course work as well because it is already based on C#.
Xamarin comes in two flavors. The first is Xamarin.Android and Xamarin.iOS. This sounds like two things but are just the two parts of one style of making a cross-platform application. Using this style of Xamarin means building 4 projects. One is the Cross-Platform shared code. This is for things that do not have platform specific dependencies. The other 3 are the platform specific projects that house platform specific implementations and UI code.
The other flavor of Xamarin is Xamarin.Forms. Xamarin.Forms attempts to abstract the UI design process for Android, iOS, and Windows Phone using XAML files. XAML files are XML files that have a C# code behind. This allows us to do layout design with XAML and implement code based changes that would be otherwise impossible to do in in the XAML files. You can also generate the layout entirely in code. While Xamarin.Forms does attempt to remove the need for platform specific implementation details it does still require certain platform specific code. The easiest example is the requirement that top margins in iOS be larger than in Android and Windows Phone due to the fact that the top bar on iPhone technically floats over the top of the app layout.
So where do we use Xamarin.Forms vs Xamarin.Android and Xamarin.iOS?
If your application is simple and you do not have much platform specific functionality then you can use Xamarin.Forms. Otherwise, you will need to use Xamarin.Android and Xamarin.iOS.
I started by trying to build Winffle in Xamarin.Forms. While I was very quickly able to make the first page and get an application that deployed and ran, it was extremely difficult to perform navigation to subsequent pages. The idea of opening a new screen from a user click was actually very difficult to implement. Also, while platform specific functionality was possible it is very complicated to do. For instance, in order to be able to take a picture I had to implement an interface with the appropriate methods and then create platform specific instances of that interface. And despite a large number of examples available for this particular need (camera functionality) it was still very tricky to implement.
Xamarin.Forms also suffers from the lack of a designer. Any time you create a design there is no way to get a picture of what it actually looks like without deploying to a device or an emulator. Creating the designs is very tedious and requires a large amount of knowledge about how Xamarin.Forms works specifically. After realizing the difficulty I would face in getting a decent looking app running with Xamarin.Forms I switched. To Xamarin.Android and Xamarin.iOS.
Xamarin.Android and Xamarin.iOS have some very nice things going for them over Xamarin.Forms. First and foremost is the presence of a designer. Having a designer makes the UI design process significantly easier. The biggest aspect of this is really just the ability to see what your design will look like without having to deploy to a device. Also, since they are more widely in use it is much easier to find online support for questions you may have in development. The documentation is simply better.
The drawback of course is that you have to implement the platform specific functionality and UI needs in the manner each platform requires. This requires learning about how each platform implements different functions. However this again is very easy to research as people have been programming for Android, iOS, and Windows Phone for quite a long time. There are loads of resources available for free online. Also, the Xamarin version of implementation mirrors the native implementations (Java and Objective-C) quite nicely. Many of the class names and method calls are exactly the same. I found often that when I was researching how to implement some piece of functionality that the results of the searches were the answers for the same issues on the native platforms.
In conclusion, Xamarin.Forms is just not quite there yet. If you are clever enough to figure out Xamarin.Forms then you are clever enough to figure out how each platform implements functionality. You will most likely be much better served by starting with a Xamarin.Android and Xamarin.iOS based solution. With the addition of a designer and larger market saturation Xamarin.Forms will eventually reach a point where it will be more useful but based on my evaluation that time is not here yet.