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

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

Взвесим все «плюсы» и «минусы» Xamarin

Что мне удалось создать

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

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

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

Недостатки и преимущества: разработка под Android была удобней, чем под iOS

В первую очередь, я начал разработку и тестирование своего приложения с помощью Xamarin.Forms под Android. Так уж вышло, что до этого времени я, по большей части, писал на Objective-C различные приложения под iOS. На свой Windows мне пришлось установить Visual Studio и с его помощью воплощать свою задумку в жизнь. Поскольку эмуляторы Android были ну очень-очень медленными, мне пришлось пойти по пути наименьшего сопротивления: я следил за процессом работы и проверял функциональность приложения на обычном телефоне Android, поскольку отладка с помощью телефона в Windows поддерживается только для устройств Android.

Для проверки правильности разработки заветной панели под iOS мне пришлось уделить несколько больше свободного пространства. Пока я продолжал разработку на Windows, мой iPhone, используемый для отладки, должен был быть постоянно подключен к Mac (или к рабочему узлу). Затем, я подключил Mac к той же сети Wi-Fi, к которой был подключен мой компьютер, используемый непосредственно для разработки. Зачем? Все просто: во время разработки и отладки Visual Studio IDE и Mac должны были взаимодействовать. С помощью SSH-соединения мне удалось «подружить» Visual Studio и Mac OS, установив доступ к компилятору Apple, а также инструментам для подписи исполняемого кода.

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

Преимущества: обеспечение функциональности благодаря встроенным макетам Xamarin.Forms

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

Что немаловажно, разрабатывая свою задумку с помощью Xamarin.Forms, я писал код, который как бы говорит: «Для первой ячейки создай мне новую линию, а для второй ячейки – сетку». Такой подход кажется мне очень удобным для разработчиков, привыкших писать свой и разбираться в чужом коде. Тем не менее, мне показалось нормальным написать свой собственный макет страницы, тем более если в будущем придется делать правки в коде и еще раз менять макет. Если у вас нет никакой другой причины, кроме как использование XAML designer, я бы посоветовал вам все-таки писать макеты для экранов.

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

Плюсы/минусы: решение вопроса ограничений с помощью Model View ViewModel

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

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

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

И все же, я не делал ставку на UX-дизайн для своего простого приложения, поскольку разработка гибкого макета с помощью Xamarin.Forms было неоспоримым преимуществом, которое позволило мне более эффективно повторно использовать код, экономя при этом 80–90% времени. Кроме того, некоторые особенности поведения той или иной системы могут отслеживаться с помощью DependencyService в Xamarin.Forms.

Вместо того чтобы все свои силы бросить на UX/UI-дизайн, постарайтесь вникнуть в ограничения для той или иной операционной системы. Сделав это, вы, несомненно, сможете создавать по-настоящему стоящие вещи, несмотря на такие границы. Конечно, такие уступки, сделанные для достижения преимуществ использования Xamarin.Forms, не могут стать решающим фактором. Тем не менее, стоит отметить, что если требуется более конкретная специфика для системы, то разработчики могут создать собственный рендер.

Принципы разработки с помощью Xamarin.Forms

(Внимание, спойлер от разработчиков!) Ниже представлены примеры лучшей практики для фреймов и эстетичных макетов для Xamarin:

• Стремитесь создать приложение, универсальное для всех систем
• Ознакомьтесь с ограничениями каждой из систем.
• Продумывайте шаги разработки вашего приложения: как вы будете его разрабатывать для операционных систем.
• Сначала – синтез, потом – дизайн
• Не стоит рассматривать функциональность как нечто, работающее на только устройствах Apple, тем более когда дело доходит до C# и SDK.
• Избегайте соблазна отказаться от привычных шаблонов взаимодействия. Почему? Там, где это возможно, Xamarin использует встроенные средства управления, поэтому элементы управления iOS и Android «text edit» выглядят и работают как элементы управления по умолчанию для каждой соответствующей ОС.

Плюсы и минусы: добавьте анимацию во время загрузки для ваших пользователей

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