Напевно, кожен .NET розробник, знайомлячись з monodroid і monotouch, хоче дізнатися, що його чекає. Чи варто витрачати свої сили і час на вивчення, який потенціал платформи, чи не перетвориться розробка на тестування фреймворку?
Вже більше року моїм основним завданням є розробка на C # під Android і IOS, і я постараюся відповісти на основні питання, що виникають при виборі monotouch і monodroid. У статті буде багато особистої думки і опису милиць, оскільки відповіді з технічних питань можна легко знайти на офіційному сайті Xamarin: docs.xamarin.com
Оскільки Xamarin 3 вийшов тільки недавно, мені не вдалося повністю промацати нові можливості і зміни в платформі. Тим не менш, майже всі «особливості» розробки в monotouch і monodroid як і раніше актуальні.
Розробка
Взаємодія з платформою Android і IOS реалізується за засобами проксі бібліотек Mono.Android і monotouch. Так само, прозоро реалізована мультиплатформенність в System.IO, System.Net, System.Data і т. д.
IOS девелоперам доступні можливості Xcode для генерації уявлень. Під час розробки під Android можна користуватися можливостями Xamarin Studio і аддону до Visual Studio для генерації Xml розмітки.
У силу схожості Java і C # застосування стандартних набоїв і фітч мови не призводить до будь-яких труднощів. Розробка під IOS не складніша - можливості ObjectceC витончено покриваються в мові C #, незважаючи на зовнішні відмінності.
Все це працює так само красиво, як і звучить. Тим не менш, є кілька зауважень:
- Практично всі нативні класи реалізують інтерфейс IDisposable. І це не проста формальність: витоки пам'яті цілком реальні.
- У monotouch Вас, можливо, здивує відсутність таких об'єктів, як GSize, CGRect та інше. Вони замінені відповідними структурами і класами з простору імен System.Drawing.
- Звичайно, винятки, що виникають всередині платформи, вкидаються як MonoTouch.Foundation.MonoTouchException і Java.Lang.Throwable, але не завжди. Цілком реальна ситуація, коли виняток збуджується в коді фреймворку. Більше того: помилка переповнення стека часто просто валить додаток, без порушення винятків.
- Деякі елементи API просто не працюють. Наприклад, події AnimationStart, AnimationEnd у ViewFlipper (Android). Monotouch до того ж володіє цікавою особливістю: деякі методи були перейменовані відповідно до правил .NET. Наприклад, метод UIApplication. didFinishLaunchingWithOptions перетворився UIApplication. FinishedLaunching. З усім цим цілком можна жити, але StackOverflow programming вже не прокатує.
- Багато елементів в monodroid і в monotouch представлені як проксі до нативних об'єктів. І життєвий цикл їх слабо пов'язаний один з одним. Тому необхідно завжди пам'ятати про Dispose, інакше можливі витоки пам'яті.
- Налагоджувач досить повільний і не завжди стабільний. Однак, розробники постійно покращують його.
Підтримка
В одному з коментарів я бачив скаргу, ніби на StackOverflow дуже мало постів по monotouch і ще менше по monodroid. Скажу чесно, так і є. І в цьому немає нічого поганого, адже більшість питань щодо API можна легко знайти в темах щодо конкретної платформи і потім транслювати в C #. Правду кажучи, варто хоча б почитати про ObjectceC, так як багато особливостей синтаксису можуть бути не зрозумілі «з наскоку». При цьому саме monotouch спільнота показує серйозну активність. При розробці під Android Ви часто будете надані самому собі.
За наявності ліцензії Business Edition Вам відкривається «доступ до тіла» офіційної техпідтримки. Цілком швидкою і об'єктивною. На жаль, ні по одному моєму зверненню вони не змогли допомогти.
Кіну пару каменів у бік оновлень Xamarin: вони завжди сповнені сюрпризів. Наприклад, після переходу стандарту платформи з Silverlight на чистий .NET, проект просто перестав компілюватися. Так само часто зустрічаються баги середовища розробки, привносимі патчами. Тут порада тільки одна: координувати оновлення в команді і не оновлюватися перед релізом свого додатку.
Вивід
Чи варто? Однозначної відповіді немає. Далі буде виключно моя особисто думка, що не претендує на повноту і об'єктивність.
Вам варто спробувати Xamarin якщо:
- Ваш додаток повинен містити великий обсяг мультиплатформенного коду. Вирішення проблеми дублювання логіки часто важливіше потенційних проблем роботи з monotouch і monodroid.
- Вам необхідно розробити в стислі терміни додаток під кілька платформ. Знову ж таки, повторне використання коду в різних платформах дозволяє відчутно прискорити розробку. Тим не менш, варто пам'ятати, що вирішення багатьох проблем можуть з'їсти десятки людино-годин.
- Вам потрібно розробити невеликий додаток-прототип під IOS, але Ви не знаєте ObjectceC або Swift. При розробці прототипу, рахунок йде на години, які не варто витрачати на вивчення нової мови.
- Ви стартапер або інді розробник. У такому випадку, Ви можете не реалізовувати проблемні фітчі, а мультплатформенність дозволить заощадити дорогоцінний час.
Вам не варто використовувати Xamarin якщо:
- Ви розробляєте не мультиплатформенний додаток. Ніяка економія часу на вивчення нової мови не варта потенційних проблем.
- Ви розробляєте GUI орієнтований додаток. Деякі інтерфейсні патерни важко реалізувати на monodroid і дуже важко на monotouch, оскільки рішення за замовчуванням для тієї чи іншої фітчі спираються на милиці платформи, які можуть просто не працювати в Xamarin.
- Ваш додаток має задовольняти особливим вимогам стабільності. Дійсно часто виникають проблеми з боку платформи mono, monotouch і monodroid. Я б не радив ризикувати.
Ну і відповідь на класичне питання: якби можна було повернутися назад і вибрати для нашого проекту щось інше, я все одно б вибрав Xamarin.
