How we developed our first application on Xamarin.Forms and what came of it

Xamarin claims that using Xamarin.Forms allows you to increase the amount of common code in applications for three mobile platforms (iOS, Android and WP) from 70% to 90%. I had a chance to check this fact out on my own experience. About why this is true and not true at the same time my story.



Immediately clarify that my experience relates already could become outdated. In the world of Xamarin, everything changes quickly, especially given the ongoing conference Xamarin Evolve.
')
It all started with the fact that I changed jobs and in the new job, while waiting for the first project, I was sent to do a small internal mobile project, the main purpose of which was to introduce developers to Xamarin. For development, Xamarin.Forms were chosen because the project was simple and did not assume a cool design. The problems started right away.

Problems

1. Xamarin.Forms currently has a very small set of standard controls. Yes, this set can be expanded with components created by the community, but still, a lot of things are missing. Yes, and those controls that are often (sometimes for unknown reasons) lack the necessary features and properties. A simple example: the Picker control used to select from large lists does not have bindable properties for the currently selected item and the list of items.
2. Some controls are mildly strange. For example, placing the ActivityIndicator in the center of the page on all platforms, without using additional code, turned out to be impossible.
3. Creating markup with XAML and not code is very difficult. Let's start with the fact that intellisence works according to some of its own rules known to him. Those. it can work on one line, but for some reason stop working on another. Yes, it's about Xamarin Studio, in Visual Studio intellisence does not work in principle.
4. At the time of development, there was no question of any visual editing of the markup.
5. Some standard XAML features do not work. For example, I could not add a link to ResourceDictionary to the page, use integer constants and converters. And, of course, actions and behaviors from Blend do not work. In addition, some things are implemented in Xamarin.Forms not as they are usually done in XAML. For example, in the lists inside the DataTemplate is not the markup itself, but the ListCell within which the markup already lies.
6. Label does not support string trimming. It would seem nonsense, it is not worth a separate item, but it seems that this is a very good indicator of platform dampness. But Xamarin does not deny this.
7. Xamarin.Forms does not work with new projects for Windows Phone 8.1 from Visual Studio 2013. This has become a big problem for us and forced us not to use Xamarin for an application for Windows Phone since it is one of our libraries (the latest version of Windows Azure Active Directory) Required WP 8.1.
8. The documentation for many classes and controls is very poor and is actually just a list of properties, constructors, fields without examples and explanations.

No problem

1. In general, having the markup already described in the code, turning it into XAML is not a problem. It took me about two hours to convert two pages.
2. Xamarin.Forms has an easy publisher-subscriber implementation, which helps a lot with platform-specific code, reducing connectivity. True, we used this implementation instead, which can work with both Xamarin and WP 8.1.
3. Yes, using Xamarin.Forms you can get 90% of the total code. Platform-specific code may be very small. For example, we work with WAAD and notifications. That's just the rule for a spherical application in a vacuum. Any application requires a specific code - processing intents in Android, background fetch in iOS, tiles in WP.
4. There are a lot of third-party controls. If you don’t have it, you can always add it. For example, the same Picker :)
5. The developers clearly understand that the design for all three platforms cannot be absolutely identical, therefore, in addition to rewriting renders for different platforms, there are simpler means. For example, you can specify the dimensions for each platform separately using a special helper. But again, not in XAML.
6. For the distribution and collection of crashes, we used HockeyApp (without a link so as not to advertise), which is supported by Xamarin and WP (the builds are in the Xamarin gallery).

findings

In the end, we managed to make an application that can even be used, but in the future I would prefer to use Xamarin without Forms. Although in my opinion, the future of Xamarin.Forms is (unless of course they are abandoned), and for the development of uncomplicated corporate applications they will be perfectly suitable in half a year.

Amendments and comments

2. ActivityIndicator can be placed in the center without a code. This, as it turned out, is easy to do with AbsoluteLayout.
5. Actions and behaviors will be added in the next version of Xamarin.Forms 1.3 (now in alpha state). If you want to right now, then there is a nuget package . Dictionaries apparently will lead to a working condition, too, in the next version.
5 again. In XAML, you can specify different parameters for different platforms. For this there are classes OnPlatform and OnIdiom.