Как мы разрабатывали свое первое приложение на Xamarin.Forms и что из этого вышло

В Xamarin утверждают, что использование Xamarin.Forms позволяет увеличить обем общего кода в приложения для трех мобильных платформ (iOS, Android и WP) с 70% до 90%. Мне на собственном опыте довелось проверить этот факт. О том почему это правда и неправда одновременно мой рассказ.



Сразу уточню, что мой опыт относится уже мог устареть. В мире Xamarin все меняется быстро, особенно с учетом идущей сейчас конференции Xamarin Evolve.

Все началось с того, что я сменил работу и на новой работе в ожидании первого проекта меня отправили делать небольшой внутренний мобильнй проект, основной целью которого было познакомить разработчиков с Xamarin. Для разработки были выбраны Xamarin.Forms так как проект был несложным и не предполагал крутого дизайна. Проблемы начались сразу же.

Проблемы

1. Xamarin.Forms на данный момент имеет очень маленький набор стандартных контролов. Да, этот набор можно расширять за счет компонентов, созданных сообществом, но все равно, много чего не хватает. Да и те контролы, что есть часто (иногда по непонятным причинам) лишены нужных фич и свойств. Простой пример: контрол Picker, использующийся для выбора из больших списков не имеет bindable свойств для текщего выбранного элемента и списка элементов.
2. Некоторые контролы ведут себя мягко сказать странно. Например поместить ActivityIndicator в центр страницы на всех платформах, без использования дополнительного кода, оказалось невозможно.
3. Создавать разметку с помощью XAML а не кода очень сложно. Начнем с того, что intellisence работает по каким-то своим, одному ему известным правилам. Т.е. он может работать на одной строке, но почему-то перестать работать на другой. Да, речь про Xamarin Studio, в Visual Studio intellisence не работает в принципе.
4. На момент разработки не о каком визуальном редактировании разметки речи не шло вообще.
5. Не работают некоторые стандартные фичи XAML. Например мне не удалось добавить ссылку на ResourceDictionary на страницу, использовать целочисленные константы и конвертеры. И, естественно, не работают actions и behaviours из Blend. Кроме того некоторые вещи реализованы в Xamarin.Forms не так как они обычно делаются в XAML. Например в списках внутри DataTemplate лежит не сама разметка, а ListCell внутри которого уже лежит разметка.
6. Label не поддерживает тримминг строк. Казалось бы ерунда, не стоит отдельного пункта, но кажется, что это очень хороший показатель сырости платформы. Впрочем Xamarin этого и не отрицает.
7. Xamarin.Forms не работают с новыми проектами для Windows Phone 8.1 из Visual Studio 2013. Это стало для нас большой проблемой и вынудило нас не использовать Xamarin для приложения под Windows Phone так как одна из, используемых нами библиотек (последняя версия Windows Azure Active Directory) требовала WP 8.1.
8. Документация по многим классам и контролам очень бедная и представляет из себя фактически только список свойств, конструкторов, полей без примеров и объяснений.

Не проблемы

1. В целом, имея разметку, уже описанную в коде, превратить ее в XAML не проблема. У меня ушло порядка двух часов на конвертацию двух страниц.
2. В Xamarin.Forms имеет несложную реализацию publisher-subscriber, что очень помогает работать с платформ-специфичным кодом, уменьшая связанность. Правда мы вместо нее использовали вот эту реализацию, которая может работать и с Xamarin и с WP 8.1.
3. Да, используя Xamarin.Forms можно можно получить 90% общего кода. Платформоспецифичного кода может быть очень мало. У нас например это работа с WAAD и нотификации. Вот только это правило для сферического приложения в вакууме. Любое приложение требует специфичного кода — обработка интентов в Андроид, background fetch в iOS, тайлы в WP.
4. Сторонних контролов много. Если же нет его-то нужного, всегда можно дописать. Например тот же Picker :)
5. Разработчики явно понимают, что дизайн для всех трех платформ не может быть абсолютно идентичным, поэтому кроме переписывания рендеров под разные платформы есть более простые средства. Например можно указывать размеры, для каждой платформы отдельно при помощи специального хэлпера. Правда опять таки не в XAML.
6. Для распространения и сбора крэшей мы использовали HockeyApp (без ссылки чтоб не рекламировать), который поддерживает Xamarin и WP (сборки лежат в галерее Xamarin).

Выводы

В итоге нам удалось сделать приложение, которым даже можно пользоваться, но в будущем я бы предпочел использовать Xamarin без Forms. Хотя на мой взгляд у будущее у Xamarin.Forms есть (если конечно их не забросят) и для разработки несложных корпоративных приложений они будут отлично подходить через пол-годика.

Поправки и коментарии

2. ActivityIndicator можно поместить в центр без кода. Это, как выяснилось, несложно сделать при помощи AbsoluteLayout.
5. Actions и behaviours будут добавлены в следующей версии Xamarin.Forms 1.3 (сейчас в состоянии альфы). Если хочется прямо сейчас, то есть nuget package. Dictionaries видимо приведут в рабочее состояние тоже в следущей версии.
5 еще раз. В XAML можно указывать разные параметры для разных платформ. Для этого есть классы OnPlatform и OnIdiom.