Ios c что это

1

Ios c что это

Рассмотрим построение проекта на Maui и C# для iOS.

Взаимодействие iOS и Maui

Весь код для непосредственного взаимодействия с платформой iOS расположен в проекте в папке Platforms/iOS/

Здесь нас будут интересовать два файла: AppDelegate.cs и Program.cs .

Работа приложения iOS начинается с кода, расположенного в файле Program.cs :

Метод Main класса Program служит точкой входа в приложения. В нем же в свою очередь вызывается метод UIApplication.Main() , который определяет суть приложения и который обращается к классу AppDelegate из файла AppDelegate.cs :

А класс Appdelegate, в свою очередь, переопределяет метод CreateMauiApp(), в котором вызывается метод CreateMauiApp() и таким образом реализуется связь с кодом приложения MAUI.

Компиляция проекта для iOS из Visual Studio на Windows

Рассмотрим, как создавать приложения под iOS из Visual Studio на Windows. Прежде всего, следует отметить, что технически для компиляции приложения под iOS необходим MacBook. Кроме того, на MacOS должны быть установлены все необходимые инструменты для разработки под Maui, как описывалось в прошлой теме, и также должна быть установлена последняя версия XCode.

Для подключения к MacOS Visual Studio применяет SSH.

Возьмем простейший проект Maui, который создается по умолчанию. Прежде всего нам надо открыть доступ извне на самой машине под управлением Mac OS. Для этого на MacOS перейдем к настройкам общего доступа, среди которых надо включить опцию «Удаленный вход»:

В этом окне надо отметить IP-адрес в рамках подсети, по которому мы будем подключаться к макбуку. В моем случае 192.168.0.102.

Это были все необходимые настройки для Mac OS. Теперь перейдем к Visual Studio. Перейдем к пункту меню Tools -> iOS -> Pair to Mac

Открывшееся окно отобразит список доступных хостов MacOS для подключения:

Выберем в этом окне нужное подключение и нажмем на кнопку Connect. После этого откроется диалоговое окно, в котором надо будет ввести аутентификационные данные для подключения к Mac OS (то есть логин и пароль пользователя на машине Mac OS):

Если вы вдруг не уверены в правильности вводимого логина, то его можно узнать на Mac OS, введя в терминал команду whoami .

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

После успешного логина и подключения все окна можно закрыть. А Visual Studio с помощью значка зеленого монитора на панели инструментов укажет, что подключение успешно установлено

И затем мы сможем использовать удаленную машину Mac OS для компиляции приложения, а в Visual Studio мы сможем выбрать нужный симулятор iOS и запустить проект:

После этого запустится на симуляторе наш проект:

Стоит отметить, что несмотря на то, что мы можем запустить приложения на симуляторе непосредственно в Windows, но все равно нам необходим Mac OS для компиляции проекта.

Настройка компиляции под iOS

Если мы перейдем к свойствам проекта в visual Studio, то в секции Application/iOS Targets мы можем настроить минимальную и целевую версии iOS, под которые выполняется построение проекта.

Здесь нам доступны следующие опции:

Target the iOS platform : при установке этого флажка .NET MAUI при построении проекта будет также создавать версию приложения для iOS.

Target .NET Runtime : применяемая версия .NET

Target iOS Framework : применяемая версия iOS

Minimum Target iOS Framework : минимальная версия iOS, под которую создается приложение

Кроме того, внизу свойств проекта с помощью пункта iOS можно настроить различные параметры публикации проекта.

Компиляция проекта для iOS на Mac OS

При компиляции проекта MAUI под iOS на Mac OS все естественно несколько проще. Если мы используем Visual Studio for Mac, то также мы можем выбрать из панели запуска нужный симулятор iOS, либо даже подключиться к реальному устройству с iOS через WiFi:

При выборе симулятора iOS будет запущено приложение на выбранном симуляторе XCode.

23.3 – Вывод данных с помощью ostream и ios

В этом разделе мы рассмотрим различные аспекты класса библиотеки iostream для вывода данных ( ostream ).

Примечание. Все функции ввода/вывода в этом уроке находятся в пространстве имен std . Это означает, что все объекты и функции ввода/вывода должны иметь префикс std:: , или должна быть использована инструкция using namespace std; .

Оператор вставки

Оператор вставки используется для записи данных в выходной поток. В C++ уже есть предопределенные операции вставки для всех встроенных типов данных, а как перегрузить оператор вставки для пользовательских классов, мы рассмотрели в уроке «13.4 – Перегрузка операторов ввода/вывода».

В уроке о потоках вы видели, что и istream , и ostream были производными от класса с именем ios . Одна из задач ios (и ios_base ) – управлять параметрами форматирования вывода.

Форматирование

Есть два способа изменить параметры форматирования: флаги и манипуляторы. Вы можете думать о флагах как о логических переменных, которые можно включать и выключать. Манипуляторы – это объекты, помещенные в поток, которые влияют на способ ввода и вывода.

Чтобы включить флаг, используйте функцию setf() с соответствующим флагом в качестве параметра. Например, по умолчанию C++ не выводит знак + перед положительными числами. Однако, используя флаг std::ios::showpos , мы можем изменить это поведение:

Это приводит к следующему выводу:

Можно включить сразу несколько флагов ios с помощью оператора ИЛИ ( | ):

Чтобы отключить флаг, используйте функцию unsetf() :

Это приводит к следующему выводу:

Есть еще одна хитрость при использовании setf() , о которой следует упомянуть. Многие флаги принадлежат группам, называемым группами форматирования. Группа форматирования – это группа флагов, которые управляют аналогичными (иногда взаимоисключающими) параметрами форматирования. Например, группа форматирования с именем basefield содержит флаги oct , dec и hex , которые управляют основанием целочисленных значений. По умолчанию установлен флаг dec . Следовательно, если мы сделаем это:

То получим такой вывод:

Не сработало! Причина в том, что setf() только включает флаги – этого недостаточно, чтобы отключить взаимоисключающие флаги. Следовательно, когда мы включили std::hex , std::ios::dec всё еще был включен, а std::ios::dec явно имеет приоритет. Есть два способа обойти эту проблему.

Во-первых, мы можем отключить std::ios::dec , чтобы был установлен только std::hex :

Теперь мы получаем ожидаемый результат:

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

Это также дает ожидаемый результат:

Использование setf() и unsetf() может быть неудобным, поэтому C++ предоставляет второй способ изменения параметров форматирования: манипуляторы. В манипуляторах хорошо то, что они достаточно умны, чтобы включать и выключать соответствующие флаги. Вот пример использования некоторых манипуляторов для изменения основания чисел:

Эта программа создает следующий вывод:

В общем, пользоваться манипуляторами намного проще, чем устанавливать и сбрасывать флаги. Многие параметры доступны как через флаги, так и через манипуляторы (например, изменение основания числа), однако некоторые параметры доступны только через флаги или только через манипуляторы, поэтому важно знать, как использовать и то, и другое.

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

Вот список некоторых наиболее полезных флагов, манипуляторов и функций-членов. Флаги находятся в классе std::ios , манипуляторы находятся в пространстве имен std , а функции-члены живут в классе std::ostream .

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

Точность, формат записи и десятичные точки

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

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

Дает следующий результат:

Если не используется ни фиксированная, ни экспоненциальная запись, точность определяет, сколько следует отображать значащих цифр. Опять же, если точность меньше количества значащих цифр, число будет округлено.

Дает следующий результат:

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

Дает следующий результат:

Вот сводная таблица с еще несколькими примерами:

Ширина, символы заполнения и выравнивание

Обычно при печати чисел числа печатаются без учета пространства вокруг них. Однако печать чисел можно выровнять по левому или правому краю. Для этого мы должны сначала определить ширину поля, которая определяет количество выходных мест печати символов, которые будут заниматься печатаемым значением. Если фактическое напечатанное число меньше ширины поля, оно будет выровнено по левому или правому краю (как указано). Если фактическое число больше ширины поля, оно не будет усечено – оно приведет к переполнению поля.

Чтобы использовать любое из этих средств форматирования, мы сначала должны установить ширину поля. Это можно сделать с помощью функции-члена width(int) или манипулятора setw() . Обратите внимание, что по умолчанию используется выравнивание по правому краю.

Это дает следующий результат:

Следует отметить, что setw() и width() влияют только на следующую инструкцию вывода. Они не постоянны, как некоторые другие флаги/манипуляторы.

Теперь давайте установим символ заполнения и выполним тот же пример:

Это дает следующий результат:

Обратите внимание, что все пустые места в поле заполнены символом заполнения.

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

Подробно о 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`ов, что позволяет писать красивый и компактный код обработчиков с использованием лямбда-выражений:

Да и в целом код, написанный на 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. Достаточно серьезное ограничение, которое может некоторым образом испортить вашу стройную и красивую архитектуру.

Разработка 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) – Слой пользовательского интерфейса.

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

У 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

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

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

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 (не вижу особого смысла, т.к. обновления и так выходят очень часто), а так же возможность отправить инженерам проект с исходным кодом и сказать «Что-то у меня не получается поменять ширину ячейки в таблице, помогите!». Плюс ряд не слишком полезных, на мой взгляд, опций.

Заключение

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

Просто и понятно о Xamarin: как разработать кроссплатформенное мобильное приложение. Пошаговая инструкция

Xamarin — это опенсорс-фреймворк для разработки кроссплатформенных мобильных приложений с использованием библиотек .NET.

Чаще всего в качестве среды разработки выбирают Microsoft Visual Studio, а в качестве языка — C#. Такое сочетание позволяет компилировать, собирать и запускать один и тот же код (общий код) для:

iOS (.ipa — iOS App Store Package);

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

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

Преимущества Xamarin

1. Выше я уже упомянул про общий код. Так вот, доля этого кроссплатформенного кода может достигать 80% или даже 90%. Понятно, что чудес не бывает и все зависит от специфики вашего приложения. Если, например, вы пишете хардкорный код для обработки аудио/видео в реальном времени, он будет платформо-зависимым, и доля общего кода снизится. Но если вы ограничиваетесь написанием бизнес-логики — тогда ситуация обратная.
2. Xamarin позволяет напрямую достучаться до нативного API каждой из трех упомянутых платформ. То есть на нем можно писать и платформо-зависимый код.

Лицензия и другие условия использования

Есть две новости — хорошая и плохая. Начнем с плохой.

Стоит предупредить, что сейчас, без машины с MacOS компилировать, собирать и отлаживать Xamarin-приложения под iOS (официально) нельзя. Возможно, ограничение получится обойти, но насколько это легально?

Теперь хорошая новость: Xamarin распространяется бесплатно — в том числе и для коммерческого использования.

Документация и сторонние компоненты

У Xamarin довольно обширная документация. Она охватывает общие вопросы разработки кроссплатформенных приложений. Много внимания уделено библиотеке Xamarin.Forms. Кроме того, существуют отдельные большие блоки документации по специфическим вопросам разработки для Android и iOS.

На английском языке:

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

Поддержка системных требований (для Windows и для Mac)

Xamarin.Mac 4.8 будет работать на macOS версии 10.9 (Mavericks) и выше.

Xamarin для Visual Studio будет работать на Visual Studio 2019 и Visual Studio 2017 (Community, Professional и Enterprise). Чтобы использовать новейшие версии SDK для Android и iOS нужна обновленная версия Visual Studio. Если хотите разрабатывать на Xamarin под UWP, вам понадобится Windows 10.

Я выбрал Windows с Visual Studio 2019 Community. Далее все примеры будут относиться именно к этой конфигурации. А собирать и запускать Xamarin-приложение я буду под Android OS.

Установка Xamarin в Visual Studio

1. Для Visual Studio 2019 и 2017 процесс очень похож. Это касается и Community (бесплатной версии), и Professional, и Enterprise. Возможно, какая-то из этих версий VS у вас уже установлена (она не должна быть старше 2017, но это не эйджизм). Если нет — скачать можно здесь .

2. В обоих случаях нужно начать с запуска инсталлятора (Visual Studio Installer). Его можно найти на своем компьютере, например, через меню Пуск . Если вы только скачали VS без установки, просто запустите скачанный файл.

3. Выберите рабочую нагрузку (вкладка Workloads ) под названием Mobile development with .NET .

Вкладка Workloads -> Mobile development with .NET

4. Больше ничего не надо выбирать. Оставьте в покое настройку Install while downloading в списке вариантов установки и нажмите Install или Change (если VS уже была установлена).

5. Дождитесь окончания установки.

6. Проверьте, что выбранные вами компоненты установлены. Для этого з апустите Visual Studio, в главном меню выберите пункт Help и далее — About Microsoft Visual Studio:

Проверьте, что компоненты установлены

Все прошло успешно!

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

Xamarin построен на базе Mono. Это опенсорс-реализация спецификации CLI (Common Language Infrastructure) с виртуальной машиной и компилятором C#.

В рамках разработки Mono также реализовано множество библиотек, совместимых с .NET Framework, а также расширяющих его функциональность.

Xamarin включает две ключевых библиотеки для разработки приложений для мобильных платформ — Xamarin.Android и Xamarin.iOS (их названия говорят сами за себя).

Дело в том, что код Xamarin-приложения (напоминаю: это код на C#) не может напрямую обращаться к нативному API операционной системы Android или iOS. Проблему решают эти библиотеки, которые преобразуют код в соответствующие нативные вызовы.

Xamarin.Android использует пространства имен Android* и Java* из виртуальной среды выполнения Android Runtime (ART). Обращаться к ним позволяет специальный набор оберток Managed Callable Wrappers (MCW), который и выполняет необходимые преобразования с C#-кодом. Обратные преобразования выполняются через другой набор классов — Android Callable Wrappers (ACW).

Xamarin.iOS занимается статической (AOT — Ahead-Of-Time) компиляцией C#-кода в нативный ARM-код. В отличие от Just-In-Time (JIT) компиляции Xamarin.Android, происходяще в процессе работы приложения, исходный код заранее преобразуется в исполняемый (в данном случае — в ассемблерный код для мобильного процессора с архитектурой ARM). Параллельно работает среда выполнения Objective C. С помощью промежуточного слоя под названием Bindings Xamarin.iOS обеспечивает преобразование вызовов C# API в вызовы Objective C и обратно (выполняет те же задачи, что и MCW / ACW в Xamarin.Android).

На более высоком уровне абстракции находятся библиотеки Xamarin.Essentials и Xamarin.Forms , которые предоставляют кроссплатформенный API. Например, Xamarin.Forms позволяет создать единый кроссплатформенный UI (допустим, с помощью XAML), повесить на него обработчики и реализовать эту обработку (с помощью C#). Этот код можно запустить на всех трех платформах, о которых мы тут говорим.

Xamarin.Essentials — это библиотека, предоставляющая кросс-платформенный API (обертку) для единообразного использования нативных функций (геолокация, блокировка экрана или показания датчиков устройства).

Xamarin.Forms — это библиотека для разработки UI с помощью комбинации XAML и C#. Созданные таким образом абстрактные элементы управления могут быть преобразованы в нативные контролы соответствующей платформы. В данном случае это преобразование называется рендерингом .

Кроме того, Xamarin.Forms может похвастаться такими фичами, как Databinding, Gestures, Effects и Styling.

Структура проекта и разработка UI

Выше мы уже решили, что в этой статье вся практика будет опираться на конфигурация Windows с Visual Studio 2019 Community. Поэтому продолжаем с ней же.

Здесь мы рассмотрим шаблон проекта Mobile App (Xamarin Forms) , потому что Xamarin в первую очередь ассоциируется с кроссплатформенной разработкой.

Mobile App (Xamarin Forms)

Будем разбираться на практике. Для начала создадим свой проект (а точнее — Solution или «решение»):

Уже понятно, какой тип проекта нужно выбрать:

Выбираем тип проекта

Назовем его HelloHighloadToday:

Далее выбираем набор платформ, для которых будем создавать Solution. Я не стал устанавливать инструменты разработки UWP-приложений, поэтому этот пункт у меня не активен.

А работая на MacOS в Visual Studio для Mac, вы обнаружите, что этого пункта просто не будет. Вот такое платформенное ограничение: видимо, UWP там не в почете.

Выбираем пункт Blank (пустой), чтобы в сгенерированном коде не было ничего лишнего

Я также выбрал пункт Blank (пустой), чтобы в сгенерированном коде не было ничего лишнего. Так проще с ним разбираться.

Все, Solution создан! Посмотрим на его структуру:

Так как я выбрал две платформы, то дополнительно к основному проекту (HelloHighloadToday) VS создала еще два (платформо-зависимых):

• HelloHighloadToday.Android;
• HelloHighloadToday.iOS.

По умолчанию жирным выделен проект HelloHighloadToday.Android, но важно понимать, что основным проектом остается HelloHighloadToday. Без этого проекта невозможно заставить один и тот же код работать на остальных двух.

Hello, HighloadToday: как работает код

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

Посмотрим на структуру основного проекта — HelloHighloadToday. Здесь нас интересуют пять файлов: App.xaml, App.xaml.cs, MainPage.xaml, MainPage.xaml.cs и AssemblyInfo.cs.

В структуре HelloHighloadToday выбираем нужные файлы

AssemblyInfo.cs хранит настройки компиляции для Xamarin-приложения. Об этом файле — пока все.

Файлы App.xaml и App.xaml.cs

Есть более интересные ф айлы App.xaml и App.xaml.cs. Они отвечают за запуск приложения (для любителей английского: App — Application). Файл App.xaml — первая стартовая точка приложения.

По его расширению можно догадаться, что код внутри написан на XAML (язык разметки на основе XML). Этот декларативный язык обычно используется для описания пользовательского интерфейса или ресурсов. В этом файле обычно описываются глобальные ресурсы (например, стили), которые можно использовать внутри всего приложения. Нам тут пока описывать нечего, но в качестве примера можно посмотреть на такое:

С описанием UI мы встретимся чуть позже.

App.xaml работает в паре с файлом App.xaml.cs. Это вторая стартовая точка.

В этом файле создается пользовательский класс App — наследник класса Application (Приложение). Полное название этого класса определяется в файле App.xaml. В нашем случае это:

В конструкторе этого класса есть важный вызов метода InitializeComponent() , который отвечает за начальную инициализацию объекта нашего класса App, производного от класса Application. Там же, в конструкторе, устанавливается наша главная страница приложения ( MainPage , о ней пойдет речь далее).

Кроме того, в этом же классе Visual Studio заботливо сгенерировала пустые обработчики основных событий для типичного мобильного приложения — OnStart() , onSleep() и onResume() . Писать внутри свой код или не писать — целиком и полностью решаем мы с вами (то есть разработчики, которые используют Xamarin). Тут же можно подписаться и на другие события.

Файлы MainPage.xaml и MainPage.xaml.cs

Эта пара файлов состоит примерно в таких же отношениях, как App.xaml и App.xaml.cs:

Только в MainPage.xaml описан пользовательский интерфейс. По аналогии с HTML, здесь элементы UI представлены в виде тегов (с своими индивидуальными атрибутами) и вложены в некий контейнер StackLayout (хотя возможны разные уровни вложенности и варианты контейнеров), который, в свою очередь, вложен в страницу нашего приложения ContentPage:

Код внутри обоих файлов был автоматически сгенерирован во время создания проекта:

Видно, что код в этом файле еще проще, чем в App.xaml.cs. Здесь важно, что класс MainPage является наследником класса главной страницы ContentPage .

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

Разработка UI

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

Наш проект пока содержит только одну страницу — MainPage. Она была добавлена автоматически при создании проекта. Мы можем и сами добавлять новые страницы.

Добавление страниц на базе готовых шаблонов

Добавление страниц на базе шаблонов

Шаблоны подразделяются по типам страниц. Но для нас сейчас важнее заметить, что некоторые шаблоны не позволяют создать для страницы XAML-файл.

Например, при создании страницы на базе шаблона ContentPage будут созданы два файла — Page1.xaml и Page1.xaml.cs. В случае с шаблоном ContentPage (C#) будет создан только файл Page1.cs.

Из этого вытекают два подхода к разработке UI.

UI на C#

Код, сгенерированный при создании страницы на базе шаблона ContentPage

Это код, сгенерированный при создании страницы на базе шаблона ContentPage (C#).

UI с XAML

XAML-код, сгенерированный при создании страницы на базе шаблона ContentPage

Это XAML-код, сгенерированный при создании страницы на базе шаблона ContentPage.

Сs-код, сгенерированный при создании страницы на базе шаблона ContentPage

Это cs-код, сгенерированный при создании страницы на базе шаблона ContentPage.

Здесь файл .xaml с описанием UI отделен от .cs-файла. Тогда имеет смысл договориться, что во втором файле будем писать только логику взаимодействия с визуальным интерфейсом. Такой подход считается более рациональным: c декларативным стилем XAML структура UI выглядит более наглядно, код проще понимать и поддерживать, благодаря разделению над каждым из двух файлов может работать отдельный специалист. И это явно реверанс в сторону любителей HTML.

В обоих случаях нужно вносить изменения в код ручками, потому что у Xamarin.Forms нет Дизайнера (Конструктора форм). Но если создать Solution вроде Android App (Xamarin), то там Дизайнер присутствует. Только это уже тема для другой статьи.

Хорошо, так давайте же внесем эти изменения!

Делаем свой UI с XAML и обработкой событий

Усложним сгенерированный пример. Сформулируем ТЗ на наше Xamarin-приложение HelloHighloadToday:

1. Показать приветственный экран. Он должен содержать:

• заголовок («Знакомься с Xamarin!»);
• развернутый призыв к действию в следующем блоке текста;
• кнопку с надписью https://highload.today/category/teoriya;
• кнопку с надписью CLEAR;
• невидимый WebView.

2. По нажатию кнопки с надписью https://highload.today/category/teoriya обеспечить показ страницы по указанной ссылке: WebView должен стать видимым.

3. По нажатию кнопки с надписью CLEAR обеспечить возврат приложения к состоянию 1 (то есть спрятать WebView).

Я не буду рассказывать про сами элементы UI в расчете на то, что вы с ними знакомы или быстро сможете познакомиться.

Перепишем сначала файл MainPage.xaml. Я, не сильно раздумывая, выбрал терпимый вариант размещения элементов визуального интерфейса. Вы можете сделать по-своему:

Теперь обработаем нажатия на кнопки:

Обрабатываем нажатия на кнопки

Вот такая нехитрая логика.

Запуск под Android

Давайте проверим, действительно ли наш код из основного проекта будет работать на Android OS без танцев с бубном. Проверять будем на настоящем смартфоне с установленной операционной системой 10-й версии. Система не самая новая, поэтому будет еще интереснее посмотреть, взлетит ли на ней проект.

Проверяем проект на смартфоне

На приведенном выше скриншоте видно, что наш основной (кроссплатформенный) проект подключен как reference, а точнее — библиотека динамической компоновки (файл HelloHighloadToday.dll ). Это один из ключевых нюансов реализации кроссплатформенности. DLL-библиотека активно используется для работы Xamarin-приложения на Android OS.

А сейчас просто посмотрим на код файла MainActivity.cs (это главный и единственный экран) из нашего проекта HelloHighloadToday.Android. Он также написан на C# — ни слова про Java, как видите.

Отмечу, что этот код полностью сгенерирован Visual Studio. В нем подключаются и используются все необходимые пространства имен и библиотеки для работы с Android (в том числе — Xamarin.Forms и Xamarin.Essentials, описанные выше). Кроме того, MainActivity.cs использует настройки и ресурсы основного проекта (HelloHighloadToday). Ну и, конечно же, в методе OnCreate(Bundle savedInstanceState) выполняется инициализация и старт приложения.

Код, сгенерированный Visual Studio

В этом коде я не менял ничего.

Отлаживать приложение можно и в эмуляторе. Но для этого ваша машина должна поддерживать виртуализацию и работать достаточно шустро.

Посмотреть список виртуальных устройств или добавить новое можно через Tools -> Android -> Android Device Manager.

Если вы, так же, как я, запускаете приложения на реальном устройстве, то нужно выполнить несколько простых манипуляций с вашим смартфоном (или что там у вас c Android OS):

1. Подключить устройство к компьютеру по USB.

2. Зайти в Настройки -> О телефоне и щелкнуть по Номеру сборки 7 раз.

Необходимо кликнуть по Номеру сборки 7 раз

3. Зайти в Настройки -> Система и обновления и выбрать пункт Для разработчиков:

Необходимо выбрать пункт «Для разработчиков»

4. Включить сначала опцию Разрешить отладку по ADB только при зарядке, а потом опцию Отладка по USB. Первая опция вроде бы не обязательна, но без нее у меня не работало:

Включить необходимые опции

5. И еще один шаг на всякий случай. Если Visual Studio не может найти ваше устройство после всех предыдущих шагов — выполните Tools -> Android -> Restart Adb Server :

Если Visual Studio не может найти ваше устройство после всех предыдущих шагов

6. Проверьте, чтобы указанные в настройках пути вели, куда надо. Иначе Visual Studio просто не найдет нужные версии SDK и JDK.

Проверьте, чтобы указанные в настройках пути вели, куда нужно

7. Чтобы успешно скомпилировать приложение, нужно выбрать версию ОС, которая установлена на вашем устройстве (или виртуальном устройстве, если используете эмулятор).

Выберите версию ОС, которая установлена на вашем устройстве

8. Для запуска приложения на устройстве номер версии Android OS не должен быть меньше указанного в настройках манифеста ( Minimum Android version) :

Попробуйте подключить старый Andorid, и увидите, что будет (спойлер: ничего не будет!).

Вернемся к нашему проекту

Нам остается только запустить Xamarin-приложение на устройстве Android. Сборка произойдет автоматически:

Запускаем запустить Xamarin-приложение

Если нажать на на кнопку с надписью https://highload.today/category/teoriya

Действительно появляется WebView с соответствующим контентом.

Нажав на кнопку с надписью CLEAR , возвращаемся к первому экрану.

Отлично, все работает в соответствии с нашим ТЗ и даже не падает, когда я закрываю приложение, смахивая его с дисплея моего смартфона.

Публикация приложения

Чтобы загрузить приложение в Google Play, нужно иметь соответствующий аккаунт и выполнить целый ряд требований. Описание этого процесса выходит за рамки моего рассказа и превышает всякие объемы приличия. Уж простите. Если сильно нужно, то с этой статьи можно начать квест (там и для iOS, и для Android OS). Но сейчас не переключайтесь, пожалуйста.

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

В Visual Studio на панели инструментов под главным меню выбираем Release вместо Debug:

Под главным меню выбираем Release

В Solution Explorer выбираем Android-проект, нажимаем правую кнопку мыши и открываем его свойства (левой кнопкой на Properties ):

Нажимаем левой кнопкой мыши на Properties

Далее переходим в Android.Manifest. Тут почти ничего менять не пришлось (как минимум это справедливо для Visual Studio Community 2019 16.11.0). Понадобилось только выбрать иконку приложения ( Application icon ). Эту иконку (точнее набор копий иконки разных размеров) Xamarin выдает по умолчанию. Можно заменить на свою в папке Resources текущего проекта:

Иконку можно заменить на свою в папке Resources

На следующей вкладке Android.Options убираем галочку с опции Enable developer instrumentation (debugging and profiling). Так безопаснее. Сегодня спонсор паранойи — корпорация Microsoft:

Убираем галочку с опции Enable developer instrumentation

Сохраняем и закрываем окно со свойствами и опять попадаем в Solution Explorer. Там последовательно выполняем два действия:

1. Очищаем проект ( Clean ).

2. Пересобираем проект (Rebuild).

Очищаем и пересобираем проект

Выбираем Android-проект, нажимаем правую кнопку мыши и затем — Archive .

Выберите Android-проект, нажмите правую кнопку мыши и затем — Archive

Дожидаемся, пока сформируется файл .apk. Сформировался? Замечательно. Но пока он не подписан. Поэтому продолжаем.

Нажмем на кнопку Distribute:

Нажмите на кнопку Distribute

В появившемся окне выберем Ad Hoc (мы ведь создаем apk без загрузки в Google Play):

Далее нужно создать Ключ (Android Key Store) , которым будем подписывать наш файл приложения:

Ниже пример заполнения полей. Нужно заполнить все поля и нажать Create .

Важно: запомните пароль , который вы придумали, так как через пару-тройку шагов вновь потребуется его ввести!

После создания Ключа нужно нажать Save As для сохранения подписанной версии файла .apk:

Нажмите Save As

Здесь можно ввести произвольное название для файла:

Вводим название файла

При сохранении потребуется ввести пароль, который мы вбили при создании Android Key Store.

Все, мы получили .apk-файл, который можно скопировать на телефон или разослать кому-то по почте. Пишите письма. Пока!