Работаем с Xamarin: опыт разработки на двух проектах

[Don_Eric]

мы уже давно используем Xamarin и в этом году выпустили приложение и на Forms.
со статьей полностью согласен, кроме нескольких моментов:
* даже в обычных приложениях удобно использовать Forms. Приходится писать больше нативных рендереров, но в конце концов это окупается в плане поддержки.
* MvvmCross я б не рекомендовал использовать вместе с Forms. Если для стандартных Xamarin (iOS/Android) он необходим, то для Forms больше минусов чем плюсов. Сам проект (MvvmCross) стал развиваться гораздо медленнее, влияет на время загрузки аппликации, а плюшки как биндинг, IoC, messenger встроены в сам Forms фреймворк

[Don_Eric]

IoC нет, но возможность регистрировать и вызывать сервисы — да

[artur_g]

А что можно было бы использовать вместо MvvmCross? MVVMLight — вроде как не кроссплатформенный, по крайней мере был, на момент начала проекта. Caliburn.Micro лично мне не очень нравится. Использовать MVVM без MVVM-фреймворка значит самому написать MVVM-фреймворк в процессе написания приложения.

[Don_Eric]

а что именно вам нужно в фреймворке? Xamarin Form он и есть сам по себе Mvvm-фреймворк — с байндингами, навигацией, dependency service, messaging service.
Кстати, тут замечательный блог с конкретными примерами:
adventuresinxamarinforms.com

[artur_g]

dependency service в xamarin это всё-таки не совсем IOC+DI. он в документации позиционируется как способ вызывать нативный код из общего кода. как он себя поведёт при большом количестве зависимостей? можно ли с помощью него зарегистрировать синглтон? сможет ли он создавать объекты, где зависимости инжектятся через конструктор? думаю ответ на все вопросы — нет.
от фреймворка мне нужно, чтобы он автоматически биндил View и ViewModel, и создавал ViewModel и вообще сам заботился о его жизненном цикле. чтобы он умел передавать параметры из одной ViewModel в другую. чтобы он умел показывать сообщения и ошибки из ViewModel во View в соответствии с паттерном, ещё я хотел бы мощную реализацию интерфейса ICommand, чтобы была возможность использовать генерики, параметры и асинхронность. Также хотелось бы всяких приятых плюшек, например готовые конвертеры на разные случае жизни, поддержку настроек, локалиации и т.п… Всё это можно реализовать самому или найти на просторах инета, но хотелось бы чтобы всё это было в одном месте, чтобы фреймворк поддерживался и развивался.

[VVS0205]

Вы можете использовать MugenMvvmToolkit, проект полностью кроссплатформенный и поддерживает все основные мобильные платформы, у него много плюсов в сравнении с MVVMCross, например:

Недоразумение вызывает лишь реализация передачи параметров во время навигации на другую страницу. Для этого требуется, чтобы класс параметров состоял из свойств простых типов (int, bool, string), т.к. он потом сериализуется в URL.

Используя MugenMvvmToolkit вы можете передавать любые параметры, потому что вы сами создаете ViewModel:

Пример навигации

using (var editorVm = GetViewModel<ProductEditorViewModel>())            
{
   var productModel = new ProductModel { Id = Guid.NewGuid() };
   editorVm.InitializeEntity(productModel, true);
   if (!await editorVm.ShowAsync())
       return;
   //Code that will be called after the completion of navigation, and yes, this code will be executed even if the application had been tombstoned and then restored.
}

Документации пока мало, но есть много примеров, также у нас есть группа на Slack, где вы можете задавать любые вопросы по проекту, ссылка на github.

[Don_Eric]

Тогда наверно Prism, part of the .NET Foundation. Один из самых популярных фреймворков для WPF, в этом году они перешли на open-source и добавили поддержку Forms. Использует Unity и Ninject
brianlagunas.com/first-look-at-the-prism-for-xamarin-forms-preview
github.com/PrismLibrary/Prism

[ad1Dima]

MVVMLight уже работает с Xamarin (cам не использовал)
в Caliburn вроде ещё не допилили поддержку

[ad1Dima]

главным в приложении является удобный пользовательский интерфейс.

Это касается только Forms. Нативные средства построения интерфейсов никуда не делись-то.

[ad1Dima]

Главным уроком для нас стало то, что нет никаких причин использовать замариновский тип проекта Shared Project (.shproj), а нужно использовать .NET-овский PCL (Portable Class Library). Главный недостаток Shared Project в том, что в нём можно написать код, который не будет работать на других платформах, и он скомпилируется, а когда начнёшь разрабатывать под другую платформу, с удивлением обнаружишь, что много кода в этой платформе не поддерживается. PCL же такого недостатка лишен.

С другой стороны PCL сильно ограничен и в .NET функциях. А в shared Project можно использовать условную компиляцию. К тому же VS2015 подсказывает, какой код не будет работать в других проектах, к которым подключён Shared

[artur_g]

Ещё один аргумент перехода на VS2015 и Win 8.1+ :)

[Nagg]

у нас был баг: при частом многократном нажатии на список приложение падало. Мы сразу решили, что это баг Xamarin, и что не будем тратить время на исправление, а подождём, может Xamarin сам это исправит

Спасибо, повеселило :-).

[vovtil]

проще написать два нативных приложения на родных средах чем все эти пляски с бубном

[artur_g]

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

[silentnuke]

Да, ибо в итоге это всеравно будет проще.

[ad1Dima]

Чем? У нас на одном реальном проекте до 75% общего кода. UI нативный для каждой платформы. Новые фичи добавлять получается быстрее, чем трижды на 3 платформы.

[silentnuke]

Разбор багов/тюнинг платформы хмарин в итоге выйдет намного дольше, чем написание на двух платформах и поддержка их.
Видел, как довольная известная специализирующася компания на разработке xamarin, потратила кучу времени (несколько лет) на разработку продукта и в итоге так и не смогла ее нормально довести до конца. И да там много общей бизнес лоигики.

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

Какое-то простое приложение, да будет проще написать на Xamarin. Но что-то довольно сложное, например Snapchat, однозначно нет.

[Nagg]

У вас есть опыт в этом деле или всё ограничивается «Видел, как довольная известная компания»? Сколько уже я диванных аналитиков повидал.

[silentnuke]

Конечно же нет реального опыта, пришел тут семечки полузгать ;-)

[Nagg]

Я так и думал. Андроид разработчика можно очень быстро научить писать на Xamarin. Фактически он будет писать как на яве слой интерфейса — теже классы, теже инструменты для UI (более того — можно использовать Android Studio для дизайна). Но при этом они получают два плюса: 1) коровая логика становится доступной для всех других платформ. 2) они получают мощный язык с лямбдами, свойствами (и ещё 20 пунктов по которым ява отстала). Ну и всего-то надо немного понимать как оно работает дабы не вылезть за грефы — для этого достаточно часок-два потратить на чтение пары статей на developer.xamarin.com/guides/android/under_the_hood/architecture

[ad1Dima]

Разбор багов/тюнинг платформы хмарин в итоге выйдет намного дольше, чем написание на двух платформах и поддержка их.

Чем написание — возможно, потому что надо думать, когда пишешь кросс-платформенный код. Поддержка — не факт.

Но что-то довольно сложное, например Snapchat, однозначно нет.

Бизнес-логика у снепчата не слишком-то сложная. вот UI-да. Выйгрыша от Xamarin почти не получится. Хотя написание UI не будет принципиально отличаться от нативного.

[Don_Eric]

иногда больше чем 2 приложения. У нас один и тот же код бежит для iOS, Android, Windows Store, mobile web и десктопные симуляторы/тесты

[om2804]

Xamarin Forms на самом деле сыроват до сих пор. Куча багов, которые фиксятся месяцами. Новых контролов не появляется. Да чего там. Даже старые неохотно расширяются новыми свойствами. У меня уже целая куча кастом рендеров, которые правят баги и расширяют контролы.
Сейчас это больше усреднение между платформами. Если фишки нет в какой-либо платформы, её нет в Forms.
Мне только одно не понятно. Откуда такие ценники на этот продукт?
А работоспособной бесплатной версии-то и нет

[Nagg]

За это я и не люблю Xamarin.Forms — все теперь судят замарин только по нему, и да он не идеален и поэтому хорошенько портит так карму компании. А так XF — это всего лишь фраемворк, который пилит небольшая команда.

[QtRoS]

Хм, а рекламируется повсеместно как готовое и полноценное средство, между прочим… В таком случае я бы Qt выбрал, там ведь по-настоящему кроссплатформенный C++ и QML, никаких проблем с обработчиками и многопоточностью. Единственная грусть — неполная возможность контроля жизненного цикла приложения (но при ровных руках можно допилить класс активити из фреймворка и будет счастье). Но с другой стороны надо признать, что на C# многие вещи пишутся быстрее, чем даже на C++\Qt (для тех кто не знаком с Qt — там С++ немного другой из-за MOC).

[Nagg]

А я бы выбрал классический замарин. В нем можно и логику написать на шарпе и в платформенном коде заюзать любой контрол из pods или jcenter/maven. А у вас есть примеры известных приложений на Qt, а то много раз слышал как люди собирались идти в мобайл с кутэ, но ни разу не видел.

[ad1Dima]

а как именно вы интегрируете любой контрол из pods или jcenter/maven?

[Nagg]

Objective Sharpie 3.0 умеет в pods уже.
Jcenter/maven — через мой плигиньчик к студии :-).

[ad1Dima]

Напишите статью про это, чтоб в противовес Xamarin.Forms повсеместному

[silentnuke]

2gis — QT.
А у вас есть примеры известных приложений на Xamarin?

[ad1Dima]

UI у них нативный. А Qt они допиливали сначала на Android, потом на iOS потому что у них WinMo6 gриложение на Qt было написано.

Эльба вон недавно написали. Они вообще на Xamarin.Forms (вот жеж делать нечего).

[Newbilius]

О да, скоро будет статья про наш опыт с Xamarin.Forms — проблем хватало, но я всё-ещё не могу однозначно сказать, стоило ли оно того, пока не допилим Android-версию приложения на нём же.

[ad1Dima]

А так, на сайте есть у них примеры xamarin.com/customers

[Wellsoft]

Пытались разрабатывать на Xamarin.Forms, но натолкнулись на большое количество багов, медленную скорость работы. И самое главное то, что приходится под каждую платформу писать свои кастомные рендеры(если требуется реализовать не примитивный интерфейс), поэтому прироста скорости разработки от использования Xamarin.Forms не увидел.
Поэтому, в наших проектах пока что используем только Xamarin Native.

[artur_g]

И это правильно, т.к. Xamarin Forms — для простых интерфейсов