Узнайте Больше О Xamarin

Хорошо ли вы владеете языком C# и платформой .

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

Что это?

Идея очень проста.

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

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

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

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

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

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

То есть, даже если вы хотите использовать стандартную кнопку «Назад» iPhone, вам придется ее нарисовать и расположить.

Во-вторых, вы получаете урезанный и обобщенный API для работы с платформой.

Таким образом, вам будут недоступны определенные возможности, присущие конкретной платформе.

Ну и третье и самое главное — такое приложение физически запускается внутри браузера телефона (точнее, внутри элемента управления WebView).

Нет необходимости подробно описывать, что это означает: низкая производительность (особенно «хорош» WebView на старых версиях Android) и огромные проблемы с отображением (ну, господа, это же браузер).

Хотя, конечно, в определенных случаях эти рамки могут быть весьма уместны.

Xamarin — это нечто другое.

Потому что я надеюсь, что мы тут все умные ребята, разработчики, я расскажу вам о том, как это работает внутри.

Это позволит нам понять потенциал этой технологии.

Xamarin основан на реализации платформы .

NET с открытым исходным кодом.

Мононуклеоз .

Эта реализация включает в себя собственный компилятор C#, среду выполнения, а также основные библиотеки .

NET. Цель проекта — позволить программам, написанным на C#, работать в операционных системах, отличных от Windows — Unix, Mac OS и других.

Важно, что Xamarin разрабатывают те же люди, которые разрабатывают Mono. И (здесь внимание) - это НЕ Microsoft со всеми вытекающими плюсами и минусами.

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

Как вы знаете, Android использует виртуальную машину Dalvik Java для запуска приложений.

Нативные приложения, написанные на Java, компилируются в некий промежуточный байт-код, который Dalvik интерпретирует в команды процессора во время выполнения программы (т.е.

аналогично тому, как среда CLR в .

NET).

Это так называемый Вовремя компиляция (компиляция на лету).

iOS использует другую модель компиляции — Досрочно (компиляция перед исполнением).

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

Для iOS ситуация проста — виртуальной машины нет и код программы нужно просто заранее скомпилировать в машинный код. Для этой цели используется компилятор Mono AOT.



Для Android интереснее.

При компиляции приложения код C# транслируется в промежуточный байт-код, понятный виртуальной машине Mono, а сама эта виртуальная машина также добавляется в упакованное приложение.

И Mono, и Dalvik написаны на C и работают поверх ядра Linux (мы помним, что Android основан на Linux).

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

Это все хорошо, но давайте приблизимся к развитию

У меня гораздо больше опыта работы с ним, чем с Xamarin.Android (но там все аналогично).

Библиотека классов Monotouch.dll обеспечивает доступ ко всем функциям iOS SDK. Для разработчика это просто набор классов C# с хорошей аннотацией.

Внутри эти классы используют механизмы привязки, разработанные инженерами Xamarin, к собственным классам и методам.

Важно, что один и тот же механизм можно использовать для связывания любых библиотек, написанных на Objective-C. Большинство классов и методов названы так же, как в исходном iOS SDK, хотя есть исключения (в этом случае вам придется искать в документации Xamarin исходное имя, поскольку оно появляется в атрибутах привязки).

В классах активно используется механизм событий C#, который позволяет писать красивый и компактный код-обработчик с помощью лямбда-выражений:

   

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

   

Посмотрите разницу в примере кода, который создает строку атрибута:



Для асинхронной разработки Xamarin предоставляет возможность использовать оба класса из пространств имен System.Threading.Thread и System.Threading.ThreadPool, а также полный спектр возможностей, предоставляемых Параллельная библиотека задач .

Однако использование последнего считается предпочтительным.

Кроме того, на момент написания статьи вышла очередная Stable версия, в которой добавлена поддержка .

NET 4.5, в частности, теперь можно использовать ключевые слова async/await. Хотя эта функция была доступна и раньше, необходимо было использовать канал бета-обновления.

А как насчет ограничений?

NET и Mono, не имеет виртуальной машины.

Поэтому возникают сложности с поддержкой Generic. Причина ясна — перед компилятором стоит задача проанализировать код и определить все возможные экземпляры в конкретном классе и методе.

Это приводит к следующим ограничениям:

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

Вы можете прочитать о них больше здесь для iOS И здесь для Android .

разработка пользовательского интерфейса

Для Android создание пользовательского интерфейса может происходить непосредственно в коде или с использованием декларативного подхода с описанием интерфейса в XML. Для iOS это тоже либо код, либо использование нативных инструментов проектирования интерфейса — отдельных xib-файлов или одной большой раскадровки.

Редактирование этих файлов происходит в привычной для iOS-разработчиков среде XCode. А это значит, что вам понадобится Mac. Да, для разработки приложений для iOS вам в любом случае понадобится Mac по двум причинам: Во-первых, как я уже сказал, редактировать UI в среде XCode. Во-вторых, для отладки приложений требуется симулятор iPhone/iPad, который также доступен только на Mac.

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

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

Но в данном случае возникает конфликт с предыдущим пунктом.

Как же так?



На самом деле ситуация следующая.

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

То есть вам придется писать код, отвечающий за внешний вид приложения, для каждой платформы отдельно.

Это цена за возможность использовать нативные механизмы пользовательского интерфейса.

Если разбить приложение на слои, то получится следующая диаграмма:

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

Доля переносимого кода достаточно сильно зависит от самого приложения, но, на мой взгляд, вряд ли может превышать 50-60%.

Инженеры Xamarin это понимают, поэтому стремятся увеличить эту долю.

Библиотеку Xamarin.Mobile можно считать достижением в решении этой проблемы.

Он предоставляет единый API для различных платформ для работы с камерой, контактами и геолокацией.

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

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

Компоненты Xamarin .

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

Количество комплектующих, кстати, растёт как на дрожжах.

Есть как платные, так и бесплатные (на данный момент их большинство).

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

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

Например, вариант Mono известной библиотеки для работы с Json — это Json.NET или библиотека для взаимодействия с Rest-сервисами — RestSharp .

Не все компоненты являются кроссплатформенными; многие из них доступны только для определенной платформы.

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

Кроме того, например, для Xamarin.iOS существует специальная утилита, которая может генерировать такие привязки автоматически.

Собственно, это позволяет инженерам Xamarin идти в ногу со всеми нововведениями iOS. Так, в частности, в Xamarin.iOS практически сразу после его выхода появилась возможность использовать Dropbox API, а также новые возможности iOS 7.

Документация и сообщество

Документация непосредственно для всех классов библиотек Monotouch и Monodroid входит в состав общая документация Mono .

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

В Xamarin есть сообщество разработчиков, ориентированное на официальный форум и дальше StackOverlow .

Не могу похвастаться активностью и инициативностью людей в сообществе.

Из пяти вопросов, заданных на официальном форуме, я получил ответ только на один.

Возможно, я спросил не то.

В этом отношении неоценимую помощь оказала частная техническая команда.

поддержка инженеров по электронной почте доступна при наличии бизнес-лицензии.

Обычно они отвечают в течение нескольких часов и не стандартными ответами «попробуй выключи и включи», а действительно понимают проблему и помогают ее решить.

Следует понимать, что база вопросов и ответов, накопленная для нативной разработки, гораздо шире, чем для Xamarin, поэтому, как бы вы ни хотели, вам придется разбираться в конкретном синтаксисе Objective-C (с Java проблем быть не должно).

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

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

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

Хамарин Студия

• Хорошая подсветка синтаксиса;
• Завершение кода (включая возможность одновременного импорта пространств имен);
• Удобный универсальный поиск по именам файлов, типам, членам классов и т.д.;
• Развитые возможности навигации по проекту: Быстрый переход к описанию класса, переход к базовому классу, списку мест, где используется класс и т.д.;
• Различные механизмы рефакторинга и быстрые подсказки (например, alt+Enter в Resharper);
• Достаточно развитые механизмы отладки, включая отслеживание, просмотр текущего значения переменной при наведении, визуализацию потоков и аналог окна Immediate в VS;
• Встроенная интеграция с системами контроля версий: SVN, Git и TFS (однако для TFS требуются сторонние утилиты);

Я использовал Xamarin Studio на Mac, поэтому следующее относится конкретно к Mac OS X:

• Горячие клавиши (в том числе копипаст) работают только в английской раскладке.

  Разработчики знают об этой проблеме.

  В баг-трекере есть ошибка;

• Периодически при попытке поставить точку останова студия зависает. Несмотря на наличие механизма автосохранения, это немного расстраивает.
• При использовании встроенной интеграции SVN добавление новых файлов в проект не отслеживается автоматически.

  Те.

  изменения в файле .

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

  В техподдержке сообщили, что знают об этой ошибке и исправят ее в одном из ближайших обновлений.

• Иногда проект перестает компилироваться.

  Лечится перезапуском студии.

Визуальная Студия

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

После установки плагина Visual Studio вам необходимо будет настроить соединение с вашим Mac, которое будет использоваться при запуске проекта.

Те.

после запуска приложение автоматически отправляется на Mac, где оно компилируется и загружается либо в симулятор, либо на устройство, а сам процесс отладки, установки точек останова и т.д. будет происходить в Visual Studio. Существует несколько вариантов работы в Visual Studio. Или вы используете виртуальную машину внутри Mac (например, Parallels), на которую устанавливаете Windows и Visual Studio. Или вы используете две разные физические машины, тогда как использовать один Mac для нескольких разработчиков ПК затруднительно, поскольку отладка требует манипуляций с симулятором.

Последний вариант — использовать виртуальную машину под управлением Mac OS X (называемую хакинтош).

Это жизнеспособный вариант, хотя есть некоторые ограничения.

Например, в Xcode вам придется перемещаться по раскадровке только с помощью полос прокрутки, потому что… Мышь Windows не очень похожа на настоящую мышь Mac со всеми вытекающими последствиями.

Время горькой правды.

Периодически возникали проблемы с отладкой в Visual Studio. Наиболее заметным из них является то, что при удаленной сборке приложения процесс отладки может истечь.

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

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

Лицензии

• Стартер - Бесплатно.

  Создан больше для информационных целей, т.к.

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

• Инди — 299 долларов за место.

  Ограничение на размер приложения снято.

  Разработка возможна только в Xamarin Studio;

• Бизнес – $999 за рабочее место.

  Появляется возможность разработки в Visual Studio и частных технологиях.

  поддержка инженеров Xamarin;

• Предприятие - $1899 за рабочее место.

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

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

Те.

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

Заключение

Несмотря на это, команда разработчиков не останавливается и продолжает активное развитие и совершенствование.

За последние два месяца произошли значительные улучшения в общей стабильности продукта.

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

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

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

Скачать фреймворк можно на официальном сайте - www.xamarin.com .

Отличные руководства для начала: iOS , Андроид .

Спасибо всем, кто нашел в себе силы дочитать до конца :) Теги: #xamarin #разработка мобильных устройств #C++ #.

NET #mono #mono #MonoTouch #MonoDroid #кроссплатформенная разработка #.

NET #Разработка мобильных приложений #C++ #xamarin

• Идеальный Инструмент Для Восстановления Базы Данных Ost Будет Выбран Для Восстановления Несовершенной Коррупции

  19 Oct, 24

• Seo-Советы Для Повышения Рейтинга В Поисковых Системах

  19 Oct, 24

• 10 Самых Популярных Видео С Рио-2016

  19 Oct, 24

• Что Такое Триз?

  19 Oct, 24

• Хранение Изображений С Помощью Django/Django Rest

  19 Oct, 24

• Используете Ли Вы Местные Торрент-Трекеры?

  19 Oct, 24

• Skype Connect Первое Знакомство

  19 Oct, 24

• Пять Книг По Программированию, Которые Вам Стоит Прочитать

  19 Oct, 24

• Выездное Обслуживание, Запросы На Карте, Геолокация. Выбор Картографического Сервиса. Взгляд Со Стороны Продукта

  19 Oct, 24

• Встреча В Санкт-Петербурге: Воскресенье, 29 Марта.

  19 Oct, 24