0,0
рейтинг
28 июля 2013 в 15:13

Разработка → Подробно о Xamarin из песочницы

Вы неплохо владеете языком C# и платформой .NET в целом? Вам надоело стоять в стороне и смотреть, как кто-то другой пишет крутые мобильные приложения вместо вас? У меня есть для вас кое-что интересное! То, что поможет вам изменить сложившуюся ситуацию и позволит писать отличные мобильные приложения, не требуя отдельного изучения Objective-C и Java. Я расскажу вам о продукте Xamarin. Подробно и правдиво.

Что это?



Xamarin — это фреймворк для кроссплатформенной разработки мобильных приложений (iOS, Android, Windows Phone) с использованием языка C#. Идея очень простая. Вы пишете код на своем любимом языке, с применением всех привычных для вас языковых фич типо LINQ, лямбда-выражений, Generic`ов и async`ов. При этом вы имеете полный доступ ко всем возможностям SDK платформы и родному механизму создания UI, получая на выходе приложение, которое, строго говоря, ничем не отличается от нативных и (по крайней мере по заверениям) не уступает им в производительности.

Фреймворк состоит из нескольких основных частей:

  • Xamarin.IOS — библиотека классов для C#, предоставляющая разработчику доступ к iOS SDK;
  • Xamarin.Android — библиотека классов для C#, предоставляющая разработчику доступ к Android SDK;
  • Компиляторы для iOS и Android;
  • IDE Xamarin Studio;
  • Плагин для Visual Studio.

Давай подробнее


Некоторое время назад достаточно широкую известность получили ряд фреймворков(например PhoneGap), которые предлагают разработку кроссплатформенных мобильных приложений на HTML5 с использованием JavaScript. Идея заключается в том, что приложение разрабатывается как обычный сайт для мобильных устройств с использованием соответствующих js-библиотек, например, Jquery Mobile. Затем все это упаковывается в некий контейнер, который для пользователя выглядит как нативное приложение. Минусы этих фреймворков очевидны: во-первых, вы не имеете доступа к нативным элементам UI. То есть даже если вы хотите использовать стандартную кнопку «Назад» для iPhone, вы должны ее нарисовать и сверстать. Во-вторых, вы получаете урезанный и обобщенный API для работы с платформой. Таким образом, те или иные фичи, присущие какой-то отдельной платформе будут вам недоступны. Ну и третье и самое важное — такое приложение физически запускается внутри браузера телефона (точнее внутри контрола WebView). Не нужно расписывать долго, что это значит: низкая производительность (особенно «хорош» WebView на старых версиях Android) и огромные проблемы с отображением (ну, господа, это же — браузер). Хотя, конечно, в определенных случаях эти фреймворки могут оказаться очень уместны.

Xamarin — это про другое. Т.к. я надеюсь, что мы здесь все — неглупые пацаны разработчики, я расскажу о том, как он устроен внутри. Это позволит понять потенциал данной технологии. Xamarin основан на open-source реализации платформы .NET — Mono. Эта реализация включает в себя собственный компилятор C#, среду выполнения, а так же основные .NET библиотеки. Цель проекта — позволить запускать программы, написанные на C#, на операционных системах, отличных от Windows — Unix-системах, Mac OS и других. Важно, что разработкой Xamarin занимаются те же люди, что и разработкой Mono. И (тут внимание) — это НЕ Microsoft со всеми вытекающими плюсами и минусами.

С точки зрения исполнения приложений между iOS и Android есть одно ключевое различие — способ их предварительной компиляции. Как известно, для выполнения приложений в Android используется виртуальная Java-машина Dalvik. Нативные приложения, которые пишутся на Java, компилируются в некий промежуточный байт-код, который интерпретируется Dalvik`ом в команды процессора в момент исполнения программы(т.е. аналогично тому, как работает CLR в .NET). Это так называемая Just-in-time компиляция (компиляция на лету). В iOS используется другая модель компиляции — Ahead-of-Time (компиляция перед исполнением). Xamarin учитывает это различие, предоставляя отдельные компиляторы для каждой из этих платформ, которые позволяют на выходе получать настоящие, нативные приложения, которые выполняются вне контекста браузера и могут использовать все аппаратные и программные ресурсы платформы.
Для iOS ситуация простая — никакой виртуальной машины нет и программный код должен быть просто заранее скомпилирован в машинный. Для этой цели используется AOT компилятор Mono.
Для Android интереснее. При компиляции приложения происходит перевод кода на C# в промежуточный байт-код, понятный виртуальной машине Mono и сама эта виртуальная машина также добавляется в упакованное приложение. И Mono и Dalvik написаны на Си и работают поверх ядра Linux (а мы помним, что Android основана на Linux). Вы уже понимаете, что происходит. При запуске приложения на Android обе виртуальные машины начинают работать бок о бок и обмениваются данными через специальный механизм wrapper`ов.

Это все хорошо, но давай ближе к разработке


Расскажу подробнее о самих библиотеках на примере Xamarin.iOS (Monotouch), т.к. опыта работы с ней гораздо больше, чем с Xamarin.Android (но там все аналогично).
Библиотека классов Monotouch.dll предоставляет доступ ко всем возможностям iOS SDK. Для разработчика — это просто набор C#-классов с хорошей аннотацией. Внутри эти классы используют разработанные инженерами Xamarin механизмы биндинга на нативные классы и методы. Важно, что этот же механизм можно использовать для биндинга любых библиотек, написанных на objective-c. Большинство классов и методов называются так же, как в оригинальном iOS SDK, хотя бывают исключения (в этом случае приходится использовать поиск в документации Xamarin по оригинальному названию, т.к. оно фигурирует в атрибутах биндинга). В классах активно используется механизм C# event`ов, что позволяет писать красивый и компактный код обработчиков с использованием лямбда-выражений:

button.TouchUpInside += (s, o) => {
    message.Text = "Hello!";
};

Да и в целом код, написанный на C# выглядит гораздо читабельней и приятней. Посмотрите разницу на примере кода, создающего строку с атрибутами:

Для асинхронной разработки Xamarin предоставляет возможность использовать как классы из пространства имен System.Threading.Thread и System.Threading.ThreadPool, так и полный спектр возможностей, предоставляемых Task Parallel Library. Использование последней, однако, считается предпочтительным. Кроме того, на момент написания статьи вышла очередная Stable версия, в которой появилась поддержка .NET 4.5, в частности, теперь можно использовать ключевые слова async/await. Хотя эта возможность была доступна и ранее, но для этого приходилось использовать beta-канал обновлений.

Что с ограничениями?


Ограничения в Xamarin.iOS связаны в основном с тем, что в iOS, как было сказано выше, в отличии от .NET и Mono нет виртуальной машины. Поэтому возникают трудности с поддержкой Generic. Причина ясна — на компилятор ложится задача проанализировать код и определить все возможные конкретизации в том или ином классе и методе. Отсюда возникают такие ограничения:

  • Не рекомендуется использовать Virtual Generic методы, т.к компилятор не всесилен и может не учесть все возможные варианты использования;
  • Нельзя создавать Generic-наследников от класса NSObject, который является базовым в иерархии Objective-C. Достаточно серьезное ограничение, которое может некоторым образом испортить вашу стройную и красивую архитектуру.

Другие ограничения, например, отсутствие поддержки динамической генерации кода, на мой взгляд, не слишком существенны. Подробнее о них можно прочитать здесь для iOS и здесь для Android.

Разработка UI


Для каждой платформы Xamarin предоставляет возможность использовать нативные средства разработки UI и нативные элементы пользовательского интерфейса. Для Android создание UI может происходить непосредственно в коде или же при помощи декларативного подхода с описанием интерфейса в XML. Для iOS это также либо код, либо использование нативных средств проектирования интерфейса — отдельные xib-файлы или же один большой Storyboard. Редактирование этих файлов происходит в привычной для iOS-разработчика среде XCode. И это означает, что вам потребуется Mac. Да, для разработки iOS-приложений вам в любом случае потребуется Mac по двум причинам:
Во-первых, как я уже сказал, для редактирования UI в среде XCode. Во-вторых, для отладки приложений требуется симулятор iPhone/iPad, который также доступен только на Mac.

Переносимость кода


Xamarin, по заявлениям разработчиков, является средством кроссплатформенной разработки, т.е. ожидаемо, что приложение, написанное один раз, может быть запущено на различных мобильных платформах. Но, в этом случае возникает конфликт с предыдущим пунктом. Как же так?

На самом деле ситуация обстоит следующим образом. Для каждой из платформы вам потребуется реализовать собственный слой UI. Т.е код, который отвечает за внешний вид приложения, вам придется написать для каждой платформы отдельно. Это цена за возможность использования нативных механизмов работы с UI. Если разбивать приложение на слои, то получается такая схема:

  • Data Layer (DL) – Хранилище данных, например, база SqlLite или xml-файлы;
  • Data Access Layer (DAL) – Обертка над хранилищем для осуществления CRUD-операций;
  • Business Layer (BL) – Слой, содержащий бизнес-логику приложения;
  • Service Access Layer (SAL) – Слой, отвечающий за взаимодействие с удаленными сервисами (Rest, Json, WCF);
  • Application Layer (AL) – Слой, содержащий платформозависимый код, другими словами, это код, который зависит от библиотек monotouch.dll или monodroid.dll;
  • User Interface Layer (UI) – Слой пользовательского интерфейса.

Кроссплатформенными являются все слои, расположенные выше Application Layer. Доля переносимого кода достаточно сильно зависит от самого приложения, но, на мой взгляд, она вряд ли может превысить 50-60%. Инженеры Xamarin это понимают, поэтому стремятся к увеличению этой доли. В качестве достижений в решении этой проблемы можно рассматривать библиотеку Xamarin.Mobile. Она предоставляет единый для различных платформ API для работы с камерой, контактами и гео-локацией. Но использование этой библиотеки никак не ограничивает вас в применении платформозависимого API, например, с помощью механизма делегатов.

Сторонние компоненты


У Xamarin существует собственный магазин сторонних компонентов Xamarin Components.Он интегрируется в IDE и позволяет в несколько кликов подключать к вашему проекту различные компоненты, написанные как инженерами Xamarin, так и сторонними разработчиками. Количество компонентов, кстати, растет как на дрожжах. Есть как платные, так и бесплатные(на данный момент их большинство). Все компоненты можно разделить на две части. Одни предоставляют дополнительные элементы пользовательского интерфейса, другие являются библиотеками классов. Например вариант для Mono известной библиотеки для работы с Json — Json.NET или же библиотека для взаимодействия с Rest-сервисами — RestSharp. Не все компоненты кроссплатформенные, многие доступны только для конкретной платформы. Как я упоминал выше, Xamarin использует механизм биндингов для связывания с нативными библиотеками классов, что позволяет портировать на C# любые нативные библиотеки классов. Кроме того, для Xamarin.iOS, например, существует специальная утилита, которая умеет генерировать такие биндинги автоматически. Собственно это позволяет инженерам Xamarin поспевать за всеми нововведениями iOS. Так, в частности, в Xamarin.iOS практически сразу после выхода появилась возможность использовать Dropbox API, а так же новые фичи iOS 7.

Документация и комьюнити


Xamarin имеет отличную документацию, содержащую подробные руководства, сниппеты, а также внушительную базу примеров. Документация непосредственно по всем классам библиотек Monotouch и Monodroid являются частью общей документации Mono. Но, к сожалению, этого все равно недостаточно, чтобы покрыть весь пласт вопросов, которые могут возникать в процессе разработки. У Xamarin существует комьюнити разработчиков, которое сконцентировано на официальном форуме и на StackOverlow. Активностью и инициативностью людей в комьюнити похвастаться не могу. Из пяти вопросов, заданных на официальном форуме, ответ я получил только на один. Может быть, не то спрашивал. В этом плане неоценимую помощь оказала приватная тех. поддержка с инженерами по электронной почте, доступная в business-лицензии. Отвечают, как правило, в течении нескольких часов и не стандартными отписками «попробуйте выключить и включить», а действительно разбираются в проблеме и помогают ее решить. Следует понимать, что база вопросов и ответов, накопленная для нативной разработки гораздо шире, чем для Xamarin, поэтому, как бы вы ни хотели, вам придется разобраться в специфическом синтаксисе objective-c (c Java проблем быть не должно), чтобы понимать примеры кода на том же StackOverflow. Кроме того, это откроет вам доступ к прочтению и пониманию официальной документации для платформы, что на определенном этапе может стать очень важно. С другой стороны, в этом есть и положительный момент: получив такой базис, вам будет проще перейти к нативной разработке при необходимости.

Среда разработки


Разработчики Xamarin в качестве среды разработки предлагают использовать либо собственную IDE — Xamarin Studio, либо Visual Studio (в business-лицензии, об этом ниже).

Xamarin Studio


Xamarin Studio — кроссплатформенная IDE, которая работает как на Mac OS X, так и на Windows. На вид эта она выглядит очень простой и дружелюбной, однако за внешней простой скрывается достаточно мощный инструмент, который включил в себя множество фич, привычных нам в Visual Studio и Resharper:
  • Приятная подсветка синтаксиса;
  • Автодополнение кода (включая возможность одновременного импорта namespaces);
  • Удобный универсальный поиск по названиям файлов, типам, членам классов и т.п;
  • Развитые возможности навигации по проекту: Быстрый переход к описанию класса, переход к базовому классу, список мест использования класса и т.д.;
  • Различные механизмы рефакторинга и быстрая подсказка (как alt+Enter в Resharper);
  • Достаточно развитые механизмы дебага, включая слежение, просмотр текущего значения переменной при наведении, визуализацию потоков и аналог Immediate window в VS;
  • Встроенная интеграция с системами контроля версий: SVN, Git и TFS (для TFS, правда, нужны сторонние утилиты);

Время горькой правды! В процессе использования открылись и другие интересные особенности. Я использовал Xamarin Studio на Mac, поэтому все нижесказанное относится именно к Mac OS X:
  • Горячие клавиши (включая copy-paste) работают только в английской раскладке. Разработчикам известно об этой проблеме. Баг в багтрекере заведен;
  • Периодически, при попытке поставить breakpoint студия виснет. Несмотря на наличие механизма автосохранения, это немного расстраивает.
  • При использовании встроенной интеграции с SVN добавление новых файлов в проект не отслеживается автоматически. Т.е. изменение в файле .csproj зачекинятся, а сами файлы — нет. По каждому файлу нужно кликать правой кнопкой и добавлять его в репозиторий. Техподдержка сообщила, что им известно об этом баге и они исправят его в одном из ближайших обновлений.
  • Иногда проект перестает компилироваться. Лечится перезапуском студии.
Справедливости ради стоит отметить, что обновления для Xamarin Studio на beta-канале выходят очень часто, по моими ощущениям — минимум раз в неделю, а то и раз в день.

Visual Studio


Xamarin предлагает возможность вести разработку в Visual Studio после установки специального плагина, который доступен в business-лицензии (на момент выхода статьи — 999$), но есть месяц триала. Плюсы очевидны: вы становитесь разработчиком мобильных приложений, не меняя места дислокации, и можете использовать всю тяжелую артиллерию в лице Resharper и других ваших любимых плагинов. После установки плагина для Visual Studio вам потребуется настроить соединение с вашим Mac, которое будет использовано при запуске проекта на выполнение. Т.е. после запуска, приложение автоматически пересылается на Mac, где компилируется и загружается либо на симулятор либо на устройство, при этом сам процесс процесс отладки, расстановка брейкпоинтов и т.д. будет происходить в Visual Studio.
Вариантов работы в Visual Studio несколько. Либо вы используется виртуальную машину внутри Mac (например Parallels), куда ставите Windows и Visual Studio. Либо используете две разные физические машины, при этом использовать один Mac для нескольких PC-разработчиков затруднительно, т.к. отладка требует манипуляций с симулятором. И последний вариант — использовать виртуальную машину с Mac OS X (так называемый hackintosh). Вполне себе жизнеспособный вариант, хотя и есть некоторые ограничения. Например, в Xcode придется перемещаться по Storyboard только с использованием полос прокрутки, т.к. windows-мышь не очень похожа на настоящую мышь от Mac со всеми вытекающими.

Время горькой правды. С отладкой в Visual Studio периодически возникали проблемы. Самая заметная — это то, что при удаленной сборке приложения, процесс отладки мог отвалиться по таймауту. Хотя, опять же, стоит отдать должное разработчикам — они исправляют ошибки достаточно интенсивно, и вот уже на момент написания этой статьи, процесс отладки стал стабильным. Хотя и стоит заметить, что на текущий момент, времени между запуском приложения и появлением его на экране симулятора при использовании Visual Studio требуется несколько больше, чем при использовании Xamarin Studio на Mac.

Лицензии


На момент написания статьи Xamarin имеет следующие типы лицензий:

  • Starter — Бесплатно. Рассчитан скорее для ознакомления, т.к. имеет ограничение на размер приложения (по ощущениям очень не большой, т.к. не компилировались даже некоторые sample-проекты) и на использование сторонних компонентов;
  • Indie — 299$ на одно рабочее место. Снимается ограничение на размер приложения. Разработка возможна только в Xamarin Studio;
  • Business — 999$ на одно рабочее место. Появляется возможность разработки в Visual Studio и приватная тех. поддержка от инженеров Xamarin;
  • Enterprise -1899$ на одно рабочее место. В рамках этой лицензии предоставляется возможность получения Hotfixes (не вижу особого смысла, т.к. обновления и так выходят очень часто), а так же возможность отправить инженерам проект с исходным кодом и сказать «Что-то у меня не получается поменять ширину ячейки в таблице, помогите!». Плюс ряд не слишком полезных, на мой взгляд, опций.

Обращаю внимание, что для каждой платформы (iOS, Android) нужна отдельная лицензия. Несмотря на то, что у Business-лицензии написано «per developer» на текущий момент каждая лицензия может быть активирована на 4-ых рабочих станциях и эти рабочие станции можно менять. Т.е. гипотетически одну лицензию могут использовать два разработчика при том, что каждый из них будет использовать для разработки Visual Studio.

Заключение


На текущий момент технология Xamarin является серьезным инструментом для решения сложных задач в области разработки мобильных приложений. Несмотря на это, команда разработчиков не останавливается и продолжает его активное развитие и улучшение. За последние два месяца заметны серьезные улучшения в общей стабильности продукта. На мой взгляд у технологии большое будущее и с каждым днем число разработчиков, использующих ее в качестве основного фреймворка для разработки будет неуклонно расти. Однако довольно высокая стоимость лицензии может стать препятствием для использования на пути indie-разработчиков. В целом свой опыт работы с данным фреймворком считаю положительным и продолжу его использование.

Скачать фреймворк можно на официальном сайте — www.xamarin.com. Отличные руководства для старта: iOS, Android.
Спасибо всем, кто нашел в себе силы дочитать до конца :)
Андрей Шелёхин @AndreyShelehin
карма
20,2
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

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

Самое читаемое Разработка

Комментарии (59)

  • +2
    В нашей компании — Touch Instinct — пишем, используя технологии Xamarin. В общем, все заказчики очень довольны :)
    • +1
      Видел ваш Range Slider в магазине компонентов :) К сожалению, его внешний вид не кастомизировался. Пришлось написать свой.
  • 0
    Интересный инструмент, надо обязательно попробовать, пожалуй, Obj-C и время вхождения — это все что меня останавливалось начать разработку на мобильных платформах.

    ps Хорошо бы еще добавить прямые ссылки на скачку, я лично против сбора такой инфы через анкеты.
  • 0
    Я так понимаю, разрабатывать на Xamarin имеет смысл только если приложение содержит много бизнес-логики, чтобы не надо было ее переносить между платформами?

    Потому что UI в любом случае приходится разрабатывать отдельно под каждую платформу.

    То есть например если у нас клиент-серверное приложение, и вся бизнес-логика на сервере а клиентская часть просто отображает данные, которые получает с сервера используя RESTful API — по сути, никакого особого выигрыша по сравнению с «нативной» разработкой под каждую платформу мы не получим?
    • +5
      Да, в этом случае выигрыш в плане переносимости кода будет несущественным. Однако опять же, если вы любите и пишете на C#, то вам в любом случае будет приятнее вести разработку на Xamarin.
    • 0
      По сути да. Малую часть кода перенести все же можно, но родные инструменты все же всегда лучше.
    • 0
      Процент общего кода можно ещё повысить если использовать библиотеки(фреймворки) вроде MVVMCross. Но, как всегда, инструмент нужно выбирать под задачу.
  • 0
    Кстати, вот недавно попытался создать PCL в Xamarin на Mac, но в таргетах можно выбрать только .net 4, silverlight, xbox 360, windows phone 7, и сборка даже не компилируется и никаких намеков на 4.5. Хотя обновил до последней версии, MDK до 3.2.0 обновил.
    Вы случайно с такой проблемой не сталкивались?
    • +2
      Поддержка .NET 4.5 в Stable версии вышла 26 июля. Попробуйте обновиться.
    • 0
      3.2.0 нестабильна еще, попробуйте 2.1 или 3.1.2
      Mono 3.2.0 update breaks PCL support

      • 0
        Спасибо огромное! Действительно помогло
  • +2
    сравнение кода на Objective-C с C# — ересь полная. Маркетологи вступают в дело.
    В Objective-C, конечно, побольше текста по сравнению с C#, но этот конкретный пример отстал от реальности эм… года на полтора

    Objective-C вариант, наши дни:

      NSDictionary *  attrs = @{
         NSFontAttributeName : [UIFont systemFontOfSize:12],
         NSForegroundColorAttributeName : [UIColor blackColor],
      };
        
      NSAttributedString * string = [[NSAttributedString alloc] initWithString:@"Hello, world" attributes:attrs];
    
    • +6
      Согласен, я долго думал, стоит ли включать это конкретное сравнение в статью. Когда мне приходится переносить некоторый код из objective-c на C#, объем кода отличается, но не в разы. Однако, стройный синтаксис C# в связке с лямбда выражениями делают его гораздо понятнее. Конечно, если вы не первый код пишете на Objective-C, для вас это может быть не слишком актуально.
      • +1
        Зря включили, статья сразу получила соответствующий уклон.
      • –1
        Насчет стройности итд — я бы лично поспорил. После нескольких лет работы с ObjC работать с ним получается очень удобно. У шарпа как и у Java есть свой минус — очень много лишней информации для стороннего программиста. В ObjC можно гораздо точнее разделять код, который стоит видеть другим программистам (.h) и реализацию. Плюс саму реализацию можно разделять хоть на 10 частей (файлов), если функционал уж совсем большой. На шарпе Partial не сильно выручают, потому что все равно реализация идет сразу с интерфейсом. Можно выделять интерфейсы, но тогда кода станет еще больше.
    • +11
      Все равно, работа с обычными типами — строками, датами — в ObjC ужасная, а на .NET — вменеямая. Например, сколько строк кода надо на ObjC чтобы написать DateTime.UtcNow.ToShortDateString()?
      • +3
        Можно подумать, что я собирался спорить, что на Obj-C писать меньше надо. Чаще всего больше. Может, быть даже всегда.

        Я говорю о том, что создается ощущение, что примеры на Objective-C на Xamarin'е писали люди, ОЧЕНЬ давно писавшие на Objective-C, и не самым лучшим образом )

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

        Но ведь можно определить для проекта свой [NSDateFormatter sharedFormatter] (например через категорию), и получим аналогичное решение в одну строчку.
        А как будет выглядеть на C# следующее объявление:

        И очень хочется посмотреть на аналогичную C# реализацию вот такого кода:
        • +8
          Вот так, примерно:
          UIView.Animate(0.25, () => someView.Alpha = 1, () => {
          	UIView.Animate(0.25, 3, (UIViewAnimationOptions)0, () => someView.Alpha = 0, () => someView.RemoveFromSuperview());
          });
          
          • +1
            С async/await
            void async AnimateSome()
            {
                await UIView.AnimateAsync(0.25, ()=>someView.Alpha = 1)
                await UIView.AnimateAsync(0.25, 3, (UIViewAnimationOptions)0, () => someView.Alpha = 0)
                someView.RemoveFromSuperview()
            }
            


            Хотя я нежно люблю Objective-C за ясность, некоторую приятную мнгословность и безусловную логичность, в асинхронном программирование C# куда выразительней.
      • –2
        Разница лишь в привычке, кто к чему привык. При этом стоит помнить, что Objective-C только для Mac/iOS, а в данной ветке речь про C# для всех подряд платформ, включая и iOS, и тут сам язык не сравнить, т.к. он полностью зависит от разработчиков Mono и Xamarin, например упомянутый вами DateTime.UtcNow.ToShortDateString не работает под iOS, это баг. Так что может данный случай на C# и быстрее написать, но, как всегда с MSFT — он не работает.
        При этом если сравнивать основные платформы ObjC и основные платформы C# то тут у шарпа шансов вообще нет.
        • 0
          Основы? это типа динамическая типизация и массивы всего чего угодно? Или специфические названия функций, которые в целом улучшают читаемость (дают большее представление о том что функция делает)?
          Это все на вкус и цвет. Мне, например, не нравится, что очень часто ошибка проявляется только где-то в рантайме. (приходилось пару раз вечер после работы отлаживать чухой код, который на C# не скомпилируется с подобной ошибкой). Возвращение nil'ом nil тоже выглядит прикольно. Но опять же, скрывает некоторые ошибки до рантайма. Что опять же не есть гуд. Или вы имели ввиду что-то другое?

          А что не так с DateTime.UtcNow.ToShortDateString? Всегда работало и сейчас только что проверил — работает. Был косяк в моно с MonthDayPattern для русского языка (было 30 Июль), но с последним релизом моно это исправили, правда они восстановили косяк сильверлайта (июля 30). Но это все можно обойти нативными функциями или вручную прописать шаблон.

          Что мне нравится в Xamarin.iOs — это работа с CoreGraphics. Не нужно писать все в C-style (Да именно в C, а не C++ или Obj-C).
  • +6
    Достоинства перечислять скучно, с ними все ясно :) Напишу про недостатки платформы, благо уже больше полугода плотно с ней работаю (помимо перечисленных).
    1. Регулярное переколбашивание фреймворка и продуктов. Внезапное возникновение багов в тех местах, где они уже были пофикшены год назад. Это несколько утомляет.
    2. Профайлер под Mono доступен только в бизнес версии, о чем на сайте ни слова. Однако нативный профайлер для iOS все равно намного лучше, так что это не проблема.
    3. Интеграция с xcode сделана так себе, вызывает регулярные проблемы. С другой стороны, xcode в принципе это тихий ужас. В итоге интерфейсы лучше всего создавать из кода c#. Проще поддерживать и менять.
    4. Очень своенравный сборщик мусора, к которому нужно приноравливаться. Имеет тенденцию поджирать объекты которые вы еще вовсю используете. Причем поведение разнится на реальном устройстве и в симуляторе.

    Тем не менее, если бы я еще раз выбирал инструменты для мобильной разработки, выбор все так же однозначно упал бы на Xamarin.
  • 0
    Также сталкивался с проблемами 1 и 3. Но, последние обновления значительно улучшили ситуацию. Теперь сбои если и происходят, то редко. Насчет интеграции с Xcode. В качестве механизма для описания UI выбрал Storyboard и на текущий момент несколько раз уже пожалел. Во-первых это гигантский XML, который очень тяжело мерджится в случае, если над проектом работает несколько человек. Кроме того, как оказалось, пользы от «drag-n-drop» перетаскивания контролов на экраны практически никакой. Потому что практически на всех экранах используются кастомные View и динамическое добавление элементов управления. В итоге нашлась отличная библиотека для Xamarin — XibFree. Она значительно упрощает механизм создания интерфейса в коде, при этом позволяет избежать нудного рассчета положения каждого элемента при добавлении.

    Черт, промахнулся веткой.
    • 0
      Спасибо за ссылку на XibFree, гляну. Т.к. проблема стоит в полный рост. От сторибордов действительно одни проблемы. Каркас накидать еще нормально, но делать что-то сложное — вешалка.
      Лично я пользы от статических xib не вижу не только из-за динамического количества элементов, но и от того, что в iOS в отличие от того же WP контролы динамически не ресайзятся по содержимому и нет нормальных гридов. Это все нужно делать руками, в итоге рисование интерфейса в интерфейс билдере становится какой-то совершенно лишней стадией. Текущий проект начинал на storyboard+xib, сейчас же остался огрызок сториборда, а xib вообще все выкинул :)
      • 0
        Аналогично. Сейчас от Storyboard остались только связи между экранами. В следующих проектах все буду делать исключительно через код и эту библиотеку. Работа с TableVIew в CocoaTouch вообще шокировала с плохой стороны.
      • 0
        Насчет динамического ресайза — Auto Layout не помогает?
        • 0
          Так это же все равно нужно все задать вручную. Сравните с гибкостью гридов в WP. Там просто верстаешь таблицами и не пытаешься издеваться над каждым из элементов.
          Плюс, например, задачка: текстовое поле, увеличивать его до тех пор, пока в нем не будет трех строчек, а когда будет три строчки — обрезать. Я вот фиг знает, как это решать если не из кода.
          • 0
            Замените таблицы на View в качестве контейнеров с зависимостями между ними, получится то же самое. Гридами и таблицами — согласен, удобно, да и привычно еще с древних html времен. Но для мобильных интерфейсов и без гридов очень удобно.
            Для текстового поля — задайте диапазон высоты элемента (min/max), чтобы влезало от 1 до 3 строк, и все.
  • 0
    А есть какие-нибудь удобные рисовалки/конструкторы GUI из компонентов?
    Впечатление, что GUI создается так же неудобно как в Windows 3.1 API на C++
    (там были какие-то вызовы, свой цикл обработки сообщений, файлы ресурсов, вообщем много всего «интересного и приятного»),
    сравните с WInForms и WPF, но вот беда приложений под венду стало столько, что якобы уже тяжело «пробиться»

    И наверно, когда мобильный GUI будет создаваться просто и удобно, инструменты будут доступны по цене,
    приложений будет уже так же много как под венду, и появится ли к тому времени такой же сдвиг как MS->Google/Apple еще неизвестно
    сейчас происходит смещение от Proprietary Windows к OpenSource Linux в области пользовательских смотрелок
    а потом куда и зачем переходить, с линукса на freebsd? интерфейсы конечно будут очеловечиваться (общение словами и т.п.),
    но наврядли Google сдаст свои позиции в ближайшие лет 10-20

    С учетом этого, наверно, выгоднее использовать PhoneGap+asp.net+DevExpress наборы с уже существующими skils-ами, без всяких зависаний у разработчика
    • 0
      т.е. заказные custom business приложения еще долго можно клепать на WinForms DevExpress, а чтобы что-то маленькое, полезное и не очень ресурсоемкое по разработке, наверно лучше пытаться популяризировать в растущем рынке мобил.
    • 0
      Ничего похожего на блендер для monotouch к сожалению нет.
    • +1
      Вы еще смотрите по скорости. Xamarin дает практически нативную скорость исполнения. Вам может показаться это не важным, но на мобильных устройствах проблема ресурсов стоит в полный рост. Самую банальную плавную прокрутку списка с «богатыми» элементами можно сделать хорошо на obj-C или на monotouch, а вот в webview уже не сделаешь.
  • 0
    Кто-нидудь в курсе, нету ли у Xamarin упрощённых лицензий для студентов, например с запретом на коммерческое использование или подобных?
    А то очень хочется попробовать но цена даже за Indie кусается, а в ограничения Starter на размер и неподключение сторонних библиотек уже упёрся.
    • +1
      После скачивания фреймворка первый месяц вы можете бесплатно пользоваться всеми фичами, доступными в Business-лицензии. За исключением приватной тех. поддержки, пожалуй. Про отдельные условия для студентов, к сожалению, нет ни слова.
    • +1
      Нет, только инди. Раньше была хорошая бесплатная лицензия в Monodevelop, которая позволяла разрабатывать сколько угодно до тех пор, пока тебе не нужно выкладывать код на реальное устройство, но кажется в феврале они обновили продукты + ограничили максимальный размер приложения, причем очень сильно. Как раз в это время пришлось купить лицензию.
      Попробовать можно месяц бесплатно.
      • 0
        Эх, жаль, спасибо за ответ.
        • +1
          Второй год пользуюсь бизнес версией Xamarin со студенческой скидкой. Что характерно, учусь заочно и не в первый раз, но формально, документы есть и их этот вариант устраивает.
          Напишите им, спросите, обсудите варианты.
  • 0
    А еще Xamarin купили разработчиков Calaba.sh и продвигают тестирование приложений в своем облаке Xamarin Test Cloud. Облако — так себе, но Calabash стал развиваться побыстрее
  • 0
    для проекта, собранного на Xamarin, требуется устанавливать еще что-то дополнительное? Точнее где располагается иртуалная машина mono? Она добавляется в каждый проект или требует отдельной установки? Как при этом выглядит сам проект целиком — на сколько увеличивается размер при написании «родными» средами, на сколько уменьшается скорость выполнения при обработке в «параллельной» виртуальной машине? Проводили ли вы такое сравнение? Не интересует суперновые компоненты, которых нет среди стандартных. Но интересно сравнение по скорости и по объему кода для «хэллоу ворлд» с использованием допустим ListView и подобного аналога в Mono.

    почему спрашиваю? сейчас у нас обсуждается перевод всех продуктов на C#, неплохо было бы еще достоинства и недостатки знать и учитывать.
    • 0
      Mono Runtime тащится с собой в каждом приложении. Если я ничего не путаю, то это несколько мегабайт. Это, кстати, можно на бесплатной лицензии проверить.
      По скорости работы, была проблема в Android при сборке мусора. Связана была с одновременной работой двух сборщиков: Mono и Dalvik. Но с этой проблемой сталкиваются не все.
      • 0
        Объем приложения для hello world для последней версии monotouch — около 3х мб. Из релиз-инфо:

        An «Hello World» application is now less than 3MB, 12% smaller than 6.2.x.
  • –1
    Сейчас меня закидают помидорами, но как обстоят дела с лекарством? А то «пробовать» софт за 200 зелёных — жирно будет. Предпочёл бы пробовать без ограничений по размеру, времени и фичам, а покупать — если решусь.
    • 0
      насколько я в курсе, приложения до 64Кб можно разрабатывать халявно (Starter Edition)
      • 0
        64K — это как-то слишком сурово, по-моему. Только поиграться с приложениями на пару кнопок, серьёзно не оценить.
    • +3
      Посмотришь на активность минусующих (в том числе особенно неленивых минусующих) — и создаётся впечатление, что на Хабре у всех только честно купленный лицензионный и опен-сорсный софт, а про Пиратскую Бухту и РуТрекер никто никогда не слышал.

      Не верю. Не в стране, которая исправляет яркость фоток любимого кота в последней версии фотошопа.
      • +5
        На Хабре ж все типа разработчики и дизайнеры, поэтому пиратский софт и копирование чужого дизайна — это фу, а фильмы и музыка из торрентов — это ок.

        Мнение по теме:
        В продукте, основной фичей которого является кроссплатформенная разработка, брать деньги за каждую платформу отдельно — это как-то неправильно. И для некоммерческого использования (например, без права публикации в аппсторах и т.п.) можно было бы сделать бесплатную лицензию. Чтобы какой-нибудь начинающий разработчик мог полгодика поковыряться, накропать кроссплатформенное приложение не задумываясь о лицензии, потестить на собстенном устройстве, а перед публикацией уже купить подходящую лицензию.
    • –1
      По моему некультурно спрашивать про лекарство в комментарии к статье где рассказываться о продукте.
      • 0
        Если бы владелец или разработчик продукта о нём рассказывал — да. А здесь статья от того, кто продуктом пользуется.
  • 0
    Разрабатывал игру на MonoGame, столкнулся с проблемой — подключение нативных Java библиотек, писать код по сути на JNI — тихий ужас.
    • +2
      В Xamarin.Android есть специальный тип проекта — Java Binding Library.
      При этом получается использовать «нативные» Java-библиотеки очень просто — в Java Binding Library добавляется jar-файл, и после компиляции получается .Net dll-ка, содержащая необходимый нам Java-код с .Net-интерфейсом. При этом вся JNI-обертка делается автоматически.
  • +1
    К сожалению с портабельностью кода на Windows Phone и Windows 8 не все просто — Microsoft уже сами ушли от System.Data, System.XML, System.IO, System.Graphics, к которым все привыкли и теперь код на Mono выходит даже «более .Net», чем для ".Net 4.5 For Windows Store". Решается, конечно, собственными Backwards Compatibility Library или еще более абстрактным уровнем в ядре приложения.
  • 0
    К сожалению отпугивает отсутствие бесплатной лицензии хотя бы для некоммерческих проектов. Для игр есть Unity 3D который тоже кроссплатформенный, тоже C# имеет достаточно мощную бесплатную версию почти для всех платформ (скоро будет поддерживать бесплатно Blackberry и Windows 8/Phone).

    Ради самостоятельных неигровых экспериментов и некоммерческих проектов без конкретных целей по заработку платить 300 баксов как-то не хочется. Хотя конечно организаций это все не касается.
  • 0
    включая возможность одновременного импорта namespaces
    == вот почему-то этой фичи не увидел. Подскажите, как она работает?
  • 0
    А есть ли какие-то аналоги?
    • 0
      Для .NET — www.dot42.com
      Для кроссплатформенности — QT и куча HTML хреновин.
      Если ещё куча просто хреновин, но там все плохо, в основном.
  • +1
    А можно ли как-то запустить свое приложение на iДевайсе без сертификата разработчика? В гугле нашел мануалы только для xcode

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