Xamarin что это такое, кому стоит использовать и ответы на другие важные вопросы о фреймворке


Оглавление (нажмите, чтобы открыть):

Стоит ли использовать Xamarin?

В компании дали задание разобраться с вопросом: стоит ли нам использовать Xamarin и что нас ждет?
Компания все свою жизнь работает с .Net. Есть некоторый опыт разработки на Java под Android. С iOS не работали ни разу.
Больше всего привлекает возможность создания кросплатформенных приложений на C#, но только стоит ли оно того.
Как вы считаете стоит ли смотреть в сторону Xamarin и что ждет впереди в случае выбора этого направления. Насколько все будет больно?)
Благодарю за возможные советы, подсказки и напутствия))

17.07.2020, 22:25

Отличие Xamarin.Forms Xamarin.Native
Всем доброе время суток. Объясните пожлуйтса новичку в Xamarin правильно ли я понимаю, что.

Где стоит использовать bootstrap и стоит ли вообще использовать CSS фреймворки?
Здравствуйте. Лично я ужасаюсь ковырять стили, когда к сайту подключен bootstrap и мало понимаю.

Какую БД использовать с xamarin.forms?
Нужна БД на удалённом сервере к которой будет подключаться приложение и взаимодействовать с БД.

Стоит ли изучать технологии Xamarin, Unity, MVC и насколько они хороши?
Всем привет дорогие друзья так как сам имею мало информации да и на просторах интернета об этом.

Стоит ли использовать this?
Здравствуйте, когда стоит использовать this, а когда нет? Например у меня есть код, тут нужны this.

Разработка мобильных приложений в Xamarin

Автор: Alex. Опубликовано в Программирование 11 Декабрь 2014 . просмотров: 20045

Если вы разработчик C# и собираетесь заниматься разработкой приложений для мобильных платформ iOS и Android, то платформа Xamarin позволит вам это сделать, не меняя привычный язык программирования и среду разработки. Вы сможете разрабатывать мобильные приложения для Android и iOS, используя Visual Studio и C#.

О компании Xamarin

Инструменты для разработки мобильных приложений Xamarin созданы и продолжают совершенствоваться американской компанией Xamarin. В штате компании около 170 сотрудников. Xamarin используют около 15 тысяч компаний и более чем 800 тысяч разработчиков по всему миру. Подробности о компании можно почитать здесь.

Разработка на Xamarin

Основной инструмент, с помощью которого компания Xamarin предлагает нам разрабатывать приложения для iOS, Android и Windows Phone, — это Xamarin Studio (см. первую картинку снизу), которая работает на Windows или Mac OS X. Также можно вести разработку благодаря расширениям в среде Microsoft Visual Studio (см. вторую картинку снизу).

В Xamarin Studio вам будут доступны привычные фишки и инструменты для разработки: подсветка синтаксиса, рефакторинг, автодополнение кода, поиск по проекту, отладка. Есть также встроенная интеграция с системами контроля версий Git и SVN и возможность интеграции с TFS. В общем, всё очень похоже на Microsoft Visual Studio.

Обратите особое внимание, что для сборки приложения для iOS вам потребуется последняя версия iOS SDK (поставляется с Xcode) и одна из последних версий Mac OSX (Mavericks или Yosemite). Т.е. в любом случае нужен будет Mac.

Как работают приложения, созданные в Xamarin?

Чтобы разработанные в Xamarin приложения работали на Android и на iOS используется разный подход.

В Android ваше приложение работает на платформе Mono — полнофункциональной реализации платформы .NET. Mono даёт возможность использовать все возможности C# и .NET, в том числе JIT-компиляцию (динамическую компиляцию), управление памятью, рефлексию и базовые .NET библиотеки. Когда вы используете классы .NET библиотек движок Mono перенаправляет все вызовы к API функциям Android.

В iOS тоже используется Mono, но по-другому. Ваше приложение перед выполнением компилируется в ARM-совместимый машинный код. Вы также можете использовать все возможности C# и .NET включая управление памятью, рефлексию и базовые .NET библиотеки.

Здесь нужно заметить, что ваше приложение сможет работать не только под iOS и Android, но и под Windows Phone, т.к. на Windows вам также будет доступен Xamarin.Forms API ну, и конечно, у вас будет доступ к оригинальной платформе .NET.

Использование сторонних .NET библиотек с Xamarin

Кроме стандартных библиотек .NET вы можете использовать библиотеки сторонних разработчиков. Все библиотеки, доступные для разработки ваших приложений в Xamarin, можно посмотреть в магазине Xamarin Component Store. Здесь есть и платные и бесплатные компоненты. При выборе сразу обращайте внимание, какие ОС поддерживаются: iOS, Android или Windows.

Кроме того вы можете использовать свои готовые .NET библиотеки, которые вы используете на компьютерах с Windows, но не заточенные под определённую платформу, например, без вызовов API функций Windows. Чтобы оценить возможность использования библиотеки с движком Mono вы можете воспользоваться сканнером .NET Mobility Scanner.

Если у вас есть необходимость вызывать существующий Objective-C-код на iOS или существующий Java-код на Android, то это вы тоже сможете делать.

Системные требования Xamarin

Системные требования Xamarin такие же, как и требования для SDK Apple и Google к целевым системам iOS и Android. Обратите также внимание, что для сборки приложения для iOS вам потребуется последняя версия iOS SDK (поставляется с Xcode) и одна из последних версий Mac OSX (Mavericks или Yosemite). Для работы расширений Xamarin для Visual Studio требуется полноценная (не экспресс) версия Visual Studio 2010, 2012 или 2013.

О ценах на Xamarin

Использование Xamarin платное — по подписке. Хотя есть и бесплатная подписка STARTER для ознакомления, но здесь ограничения на размер создаваемого приложения (не более 64Кб скомпилированного кода) и на использование сторонних библиотек. Поэтому пользоваться бесплатной подпиской практически нереально.

Самая дешёвая подписка, с помощью которой можно создавать приложения без ограничения размера с возможностью использования сторонних библиотек – это INDIE стоимостью 299 долларов в год на одного разработчика под одну платформу (Android, iOS или Mac). Если вы хотите разрабатывать для Android и iOS, то вам нужно оформить две подписки. По истечении года вы сможете легально продолжать использовать Xamarin, но не сможете получать обновления, а обновления важны, т.к. регулярно появляются новые версии iOS и Android. Подписку INDIE можно оплачивать помесячно (за 25 долларов в месяц), но в этом случае вы не имеете право использовать Xamarin по истечении подписки.

Для организаций с количеством разработчиков более 5-ти нужно приобретать подписки BUSINESS, 999 долларов в год, или ENTERPRISE, 1899 долларов в год. После истечения подписки вы также можете продолжать использовать Xamarin, но не будете получать обновления. Цены указаны также на одного разработчика и на одну платформу. Для нескольких разработчиков даются скидки. С помощью этих подписок вы уже сможете разрабатывать в среде Microsoft Visual Studio, получите поддержку WCF и System.Data.SqlClient и получите расширенную поддержку. Друг от друга эти подписки отличаются степенью поддержки со стороны компании Xamarin. Также с подпиской ENTERPRISE вы автоматически приобретаете компоненты и темы более чем на 500 долларов, включая SQLCipher, Signature Pad, Lock Screen, Black Leather Theme, Brown Leather Theme и Industrial Theme.

Подписавшись на какую-либо подписку, вы всегда сможете перейти на более продвинутую подписку, доплатив разницу. Для этого нужно послать запрос на адрес Этот адрес электронной почты защищён от спам-ботов. У вас должен быть включен JavaScript для просмотра. .

Студенты могут попробовать получить Xamarin INDIE бесплатно. Форма для заполнения заявки здесь. Преподаватели и институты могут купить подписку BUSINESS без E-mail поддержки на Xamarin.iOS и Xamarin.Android за 99 долларов. Чтобы получить такую скидку нужно отправить запрос с описанием курса и лабораторных работ на адрес Этот адрес электронной почты защищён от спам-ботов. У вас должен быть включен JavaScript для просмотра. . Подробнее о ценообразовании для студентов и преподавателей написано здесь.

Все подробности по подпискам можно почитать здесь.

Облако тестирования Xamarin Test Cloud

Одна из интересных фишек Xamarin – это возможность тестирования вашего приложения в облаке Xamarin Test Cloud. Облако позволяет имитировать и автоматизировать действия пользователя. Также облако предоставляет возможность тестирования на более чем 1000 реальных невзломанных устройств (список девайсов можете посмотреть здесь). Тестовые сценарии могут выполняться параллельно на сотнях устройств одновременно, и вы получите отчёты об испытаниях. Скрипты для тестирования могут быть написаны с помощью Calabash (Ruby) и C#.

С помощью облака Xamarin Test Cloud можно тестировать приложения, написанные не только с помощью Xamarin. Здесь также можно проверить работу приложений созданных с помощью Objective-C, Java, Appcelerator и Phonegap.

Использование облака, как вы можете догадаться, не бесплатное. Доступ производится тоже по подписке. Цена подписки варьируется от 1000 долларов до 12000 долларов за месяц, а оплачивается подписка на год. Разница между подписками в количестве тестируемых приложений, количестве часов тестирования и степени поддержки со стороны специалистов Xamarin.

Страничка облака находится здесь. Чтобы начать пользоваться облаком, напишите об этом разработчикам с помощью специальной формы и ждите обратной связи.

Стоит ли использовать Xamarin для разработки мобильных приложений?

Конечно, вам самим нужно решать, стоит ли разрабатывать мобильные приложения с помощью платформы Xamarin. Использование именно этой платформы может быть оправдано тем, что C# программистам не нужно изучать другие языки программирования и тем, что один код будет работать на всех мобильных платформах и поэтому ваш проект будет проще сопровождать.

Для оценки платформы вы можете скачать Xamarin Studio по бесплатной подписке STARTER или купить на месяц подписку INDIE, можете ознакомиться с документацией и посмотреть примеры.

Xamarin: что это такое, кому стоит использовать и ответы на другие важные вопросы о фреймворке

Меня очень вдохновил недавний пост Скотта Хансельмана в его блоге о том, что разработчики .NET должны знать на начало 2020 года. И я решил пойти немного дальше этого и написать небольшой путеводитель для разработчиков Xamarin, создающих приложения iOS, Android и macOS в .NET. Так что я связался с Крисом Харди, и мы совместно подготовили обширный список понятий и полезных ресурсов, имеющих отношение к Xamarin.

Прежде чем мы начнем, Вам непременно стоит посетить замечательный блог Скотта, поскольку он просто переполнен отличной информацией. Кроме того, чтобы сделать этот пост максимально полезным, я разделил его на специальные секции: «непременно нужно знать», «следует знать» и «неплохо бы знать», к тому же я подготовил специальные разделы для iOS и Android.

Когда вы будете готовы приступить к работе с Xamarin, отправляйтесь на портал developer.xamarin.com, который, безусловно, является идеальным местом для начинающих разработчиков. Именно там я начал работу в области мобильной разработки в далеком 2011 году. Итак, приступаем!

С чего начать?

Тем, кто желает много читать, скачивать, изучать и смотреть по теме Xamarin, рекомендуем сразу взять на заметку следующие порталы:

  • xamarin.com и xamarin.com/download: Читайте и качайте материалы, связанные с Xamarin!
  • university.xamarin.com/self-guided: Бесплатное самостоятельное обучение в университете Xamarin.
  • Xamarin Workbooks: Позволяет разработчикам протестировать API-интерфейсы в интерактивном режиме.
  • xamarinshow.com: Еженедельное шоу на CH9, посвященное разработке и организованное мною.
  • open.xamarin.com: Здесь представлены проекты Xamarin на основе открытого исходного кода.

Что непременно нужно знать о Xamarin


  • Что такое Xamarin? Благодаря платформе Xamarin разработчики могут создавать полностью нативные приложения для iOS, Android и macOS, используя C#, F# или даже VB.NET. При этом в наличие 100% доступ к нативному API и возможность совместного использования логики с другими приложениями .NET.
  • У нас есть одна супер-оптимизированная среда выполнения .NET, которая доставляет .NET на iOS, Android, macOS, IoT, Linux, PS4, Xbox и т. д. Она реализует .NET API и приводит в действие .NET Standard, поэтому Вам не придется беспокоиться о реализации «под капотом».
  • Традиционная Xamarin разработка: Известная также как нативная Xamarin разработка, она дает разработчикам возможность совместного использования бизнес-логики приложений и создания нативных пользовательских интерфейсов для каждой платформы со 100% доступа к каждому API.
  • Xamarin.Forms разработка: Предлагает разработчикам кросс-платформенный пользовательский интерфейс абстракции для iOS, Android и Windows. Пользовательские интерфейсы могут быть созданы в коде XAML или ином виде, и к тому же нативные элементы управления установлены в среде выполнения для каждой платформы. Кроме того, предлагаются такие функции MVVM (Model-View-ViewModel), как привязка данных и управление ими. Получить доступ к нативным API-интерфейсам можно через платформу проектов и сервисы зависимостей.

Кросс-платформенное совместное использование кода

Существует несколько способов использования общего кода в разных приложениях

  • PCL (Portable Class Library): Эта библиотека, также известная как Pickle, дает разработчикам возможность для создания «библиотеки классов», рассчитанной на несколько платформ. Эта библиотека фактически действует в качестве опорного узла, предоставляющего перекрестный API, который доступен на каждой платформе. Чем больше платформ Вы выберите, тем меньшая плоскость API будет доступна.
  • Общий проект: Самый простой способ совместного использования кода на разных платформах. Он функционирует как «связывающий файл», разделяя код с целевой платформой. Преимущества, состоят в том, что здесь доступны все целевые API-интерфейсы, так что Вы можете производить условную компиляцию. Однако, такой подход может обернуться запутанным кодом, и, кроме того, в этом случае не создается сборка: файлы связываются между собой в проект платформы.
  • .NETStandard или “netstandard”: Библиотека netstandard — это следующий этап эволюции, и она вполне может прийти на смену PCL. Разработчики получают по-настоящему кросс-платформенную библиотеку, и она может быть запущена в любой среде выполнения, которая реализует такие API-интерфейсы, как Mono, .NET Framework и .NET Core.

Источники библиотек

Существует множество API, доступных в .NET и на каждой платформе, но иногда хочется больше! И здесь их можно получить.

  • NuGet: NuGet — это менеджер пакетов для платформы разработки Microsoft, включающей .NET. Клиентские инструменты NuGet обеспечивают возможность создания и использования пакетов. Галерея NuGet является центральным хранилищем пакетов, и используется всеми их авторами и пользователями.
  • Component: «Магазин компонентов» является специально подобранной галереей библиотек и менеджером платформ Xamarin. Он предлагает платные и бесплатные библиотеки, которые могут быть установлены непосредственно в приложения iOS и Android. Эти библиотеки создаются как разработчиками компонентов Xamarin, так и сторонними девелоперами.
  • Plugin: По правде сказать, плагины для Xamarin и Windows просто превосходные. Они позволяют Вам получать доступ к нативным функциям кросс-платформенного API прямо из общего кода! У них открытый исходный код, и здесь доступно немало классных вещей, в том числе для геолокации, возможности подключений и фотографий. Каждый плагин доступен по лицензии MIT и может быть установлен в любую библиотеку iOS, Android, Windows, PCL или .NETStandard Library через NuGet.

Библиотеки

Давайте познакомимся с некоторыми по-настоящему классными библиотеками, созданными или поддерживаемыми Xamarin:

  • MonoGame: MonoGame является эффективным, гибким и кросс-платформенным API для разработки игр в 2D и 3D. Он обеспечивает основу для многих кросс-платформенных игровых движков. Однако, он может также использоваться и непосредственно в играх, не будучи обернутым в игровой движок.
  • UrhoSharp: UrhoSharp является кросс-платформенным движком высокого уровня (3D и 2D), который может быть использован для создания анимированных 3D и 2D игр и сцен в приложениях, использующих геометрические формы, материалы, огни и камеры. UrhoSharp совместим с мобильными и десктопными приложениями, а также с HoloLens и VR.
  • SkiaSharp: SkiaSharp предлагает богатый и мощный графический API, который можно использовать для визуализации в 2D буферах. Вы можете использовать их для реализации элементов пользовательского интерфейса и 2D-графики, которые могут быть включены в приложение. SkiaSharp является привязкой .NET с библиотекой Skia и наследует функции и силу этой библиотеки.
  • CocosSharp: CocosSharp является простой библиотекой для 2D-игр, использующей C# и F#. Это .NET порт популярного движка Cocos2D.
Мастер Йода рекомендует:  Кому нужен выделенный сервер

Обязательно нужно знать: iOS

  • Расширения: Р асширения — это виджеты, которые предоставляются iOS в стандартных обстоятельствах, как, например, в «Центре уведомлений», когда пользователь запрашивает клавиатуру или редактирует фотографии. Все расширения устанавливаются в сочетании с приложением Container и активируются с определенной «точки расширения» в приложении Host.
  • watchOS: watchOS — это определенная версия iOS, которая предназначена для устройств Apple Watch.
  • tvOS: Apple выпустила 4-е поколение аппаратных средств Apple TV, отличающихся переработанным пультом с поддержкой сенсорного управления и новой операционной системой (основанной на iOS9).
  • Регистрационные профили: Когда нужно установить приложение на устройство или выпустить его в App Store, требуется получить учетную запись разработчика и создать регистрационный профиль. Они должны связать вместе устройства, учетные записи и компьютеры разработчика.

Непременно нужно знать: Android

  • Android Wear : Android Wear — это версия Android, которая предназначена для таких носимых устройств, как умные часы.
  • Keystore: Используется для подписи приложений Android, с тем чтобы размещать их в соответствующих магазинах.
  • Разбор APIs & SDKs: Компиляции, минимизация, планирование — всё, что является важным и заслуживает изучения. Ознакомьтесь с коротким видео по теме.

Следует знать: Xamarin

  • Linker: Используется для уменьшения размера приложений для iOS и Android, осуществляет статический анализ приложения, с тем чтобы определить, какие в нем используются узлы, типы и члены классов. Благодаря этому любая неиспользуемая вещь будет отброшена.
  • IL — некий промежуточный язык, который создается при компиляции. Как написал Скотт: C# — это яблоки, из которых IL делает яблочный соус, а JIT/АОТ и среда выполнения — яблочный сок.
  • AOT— Расшифровывается как Ahead of Time Compilation («компиляция на опережение»): Принимает IL и компилирует его в машинный код с целью выполнения полученного двоичного файла в нативном виде. Это то, что использует Xamarin.iOS.
  • JIT — Расшифровывается как Just in Time Compilation («мгновенная компиляция»): Принимает IL и компилирует его, подготавливая для запуска в качестве машинного кода. Это то, что использует Xamarin.Android.

Следует знать: iOS

  • Storyboard: Storyboard позволяет разработчику определять оба контроллера предоставлений и перемещаться между ними на поверхности дизайна, а также предлагает WYSIWYG редактирование пользовательского интерфейса приложения.
  • XIB: Шаблон iOS View XIB, в который можно добавлять автономный файл .xib, который может быть присоединен к определенному обратному классу.
  • Регистраторы: Код, который выставляет управляемый код на Objective-C. Он достигает этого путем создания списка каждого управляемого класса, унаследованного от NSObject.

Следует знать: Android

  • Dalvik & ART: ART — это среда выполнения Android, которая используется приложениями и некоторыми системными службами на Android. ART и ее предшественник Dalvik изначально были созданы специально для проекта Android.
  • Multi-Dex: Приложение Android (APK) состоит из исполняемых байткодовых файлов в виде Dalvik Executable (DEX), и они содержат скомпилированный код, используемый для запуска приложения. В спецификациях DalvikExecutable ограничено общее количество методов, на которые можно ссылаться в одном файле DEX до 65,536. Multi-Dex создает несколько файлов DEX для APK, и, таким образом, ограничения можно обойти.
  • ABI (Application Binary Interface): Один APK может содержать машинный код для поддержки нескольких различных архитектур. Каждая коллекция архитектурно-зависимого кода связана с бинарным интерфейсом приложения (ABI).
  • ACW & MCW: Android и Managed Callable Wrappers — это то, что позволяет .NET общаться с Java и наоборот.
  • AVD: Android Virtual Devices — это эмуляторы Android, которые используются для отладки приложений.
  • HAXM (Hardware Accelerated Execution Manager): Программное обеспечение от Intel для Windows и macOS, предназначенное для виртуализации, благодаря которому Вы получаете потрясающие AVDs.

Неплохо бы знать


  • Xamarin.Forms Roadmap: Замечательный стратегический план готовящихся функций и исправлений для Xamarin.Forms.
  • Профайлер: Профайлер Xamarin интегрируется с существующим инструментарием для сбора информации о приложениях Xamarin. Используйте его для поиска утечек памяти, устранения узких мест в производительности, а также для полировки приложения перед тем, как пускать их в свободное плавание.
  • MVVM (Model-View-ViewModel): Model-View-ViewModel (MVVM) — это архитектурный шаблон, который был изобретен с учетом XAML. Шаблон устанавливает разделение пользовательского интерфейса XAML (предоставления) и исходных данных (модели) через класс, который служит посредником между предоставлением и моделью (ViewModel). View и ViewModel часто соединяются через привязки данных, определенных в файле XAML. BindingContext для представления, как правило, является экземпляром ViewModel.
  • Пользовательский линкер: Если набора опций, доступных по умолчанию, оказывается недостаточно, тогда можно управлять процессом связывания с помощью файла XML, в котором будет описываться то, что нужно от линкера.

Порталы, которые стоит взять на заметку

  • Releases Blog: Будьте в курсе того, что происходит.
  • Xamarin в Twitter: Твит и еще раз твит!
  • События Xamarin: Все что происходит в мире Xamarin
  • Xamarin Podcast: В то время, когда Вы не слушаете Merge Conflict, я настоятельно рекомендую слушать Xamarin Podcast
  • Weekly Xamarin: Специально подобранные еженедельные материалы в рассылке «все о Xamarin»!

Автор: James Montemagno
Источник: Статья в блоге автора

Сравнение Xamarin с нативными iOS/Andro >Все, что можно сделать в приложении iOS с использованием Objective-C или Swift, и все, что можно сделать в приложении Android с помощью Java, можно сделать и на языке C # при помощи Xamarin

В последнее время многие разработчики приложений склонны соглашаться с тем, что Xamarin может считаться нативным инструментом разработки. В самом деле, существует мнение, что «все, что можно сделать в приложении iOS с использованием Objective-C или Swift, и все, что можно сделать в приложении Android с помощью Java, можно сделать и на языке C # при помощи Xamarin».

Тем не менее существует много подводных камней в соперничестве нативной платформы и платформы Xamarin. Итак, давайте сравним Xamarin с нативными инструментами разработки и разработкой гибридных платформ (Ionic, PhoneGap/Cordova).

Один стек, одна кодовая база (C#, .Net framework + нативные библиотеки)

Разные стеки для каждой платформы

Один стек, одна кодовая база (JavaScript, HTML5, CCS)

Совместное использование кода

Да, до 96% с использованием Xamarin.Forms

Нет, разные кодовые базы

UI/UX (User Interface/User Expierence)

Возможна полная настройка UI для каждой платформы

Только платформо-зависимые UI

Общий UI для всех платформ (ограниченные возможности настройки)

Хорошая, близкая к родной

Возможности аппаратных средств

Высокие. Xamrin использует платформо-

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

Высокие. Нативные инструменты имеют полную поддержку для возможностей системы OOTB

Средние. Возможности могут быть доступны через сторонние API и плагины, хотя есть некоторые риски из-за низкого качества и ненадежности большинства из этих инструментов

TTM (время выхода на рынок)

С Xamarin.Forms TTM происходит быстро из-за ограниченной настройки и расширенного обмена кодами.

Xamarin,iOS и Xamarin.Android требуют больше времени по мере того, как увеличивается количество пользовательского кода.

TTM для нативных приложений Android или iOS может быть таким же, что и для Xamarin.Forms или гибридных инструментов. Тем не менее создание приложений для множества платформ может потребовать от вас либо продлить время выхода на рынок, либо увеличить количество заинтересованных разработчиков

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

Есть ли альтернатива Xamarin сегодня?

Гибридные инструменты мобильной разработки развиваются довольно быстро, но им по-прежнему не хватает производительности и собственных возможностей, которые предлагает Xamarin. При этом затраты остаются сопоставимиыми. Если рассматривать два подхода (гибридный и Xamarin), то самая популярная дилемма — это Xamarin против Ionic и Xamarin против React. Однако React Native теряет популярность из-за ряда ограничений в базовых технологиях (стек веб-технологий).

Тем не менее существует мобильный инструмент разработки на базе JavaScript, который превосходит гибридные решения, по крайней мере, с точки зрения UI. Речь идет о NativeScript. Этот кроссплатформенный фреймворк с открытым исходным кодом при поддержке Telerik и при помощи единой базы кода позволяет вам реализовывать нативный UI и подключаться к родным API для лучшего использования мобильных устройств. Его главное отличие заключается в том, что он использует разметку XML, которая компилируется не в веб-браузере HTML, а в нативных эквивалентах Android и iOS.

Этот подход заполняет пробелы между нативными и гибридными разработками, и его методы похожи на то, что делает Xamarin. Основное различие между этими двумя инструментами заключается в языке программирования. Поэтому сравнение Xamarin и NativeScript, должно стать предметом более подробных исследований.

В то же время обсуждения преимуществ и недостатков Xamarin и нативных разработок Android/iOS кажутся более сложными: оба варианта доказывают, что они ценны с точки зрения качества и производительности. Поэтому выбор обычно зависит от типа приложения, которое вы хотите создать.

Советы по использованию Xamarin

При сравнении всех за и против нетрудно прийти к выводу, что перечисленные недостатки могут нанести ущерб разработке. Большинство владельцев бизнеса выбирают платформу Xamarin, так как это сокращает время выхода на рынок (Time-To-Market) и инженерных затрат за счет совместного использования кода и использования единого стека технологий.

Основываясь на опыте нашей команды, можно заключить, что лучшим вариантом использования Xamarin является разработка мобильных приложений для бизнеса. Со стандартным интерфейсом, который охватывает 90% проектов, логическое ядро продукта можно легко сделать общим на всех платформах.

В случае создания приложений со сложным интерфейсом, количество общего кода кардинально уменьшается. Таким образом, кроссплатформенная разработка Xamarin теряет своё главное преимущество и может сравняться по затратам с отдельными нативными решениями для каждой целевой платформы. Но это не делает приложения на Xamarin менне качественными, просто несколько увеличивает трудозатраты. И если вы ищете альтернативу платформе Xamarin для создания кроссплатформенных мобильных приложений, вы, скорее всего, разочаруетесь. Так, наиболее широко используемыми кроссплатформенными мобильными инструментами для разработки являются PhoneGap/Apache Cordova, Ionic Framework, Appcelerator/Titanium, а они, в первую очередь, опираются на веб-технологии, такие как HTML5 или JavaScript. Именно поэтому ни один из этих инструментов не может иметь такой же уровень производительности и нативные функциональные возможности, какие нам предлагает платформа Xamarin.

Подводные камни Xamarin

Чтобы выпустить успешное мобильное приложение в 2010 году, можно было ограничиться iOS-платформой и отложить остальные платформы менее популярные, до лучших времен. Сейчас же игнорировать, скажем, Android, чья аудитория растет в геометрической прогрессии, недальновидно, в связи с чем кроссплатформенные подходы становятся объектом пристального внимания.

Тем не менее, возникает вопрос, что проще и выгоднее: писать универсальный код с последующим портированием в другую среду или разрабатывать отдельные приложения для каждой платформы? В каких случаях кроссплатформенная разработка будет оптимальной? На эти и другие вопросы отвечает Валентин Базаревский, один из ведущих разработчиков компании Itransition.

Нативные или кроссплатформенные приложения?

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


На рынке мобильного ПО крепче всего удерживаются те приложения, которые одинаково хорошо работают как минимум на двух платформах – iOS и Android, а желательно и на Windows Phone. Добиться этого можно двумя способами: написать приложение трижды под разные платформы или адаптировать универсальный код к особенностям различных платформ. Для трех разных приложений нужны три команды разработчиков с различными навыками мобильной разработки, а для кроссплатформенного кода потребуется всего одна, но хорошо подготовленная команда.

Какие приложения лучше писать кроссплатформенно?

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

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

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

Возможно ли повторное использование кода для разных платформ?

Повторное использование кода помогает сократить трудозатраты при разработке сложных систем. Так, если система включает большой объем бизнес-логики, – сложные операции с локальной базой данных, например, – эта функциональность может быть без изменений перенесена с одной платформы на другую. Идеальные источники переносимого кода – это обширные проекты со сложными клиент-серверными операциями: масштабной обработкой и синхронизацией данных между мобильной и серверной базой данных, а также локальными алгоритмами предобработки, фильтрации и сжатия данных. И хотя интерфейс придется дописывать для каждой платформы отдельно, с инструментами Xamarin вы сможете составить до 80% кода из уже существующих компонентов (безусловно, это зависит от функционала конкретного приложения).

Возможно ли совместное использование логики серверной и клиентской частями?

Устоявшимся трендом является использование подхода API-first, который предполагает, что каждый серверный компонент системы предоставляет хорошо документированный и полный интерфейс взаимодействия. Зачастую помимо непосредственно API и документации к нему каждый такой серверный компонент предоставляет и клиентскую библиотеку (необходимую как минимум для интеграционного тестирования компонента). В случае .NET-проектов эта клиентская библиотека при правильном проектировании может быть использована без изменений на мобильных Xamarin-приложениях, таким образом значительно ускоряя процесс разработки.

Как добиться высокой производительности?

Этот вопрос волнует многих разработчиков, поскольку жертвовать производительностью системы ради экономии на этапе разработки недальновидно: пользователи вряд ли будут мириться с медленной работой приложения. В этой ситуации на помощь приходят кроссплатформенные SDK от вышеупомянутого Xamarin), который обеспечивает статическую компиляцию в нативный код, позволяя добиться хорошей производительности даже при сложных сценариях. Другие библиотеки, такие как Marmalade SDK, тоже показывают отличную производительность, но базируются на С++, поэтому требуют очень высокой квалификации команды и не позволяют повторное использование серверного C# кода.

Как насчет сторонних библиотек?

Создавая мобильное приложение, порой не обойтись без подключения сторонних библиотек. Здесь можно пойти двумя путями: внедрить зависимости в существующий код или же создать обертку над функционалом. Кроссплатформенные фреймворки решают эту проблему разными путями и с разной степенью эффективности. Xamarin, например, предусматривает оба подхода.

Как тестировать и поддерживать проект?

Продукты Xamarin поддерживают портируемые библиотеки типа PCL, позволяющие разработчикам использовать привычную серверную инфраструктуру для интеграции, внедрения и контроля качества, как любого другого .NET проекта. Таким образом, разработчики могут проводить модульное и интеграционное тестирование C# кода и применять хорошо зарекомендовавшие себя техники командной разработки, например, совместное владение кодом, командный анализ кода и пр.

Мастер Йода рекомендует:  Как эмулировать мобильные устройства в Google Chrome

Как интегрировать бизнес-приложения в инфраструктуру компании?

Крупные бизнес-проекты, разработанные на базе Xamarin, легко интегрируются с серверной инфраструктурой компании. Поскольку Xamarin основан на open-source реализации платформы .NET, он включает в себя множество традиционных полезных инструментов для полноценного развертывания и интеграции. А в свете последних событий (анонсирование поддержки операционных систем Linux и Mac OS X платформой .NET по умолчанию) будущее Xamarin становится все более многообещающим.

Нужны ли специальные знания мобильной разработки?

Поскольку приложения разрабатываются на С#, разработчики без знания Objective-C и Java могут принимать участие в написании мобильных приложений. Идея крайне проста: бизнес-логика пишется в привычной для .NET-разработчиков Visual Studio, тестируется и проверяется на одном из многочисленных continuous integration серверов, а непосредственным внедрением этой функциональности в мобильное приложение занимается программист, имеющий представление как о .NET, так и о Xamarin. В результате получается полноценное мобильное приложение.

Как углубить знания Xamarin?

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

Валентин Базаревский – один из ведущих разработчиков Itransition. В данный момент он работает над диссертацией на соискание степени кандидата наук в БГУИР. В сферу его профессиональных интересов входят .NET, iOS Objective-C, а так же технологии анализа данных в высоконагруженных системах, мобильные платформы (кроссплатформенная и нативная разработка) и машинное обучение.

Насколько хорошо Xamarin?

Смотря что писать собираетесь. Все эти альтернативные решения — это скорее для таких обычных, стандартных проектов без эзотерики и сложностей, ну типа программа заказа такси. Или с БД что-нибудь. Или мобильный клиент для чего-то.
Такие программы имеет смысл на них писать.
А вещи специфические, где нужен доступ к API ОС, вообще обычно не стоит кроссплатформенными делать.
Вот у меня сейчас такой проект, что важна даже IDE, чтоб была Android Studio, а не подустаревший Eclipse — не говоря уже о том, что ксамарины-кордовы туда вообще никаким боком (точнее, примениться-то они там могут — но очень нестандартно и неожиданно).

«если можно изучить ту или иную платформу» — так это по-любому надо. Если, конечно, вы будете специализировать не только на мобильных клиентах, прогах для заказа такси и прочих тривиальных вещах без всяких затей.

Наш первый опыт разработки на Xamarin

Полгода назад мы завершили разработку внутрикорпоративного мобильного приложения “Company Staff”. Company Staff (далее – CS) – это приложение для сотрудников нашей компании, помогающее нам искать коллег, получать информацию о них (дата рождения, вишлисты, достижения и т.д.), узнавать последние новости компании и многое другое.

Все началось с того, что у нашей .NET-команды между завершенным проектом и запланированным стартом нового выдалось свободное время, которое решили потратить на изучение новой для нас технологии – Xamarin. И чтобы не тратить время зря, мы хотели сразу опробовать эту технологию на приложении, которое было бы полезно Noveo. Долго думать не пришлось – мы вспомнили о Company Staff. Это приложение уже существовало в виде Web- и iOS-версий и, соответственно, готового Web API. Также существовало Android-приложение, которое просто импортировало контакты в телефон. Более того, наши дизайнеры уже потрудились и приготовили замечательный дизайн для нового Android-приложения, так что выбор был очевиден.

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

Xamarin

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

Xamarin – это фреймворк для кросс-платформенной разработки мобильных приложений, основанный на open-source реализации платформы .Net – Mono. С помощью Xamarin можно разрабатывать приложения для Apple-, Android- и Windows-девайсов, используя один язык – C#, и одно IDE – Visual Studio или Xamarin Studio. Также данная платформа предоставляет полный доступ к SDK, единую среду выполнения и даже родные механизмы создания UI. Приложения на Xamarin практически не уступают в производительности и внешнему виду нативным.

Многие до сих пор полагают, что кроссплатформенная разработка должна подчиняться фразе “write once, run everywhere”, что подразумевает, что один код должен работать на нескольких платформах без изменений. Однако такой подход обычно приводит к приложениям с ограниченной функциональностью (многие фичи, присущие той или иной платформе, недоступны) и универсальным UI, который не вписывается ни в одну из мобильных платформ.

Xamarin, в свою очередь, нельзя отнести к категории “write once, run everywhere”, хотя бы потому, что одна из его важнейших функций – возможность реализовать нативный UI для каждой платформы отдельно. При этом большая часть кода, которая включает в себя бизнес-логику, слой данных, доступ к ним и др., остаётся общей для всех платформ.

Как это работает?

Исходники на C# становятся нативными приложениями совершенно различными путями на каждой платформе. Главное различие заключается в предварительной компиляции:

  • Для iOS используется Ahead-of-Time (AOT) компиляция. Xamarin.iOS-приложение компилируется прямо в машинный код (ARM Assembly language). Поскольку Apple запрещает динамическую генерацию кода, накладывается ряд ограничений (см. Xamarin.iOS Limitations).
  • Для Android все немного сложнее. Для выполнения приложений в Android используется виртуальная Java-машина Dalvik. Нативные Java-приложения компилируются в промежуточный байт-код, который интерпретируется Dalvik’ом в команды процессора во время исполнения программы (Just-in-time (JIT) компиляция). Xamarin в свою очередь компилирует C#-код в промежуточный байт-код для виртуальной машины Mono, которая упаковывается в приложение. При запуске Xamarin-приложения две виртуальные машины Mono и Dalvik работают параллельно, обмениваясь данными через JNI.
  • Для Windows все как обычно. C# компилируется в IL и выполняется встроенной средой выполнения. Инструменты Xamarin’a не нужны. Также можно отметить, что для приложений Universal Windows Platform (UWP) остаётся функция .NET Native, которая ведет себя аналогично AOT-компиляции для iOS.

Результатом скомпилированного Xamarin-приложения являются .app-файл для iOS, .apk для Android и .appxbundle для UWP. Эти файлы неотличимы от пакетов приложений, созданных стандартными для платформ IDE, и развертываются точно таким же образом.

Xamarin.Forms

Первый же вопрос, который мы себе задали, – зачем для нашего приложения нужен Xamarin? Ведь по большому счету все, что должно уметь приложение, – это отобразить данные, которые приходят с сервера. По предварительным оценкам, только 25-30% приложения общие для всех платформ, а всё остальное – UI, который нужно реализовывать отдельно для каждой платформы.

Хотя целью Company Staff первоначально было обучение новой технологии, чтобы максимально проникнуться платформой и в дальнейшем заниматься серьёзными коммерческими проектами, мы решили отнестись к “тренингу” как к продукту. Тем более, что он действительно имел практическое применение в реалиях нашей компании. И поэтому нужно было сначала ответить на вопрос целесообразности применения Xamarin.

К счастью, разработчики Xamarin позаботились о нас и предоставили Xamarin Forms API.

Xamarin.Forms – это “надстройка” над Xamarin.iOS и Xamarin.Android, которая позволяет создавать кросс-платформенный пользовательский интерфейс. Такой интерфейс можно создать как с помощью XAML, так и кодом С#. Устроено это довольно просто: верстка реализуется с помощью Xamarin.Forms-компонентов, которые транслируются в нативные компоненты с помощью специальных классов-рендереров на каждой целевой платформе. Кроме того, важным достоинством является полноценная поддержка MVVM (Model-View-ViewModel) – наличие привязки данных (data binding) и управление ими. Таким образом, в идеальном случае разработка на Xamarin.Forms немногим отличается от разработки приложений UWP/WindowsPhone/WPF.

Первые шаги

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

Для Xamarin Forms есть 3 архитектурных подхода для общего кросс-платформенного кода:

  • Shared Asset Projects (SAP) – довольно простой подход. Такой проект не компилируется в отдельную сборку, а “встраивается” в проекты, в которых используется. Такой подход позволяет использовать платформо-зависимый код наряду с общим, используя директивы компилятора #if.
  • Portable >В результате будут доступны только те функции, которые находятся в пересечении указанных платформ. PCL не позволит использовать какой-либо платформо-зависимый функционал, таким образом гарантируя, что PCL код запустится на всех указанных платформах.
  • .NET Standard Libraries – более новая технология, упрощенная версия PCL, но с более широким функционалом. На момент разработки нашего приложения .NETStandard еще не появился в общем доступе, и мы, естественно, не могли рассматривать его. Хотя стоит отметить, что сегодня мы бы выбрали именно этот подход, поскольку он более гибок и прогрессивен.

После краткого описания первых двух подходов очевидно, что у PCL намного больше преимуществ перед SAP. Конечно, могут возникнуть ситуации, когда какая-либо фича не может быть реализована общим кодом (например, работа с файлами), при условии, что стоит строгая задача локализовать бизнес-логику в отдельном проекте. В таком случае можно скомбинировать оба подхода. В нашей же ситуации мы решили не прибегать к SAP, а платформо-зависимый функционал реализовать в проектах под конкретную ОС.

Верхняя структура проекта проста, определилась сразу и почти не изменилась до релиза проекта:


— CompanyStaff – PCL библиотека Forms, которая содержит общие для всех платформ модели (Models), вью-модели (ViewModels), локализацию, общие настройки приложений, бизнес-логику и, собственно, сами Xamarin.Forms вью (Views);

— CompanyStaff.Droid, CompanyStaff.iOS, CompanyStaff.UWP – по большому счету это и есть нативный Xamarin. Здесь содержится реализация нативного функционала приложения, и именно эти проекты затем собираются в пакеты приложений под указанные платформы. Код данных проектов – это C#-обертки над нативными классами. В нашем случае классы этих проектов можно разделить на две категории:

1) Рендереры – классы, отвечающие за отображение визуальных компонент. Они содержат ссылки на PCL-объекты и выставляют свои свойства согласно этим объектам. В дальнейшем рендереры разворачиваются в нативные контролы.

Рассмотрим кастомизацию контролов на примере простого поля ввода, у которого нужно отключить нативные клавиатурные подсказки.

Для начала нужно создать класс в PCL, унаследованный от Entry.

Затем просто добавляем новый контрол в код пользовательского интерфейса (в нашем случае интерфейс описан в XAML):

Это все, что нужно в PCL для нашего простого примера. Переходим к реализации рендереров. Для этого необходимо всего три вещи:

  • Создать унаследованный от EntryRenderer класс, который отвечает за отображение нативного элемента.
  • Переопределить метод OnElementChanged, в котором необходимо описать логику кастомизации контрола. Этот метод вызывается при создании соответствующего контрола Forms.
  • Добавить атрибут ExportRenderer на класс рендерера, чтобы “зарегистрировать” наш класс в Xamarin.Forms для рендеринга определенного контрола.

Вот так выглядит код рендереров для нашего поля ввода:

2) Реализация DependencyService’ов – реализация функционала, не связанного с UI, позволяющая работать с данным функционалом из PCL на уровне абстракций.

Одной из важных функций в CS является возможность добавления контактов сотрудника в телефонную книгу устройства. Поскольку реализация данного функционала сильно “платформо-зависима”, а доступ к нему нам необходим из PCL кода, то наиболее удобный способ – использование DependencyService’ов.

Для начала нужен интерфейс в PCL для операций добавления контактов. В нашем приложении он выглядит так:

Затем нужно реализовать данный интерфейс на каждой платформе. Общая схема одинакова (за исключением .NET Native компиляции UWP проектов). Пример для Android:

Далее из PCL кода достаточно вызвать фабричный метод Get () у статического класса DependencyService для выполнения описанных операций:

В CS с помощью DependencyService’ов реализована работа с контактами, ориентацией девайса, социальными сетями, локализацией, защищенным хранилищем данных и др.

CompanyStaff.Dependencies – сюда мы вынесли интерфейсы DependencyService’ов.

— CompanyStaff.ServicesContract и CompanyStaff.Services – интерфейсы и реализация работы с web-сервисом соответственно.

— Bootstrapper – регистрация сервисов в IoC контейнере для Dependency Injection.

Затем нужно было выбрать фреймворк, который упростит работу с MVVM и легко встроится в описанную выше архитектуру. От данного фреймворка нам требовался следующий функционал:

  • базовые классы для работы с MVVM (ViewModelBase, Commands, Events);
  • Dependency Injection, в первую очередь для внедрения сервисов во вью-модели;
  • реализация межстраничной навигации.

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

Существует несколько наиболее популярных фреймворков для данных целей:

Каждый из этих фреймворков портирован для Xamarin.Forms. Со всеми, кроме последнего, мы имели опыт работы раньше на других платформах – UWP, WindowsPhone, WPF.

MVVMCross и Prism – большие и мощные фреймворки с большой поддержкой коммьюнити. Поскольку и Xamarin, и Xamarin.Forms быстро развиваются, количество форков и звездочек на github’e на данный момент и в дальнейшем стало определяющим фактором при выборе сторонних инструментов.

Мы решили одновременно попробовать оба фреймворка и выбрать более удобный. С MVVMCross сразу возникли проблемы c инициализацией на UWP. Prism, в свою очередь, завелся сразу и без каких-либо трудностей. Долго не разбираясь, оставили Prism. Тем более, что мы давно хотели его «пощупать».

В итоге – мы остались довольны выбором Prism, в первую очередь – благодаря удобной реализации навигации MVVM-путём, хоть и пришлось повозиться с навигацией на уровне Xamarin.Forms.

О том, как мы преодолели трудности, связанные с навигацией и не только, читайте во второй части!

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Информационный портал по безопасности

Xamarin. За и против

Автор: admin от 27-06-2014, 09:50, посмотрело: 1314

Наверное, каждый .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, иначе возможны утечки памяти.
  • Отладчик достаточно медленный и не всегда стабильный. Однако, разработчики постоянно улучшают его.
Мастер Йода рекомендует:  Как создать цветной деревянный 3D-текст

Поддержка

В одном из комментариев я видел жалобу, будто на 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.

Apps4all

​ Сегодня редакция Apps4All пообщалась с Дмитрием Моисеевым, последние два года он занимается разработкой мобильного приложения Контур.Эльбы, а также оказывает посильную помощь при разработке мобильных приложений других команд СКБ Контур.

Дмитрий, добрый день. Расскажите, когда было запущено приложение?

Год назад мы выпустили мобильное приложение под Android и активно его развивали. Сейчас пришло время мобильной платформы iOS, второй по популярности среди наших пользователей. Несколько лет назад команда уже предпринимала попытку сделать приложение для iPhone, но результат вышел неоднозначный. Основной проблемой стало то, что разработка была «полуаутсорсовой» и приложение не удавалось эффективно развивать и поддерживать одновременно с веб-сервисом. В этот раз разработка велась при активном участии основной команды.

Поделитесь особенностями и ошибками, с которыми вам пришлось столкнуться.

Приложение под Android разрабатывалось для существующих пользователей Эльбы, поэтому в первой версии была возможность просматривать созданные в сервисе счета, документы и контрагентов. Позднее появилась возможность редактирования этих данных. А при создании iOS-приложения мы поставили иную цель – приносить пользу всем предпринимателям, а значит, предоставить возможность пользоваться приложением сразу после установки из AppStore, без регистрации.

Вторым отличием стали использованные технологии: Android-приложение мы писали с использованием родного Google-инструментария и на Java, а приложение под iOS – уже на кроссплатформенном фреймворке Xamarin и C#, чтобы задействовать тот же язык и платформу (.NET), что и на сервере.

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

Для первого релиза мы выбрали минимальный набор возможностей: выставление счетов и отправка их по электронной почте или с помощью мессенджеров.

На первом экране пользователя встречает описание возможностей, а при создании документа нужно ответить всего на один вопрос: у вас ИП или ООО?

После выбора формы бизнеса можно выставить счет с фактурной частью и отправить контрагенту в виде PDF-файла или ссылки на документ. Перед этим следует заполнить реквизиты: ИНН и расчетный счет.

Без регистрации в приложении можно создать не более пяти счетов. Чтобы создавать неограниченное количество документов, нужно пройти регистрацию – указать электронную почту в качестве логина и придумать пароль. Никаких длиннющих форм 🙂

Несмотря на бесплатный тариф в веб-версии Эльбы, лимитов на создание счетов нет – бонус для пользователей приложения.

Как проходил процесс разработки?

Несмотря на то, что опыта разработки под iOS и Xamarin у нас не было, команда была настроена оптимистично. Xamarin на рынке уже не первый год, коммерческая версия на 1 платформу и 1 разработчика стоит 1 000 $ в год (Android + iOS соответственно 2 000 $), а значит, компания явно вкладывает силы и ресурсы в полировку своего продукта.

Увы, несмотря на возраст и большие амбиции, платформа оказалась сырой, причем по всем фронтам.

Редактор кода (Xamarin.Studio) – очень нестабилен. Может зависнуть в процессе сборки приложения, иногда перестает работать отладка или не открывается файл с версткой экранов. Не очень хорошо работают автодополнение кода. Настройки проекта могут измениться при открытии его в новой версии редактора. Подсветка синтаксиса может сработать неверно или совсем отключиться, а при переключении на русский язык недоступны горячие клавиши.

У Xamarin есть плагин, который позволяет писать код в Visual Studio под Windows, через локальную сеть компилируя и запуская приложение на Mac’. Но данный плагин тоже нестабилен, как и весь мир 🙂 Поэтому процесс разработки у нас выглядит так:

  • код лежит в сетевой папке, доступной на Mac’е и на запущенной виртуальной машине Parallels;
  • основная часть кода пишется в Visual Studio под Windows внутри виртуалки;
  • отладка или сборка финальной версии происходит в Xamarin.Studio на Mac OS X, но не через плагин, а через ручное открытие того же кода в общей папке.

Помимо редактора кода, есть другой нюанс: для iOS написано множество готовых библиотек и компонентов на Object-C или Swift, а для Xamarin’а их заметно меньше. В Xamarin-проекте можно создавать обертки вокруг Object-C кода для iOS или Java-кода для Android, но тогда теряется главное преимущество – код на одном языке на сервере и телефоне.

Несмотря на то, что Xamarin – кроссплатформенное решение, от разработчика требуется четкое понимание особенностей каждой мобильной ОС. Когда при работе над iOS-приложением мы использовали привычки, приобретенные за время разработки Android-версии, поняли – некоторые вещи устроены радикально иначе, например, работа с фоновыми процессами. Xamarin не сглаживает эти моменты.

Кроме основного продукта Xamarin, мы использовали библиотеку Xamarin.Forms, которая появилась в середине 2014 года. Это дополнительная обертка, позволяющая создавать верстку экранов сразу для обеих мобильных версий. К сожалению, и тут выяснились некоторые «нюансы»:

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

2. В библиотеке есть баги, в том числе крупные. Мы, например, столкнулись с такой проблемой: некоторые элементы управления на экране просто не появлялись, если их скрывать / показывать из кода. Причем этот баг возникал не всегда. Решение-костыль для него подобрать удалось, но неприятный осадок остался.

3. Через библиотеку нельзя управлять некоторыми возможностями. Например, нельзя поместить элементы управления в навигационную панель iOS приложений, а также усложняется создание анимации или каких-то специфичных эффектов.

4. Эта прослойка работает медленнее, чем родные компоненты, поэтому приходится помучиться над дополнительной оптимизацией.

В общем, напрашивается вопрос: а стоит ли использовать Xamarin, если требуется создать приложение для нескольких мобильных платформ сразу? Пожалуй, все-таки стоит, но с парой оговорок:

1. Нужно быть готовым к тому, что в продукте есть заметные баги и их придется обходить.

2. Продукт не до конца скрывает особенности платформ, так что изучать все нюансы работы с iOS и Android все равно придется.

А как проходила передача дизайна разработчикам?

При работе с версткой на первых порах нам помог продукт Zeplin, позволяющий экспортировать проект прямо из Sketch’а.После этого разработчик может посмотреть все размеры, отступы, шрифты, не дергая по каждому спорному вопросу проектировщика интерфейсов.

К сожалению, и в нем встретились баги с показом размеров, из-за которых неверно работает округление. Поэтому мы перешли на бесплатный плагин Sketch под названием marketch –он экспортирует проект в HTML-формат, после чего можно смотреть результат в любом браузере. Багов с пересчетом размеров пока не замечено, и обрадовало то, что не нужно ставить отдельный софт каждому разработчику.

Модерация в App Store: какие там подводные камни?

Премодерация приложения в App Store стала для нас отдельным приключением, которое требует своей истории. На эту тему мы опубликовали целую статью с подробностями общения с модераторами.

Если в двух словах, проблем было две:

1. Мы поместили в приложение ссылку на промо-сайт. А так как на сайте можно купить Эльбу, такие ссылки в приложении ставить нельзя.

2. Много времени пропало из-за взаимного недопонимания. Модераторы по какой-то причине требовали убрать из приложения регистрацию или добавить in-app purchase, а мы объясняли, что приложение бесплатно, в нем нечего покупать, а значит, и в in-app purchase нет нужды.

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

Следствие из вывода: время прохождения модерации никак не гарантированно, нужно закладывать время на возможные форс-мажорные обстоятельства.

Какие теперь у вас планы?

В ближайших планах у нас:

  • Доработать iOS приложение, чтобы оно по возможностям догнало Android-приложение.
  • Перенести Android-приложение на Xamarin.
  • Добавить новые фичи, которые уже давно ждут своего часа, например – распознавание документов из фотографий.

Дмитрий, спасибо вам за то, что поделились с нами опытом, удачи!

Должен ли я выбрать родной Xamarin или Xamarin.Forms для существующего приложения для Android?

У нас есть приложение для Android и мы хотим его воссоздать для кросс-платформы.

Каковы факты за или против родства и форм Хамарина?

Преимущество native будет, мы могли бы повторно использовать все xml-макеты, пока мы должны воссоздать iOS-представление в XAML или XIB?

Есть ли что-то, что действительно является блокировщиком?

Я буду комментировать на основе ответа Гиорги с некоторым фактическим пониманием и обратиться к скопированным пунктам:

Это резюме опыта, накопленного за последние 6 месяцев:

Xamarin.Forms лучше всего подходит для:

  • Приложения, для которых требуется небольшая функциональность для платформы
    • Неправильно. С помощью DI вы можете использовать любые функции устройства, которые вы, возможно, захотите. Посмотрите XLabs на GitHub, если вы сомневаетесь в этом.
  • Приложения, в которых совместное использование кода важнее пользовательского интерфейса
    • На самом деле это глупость. Вы можете создавать собственные средства визуализации для представления элементов управления каждой платформы так, как вы хотите. Я также написал более сложные средства визуализации для пользовательских элементов управления, таких как SideDrawer. В андроиде я было сделано через 2 дня, iOS около 2 недель (рендерер для Android был всего лишь оболочкой для собственного управления).
  • Разработчики, удобные с XAML
    • ну да и любой, кто пользуется удобным развитием пользовательского интерфейса. Имейте в виду, что есть кривая обучения с xaml (которую я уже знал в то время, когда я начал с разработки WPF). Но из того, что я видел, это не то, что отличается от андроида.

Xamarin.iOS и Xamarin.Android лучше всего подходят для:

  • Приложения с взаимодействиями, требующими собственного поведения
    • В то время как взламывание вашего решения происходит быстрее, вы скорее можете сделать это довольно быстро, если вы приобретете хорошие элементы управления/знаете правильную собственную реализацию и зеркалируете ее на С#, поскольку API в С# очень похож на собственный.
  • Приложения, которые используют многие API-интерфейсы для платформы
    • Не знаю, почему Xamarin делает антирекламу против форм. До сих пор у меня было мало проблем.
  • Приложения, в которых пользовательский интерфейс более важен, чем Совместное использование кода
    • Возможно, это правда, но также сложнее поддерживать функциональность интерфейса пользователя, и вам понадобится больше рабочей силы.

Что нужно учитывать о формах:

Формы, кажется, стабилизируются на данный момент, и я уверен, что Microsoft сделает все возможное, чтобы превратить ее в надежный и надежный продукт (иногда проблемы с созданием были кошмаром, но это стало лучше времени)

XAML для Xamarin менее развит по сравнению с WPF XAML, хотя и очень похож. Однако последние обновления nuget обеспечивают зеркальную функциональность с впечатляющей скоростью. Подавляющее большинство функций, которые вы ожидаете и любите в XAML, присутствуют.

Показатель производительности плохой, если вы не проводите исследования (здесь). Производительность увеличила нагрузку в этой области.

Если бы мне пришлось снова сделать выбор, я бы все равно пошел на формы. Хотя иногда есть вещи, которые кажутся ошибочными/плохими, вы обычно можете найти какое-то чистое исправление, в то время как большую часть времени занимаетесь разработкой приложения. (иногда вы все равно найдете вещи, которые просто заставляют вас хмуриться, почему что-то не реализовано, например, свойство Margin реализуется только сразу после покупки Microsoft xamarin).

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

    Xamarin.iOS и Xamarin.Android лучше всего:

    Ответ Giorgis правильный, но поскольку вы добавили еще несколько ограничений, вот мои мысли.

    Я бы проанализировал текущее приложение. Сколько кода является бизнес-логикой, которую можно использовать? Как настроен пользовательский интерфейс, должен ли он выглядеть более родным или более похожим и как он изменится в будущем? Если вы планируете многое изменить в пользовательском интерфейсе, и платформы должны выглядеть схожими, может быть проще переключиться на формы.

    Также подумайте, планируете ли вы разрабатывать Windows Phone? Если да, вы можете сэкономить много времени только для этой третьей платформы.

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

    Лично я использую Xamarin.iOS и Xamarin.Android с MvvmCross, таким образом я могу полностью контролировать собственный пользовательский интерфейс на каждом платформу при максимальном повторном использовании кода.

    С сайта Xamarin (кто знает лучше, чем они?):

    Добавить комментарий