Xamarin. За и против

image

Наверное, каждый .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 не сложнее – возможности ObjectiveC изящно покрываются в языке 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#. По правде говоря, стоит хотя бы почитать про ObjectiveC, так как многие особенности синтаксиса могут быть не понятны «с наскока». При этом именно monotouch сообщество показывает серьёзную активность. При разработке под Android Вы часто будете предоставлены самому себе.

При наличии лицензии Business Edition Вам открывается «доступ к телу» официальной техподдержки. Вполне быстрой и объективной. К сожалению, ни по одному моему обращению они не смогли помочь.
Кину пару камней в сторону обновлений Xamarin: они всегда полны сюрпризов. Например, после перехода стандарта платформы с Silverlight на чистый .NET, проект попросту перестал компилироваться. Так же часто встречаются баги среды разработки, привносимые патчами. Тут совет только один: координировать обновления в команде и не обновляться перед релизом своего приложения.

Вывод

Стоит ли? Однозначного ответа нет. Далее будет исключительно мое лично мнение, не претендующее на полноту и объективность.

Вам стоит попробовать Xamarin если:

  • Ваше приложение должно содержать большой объем мультиплатформенного кода. Решение проблемы дублирования логики зачастую важнее потенциальных проблем работы с monotouch и monodroid.
  • Вам необходимо разработать в сжатые сроки приложение под несколько платформ. Опять же, повторное использование кода в различных платформах позволяет ощутимо ускорить разработку. Тем не менее, стоит помнить, что решение многих проблем могут съесть десятки человеко-часов.
  • Вам нужно разработать небольшое приложение-прототип под IOS, но Вы не знаете ObjectiveC или Swift. При разработке прототипа, счет идет на часы, которые не стоит тратить на изучение нового языка.
  • Вы стартапер или инди разработчик. В таком случае, Вы можете не реализовывать проблемные фитчи, а мультплатформенность позволит сэкономить драгоценное время.

Вам не стоит использовать Xamarin если:

  • Вы разрабатываете не мультиплатформенное приложение. Никакая экономия времени на изучение нового языка не стоит потенциальных проблем.
  • Вы разрабатываете GUI ориентированное приложение. Некоторые интерфейсные паттерны тяжело реализовать на monodroid и очень тяжело на monotouch, так как решения по умолчанию для той или иной фитчи опираются на костыли платформы, которые могут попросту не работать в Xamarin.
  • Ваше приложение должно удовлетворять особенным требованиям стабильности. Действительно часто возникают проблемы со стороны платформы mono, monotouch и monodroid. Я бы не советовал рисковать.


Ну и ответ на классический вопрос: если бы можно было вернуться назад и выбрать для нашего проекта что-либо другое, я все равно бы выбрал Xamarin.
Поделиться публикацией
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама

Комментарии 31

    0
    Интересно, а работа с Bluetooth SPP нормально реализована в новых версиях monotouch или monodroid?
      +1
      Никогда с этим не работал, но классы, по крайней мере на андроиде есть
           Android.Bluetooth.BluetoothDevice device;
           device.CreateRfcommSocketToServiceRecord(uuid);
      
        0
        Классы есть, но я очень сильно обманулся с ними в свое время.
          0
          А что именно не так?

          Мы в команде в свою очередь натыкались на трудности обхода бага в TextView, когда тег <im> рисуется жирным, а <strong> курсивом. Решения на StackOverflow предлагали задействовать парсер XML, который в Xamarin не поддерживается.
            0
            Я уже погуглил, вроде уже все нормально работает, правда, для каждой платформы придется писать отдельный блютуз модуль. А проблема была простой, у меня датчик раз в секунду посылал пакет данных, но вот узнать, есть ли данные в буфере или нет было сложно, т.к. соответствующий метод available (вроде так) на пустом буфере у меня крашил все приложение.
              0
              Можно написать универсальный блютус-модуль и продавать его через components.xamarin.com/ ;)
      +5
      На реальном проекте все пришло к тому, что я выучил Objective C (проект под Windows + Mac).
        0
        Кстати да, это один из плюсов Xamarin — очень плавное обучение другим платформам с возможностью последующего перехода ;-)
          +6
          Как незаметно можно недостаток превратить в достоинство!
            0
            И это правда: поневоле начинаешь изучать специфику ObjectiveC и Java. На мой взгляд — это бесценный опыт.
        +3
        •Вы разрабатываете GUI ориентированное приложение. Некоторые интерфейсные паттерны тяжело реализовать на monodroid и очень тяжело на monotouch, так как решения по умолчанию для той или иной фитчи опираются на костыли платформы, которые могут попросту не работать в Xamarin.

        За андроид не скажу, но мне очень интересно, что именно у вам не получилось реализовать в Xamarin.iOS?
          0
          В крайнем случае, есть возможность собрать библиотеку из нативного кода и подключить к проекту.
          Я именно так и делаю, весь интерфейс нативный, на objective-c(ios) и java(android), а бизнес логику пишу уже на C#.
            +2
            Можно и так, но я не вижу нужды делать ВЕСЬ интерфейс на родном языке. Особо сложные контролы — вероятно. Но большую часть UI можно спокойно писать в Xamarin.
              0
              Поддерживаю. И я не вижу в этом нужды.
                0
                А почему делаете так, если не секрет? Ведь появляются накладные расходы на связывание интерфейса и бизнес-логики?
                  0
                  Недостаток времени на борьбу с возможными подводными камнями в UI части Xamarin.(iOS/Android). Пока идет освоение этого инструмента.
            0
            Например, модальный DateTime picker, «выезжающий снизу». Сам пикер реализовал через InputView, а вот с модальностью возникли проблемы: GestureRecogniser работает не очень корректно, так что пришлось перехватывать события в контролах.
              +3
              Вот буквально только что реализовал модальный датапикер на Xamarin ровно так же, как реализовывал его в Obj-c. Несколько не понял, в чем у вас проблема и почему нельзя было использовать UIDatePicker?
                0
                Я использовал UIDatePicker. Проблема как раз в модальности.
                  0
                  А в чем проблема с модальностью? Там все 1:1 где я сталкивался.
                    +1
                    Кладёте subview в Window или в RootViewController. С помощью UIView.BeginAnimation() делаете красивое выезжание-появление. Тулбар, затеняющая вьюшка по вкусу.
                      0
                      Спасибо. Попробую. Не хватает кармы что бы плюсануть.
              0
              А как же вопрос с лицензией? Если уж взвешивать, то все факторы.
              Вы стартапер или инди разработчик.

              Особенно для этой группы разработчиков
                +1
                300 долларов в год стоит лицензия инди разработчика. Зато экономится несколько рабочих мест при мультиплатформенной разработке.
                  0
                  Но это лицензия на одну платформу. Если нужна кроссплатформенность, то логично, что будет уже 540. Хотя если нужны только Windows(Mobile) и iOS/Android, то да.
                    +3
                    Инди разработчиков не останавливает это от использования Unity.
                    И во-вторых если вы стартап или малый бизнесс просто напишите и возможно договоритесь о какой-то скидке store.xamarin.com/ «Are you a startup or small business? Contact us.»
                      +1
                      Они охотно идут навстречу — 2 года назал в ответ на такой запрос мне продали лицензию за 80 долларов.
                        0
                        Пару недель назад мы(стартап) писали им. Они предложили скидку в 20% на бизнес версию. А на инди скидки не предложили.
                          0
                          Было бы интересно увидеть два примера письма ))
                          Может в этом дело? А может и в том, что 2 года назад они заботились о лояльности разработчиков, а пару недель назад о собственном финансовом благополучии.
                            0
                            Я им честно написал, что собираюсь писать мелкие хобби-програмки не ради заработка а ради развлечения. Может это сработало.
                +2
                ПОСРЕДСТВОМ!

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

                Самое читаемое