История создания кроссплатформенного мобильного приложения

Жесткая конкуренция на рынке мобильных платформ уже не позволяет выпускать приложения ориентированные на одну операционную систему, что ставит разработчиков перед сложным выбором. Они должны выбирать между разработкой нативных приложений для каждой ОС (на родных языках програм¬мирования для каждой из них), разработкой в виде сайта для мобильных устройств на HTML5 или же создавать приложения, используя фреймворки для кроссплатформенной разработки.

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

Нашим первым клиентом стал международный аэропорт «Киев Борисполь». Особенность разработанного продукта заключалась в том, что он был адаптирован под корпоративный стиль заказчика и успешно опубликован в магазинах. Интересно, что аэропорт «Киев Борисполь» стал первым в Украине обладателем современного мобильного приложения. Тем не менее, стоит начать с самого начала.

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

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

Разработка клиентской части решения

Учитывая большой опыт наших сотрудников в создании приложений на С#, нами был выбран подход разработки клиентской части приложения с использованием фреймворка Xamarin. Вся работа проводилась в Visual Studio. И если для Windows phone и Windows 8 разработка в Visual Studio является инструментом по умолчанию, то для Android и iOS такая возможность стала доступной благодаря Xamarin (для этого необходима business-лицензия).

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

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

Xamarin позволяет использовать стандартные средства разработки пользовательского интерфейса и его элементов для iOS и Android.

Стоит отметить, что для разработки решения под iOS в любом случае необходим Mac. В нашем случае Mac потребовался по двум причинам: во-первых, для отладки приложений нужен эмулятор iPhone/iPad, который доступен только на Mac; во-вторых, эта операционная система была необходима для автосборки проекта.

Разработка серверной части решения

Учитывая необходимость универсализации приложения, при проектировании мы пришли к выводу, что оптимальным решением станет размещение серверной части в облаке. В качестве облачной платформы было выбрано решение от Microsoft — Windows Azure.

Работать с ним было очень удобно и довольно легко. Из положительных сторон работы с Azure хотим выделить следующие:
1) Удобное развертывание системы в облаке
Развертывание приложений в Windows Azure можно осуществлять двумя способами — при помощи портала Windows Azure или Service Management API (SMAPI).

2) Удобный механизм для тестового развертывания
Существует две ячейки развертывания – тестовая (staging) и боевая (production). Тестовое развертывание позволяет протестировать приложение в среде Windows Azure перед развертыванием в боевую среду. В свою очередь, переключение между staging и production выполняется в один клик.

Поскольку в Windows Azure размер оплаты зависит от потраченного процессорного времени, то для оптимизации расходов необходимо удалять staging развертывания. Если же просто нажать кнопку «Остановить» в портале, то сервис станет недоступным, но при этом процессорное время будет расходоваться.

Стоит отметить, что в нашем случае экономия составляла более 100 долларов в месяц.

В качестве ложки дегтя в бочку меда Microsoft скажем, что в Windows Azure неудобная работа с логами. Конечно же, для логов можно использовать платные решения, так как работать с их Table Storage очень неудобно.

Особенности функционала серверной части системы

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

Плюсы:

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

Минусы:

• невозможность предотвращения всех сбоев со стороны аэропорта
• безопасность FTP-протокола
• поскольку Windows Azure отсутствует такой сервис как FTP, ftp-сервер должен разворачиваться у заказчика
• истема, которая получает данные из FTP, имеет динамический IP-адрес, вследствие чего доступ к информации должен ограничиваться по пулу адресов облака Azure или по доменному имени сервиса.

Стоит также обратить внимание на отправку push-уведомлений пользователям. Среди особенностей необходимо назвать следующие:

• сервисы push-уведомлений не гарантируют доставку на клиент, а потому при плохом канале Интернет, существует вероятность потери сообщений
• очередность доставки уведомлений не зависит от очередности отправки
• в Wi-Fi сети необходимо открыть специальные порты для доставки push-уведомлений (в том случае, если политика безопасности построена по принципу «запретить все и разрешить только нужное»).

Особенности публикации

Аэропорт «Киев Борисполь» захотел получить приложение доступное на всех популярных смартфонах (iOS, Android, Windows phone), а так же на планшетах под управлением Windows 8.

Windows phone

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

iOS

Публикация в AppStore также прошла без затруднений, однако прохождение всех этапов заняло неделю.

Android

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

Windows 8

Вдохновленные простотой публикации в магазине Windows phone мы ожидали того же и в работе с Windows 8. Однако, при публикации возникли некоторые сложности.

Первый отказ системы мы получили с формулировками:

• Ваше приложение не соответствует требованию 4.1. (Если приложение имеет сетевые возможности, оно должно содержать заявление о конфиденциальности). Подробнее

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

• Ваше приложение не соответствует требованию 6.8. (Вы должны предоставить локализованные снимки экрана приложения для каждого поддерживаемого языка). Подробнее

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

Второй отказ был получен с формулировкой:

• Ваше приложение не соответствует требованию 2.3 (Приложение не должно отображать рекламу с помощью собственного описания, плиток, уведомлений, панели приложения или после быстрого проведения пальцем от края). Подробнее

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

Плюсы и минусы выбранных подходов

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

1. решение реализовать кроссплатформенное ядро на Xamarin позволило существенно сократить время разработки и тестирования бизнес-логики приложения
2. решение разворачивать серверную часть в облаке Windows Azure дало возможность:

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

Недостатки у выбранного подхода такие:

1. приложение получилось довольно тяжелым (около 19 Мб), поскольку Xamarin увеличил его размер (iOS и Android) − это вызвало негативные отзывы пользователей Android
2. у Xamarin бывают некоторые баги, которые надо репортить (они их фиксят, но не моментально).

Для сравнения размер приложений получился следующий:

• Android – 19 Мб
• iOS – 19 Мб
• Windows phone – 2 Мб
• Windows 8 – 4,5 Мб.

Немного статистики по первому внедрению

Приложение «Киев Борисполь» – это нишевое приложение. Его целевая аудитория − пассажиры аэропорта, а также люди, встречающие и провожающие их.

Необходимо учитывать, что рекламное продвижение приложения не выполнялось. Отдел маркетинга аэропорта лишь опубликовал две обзорные статьи в СМИ. На момент написания этого материала на территории аэропорта не было ни рекламного объявления, ни даже бегущей строки на экранах.

Лояльность пользователей

В среднем ежедневно среди всех пользователей:

• 8,3% − новые пользователи
• 91,7% − пользователи, которые ранее уже запускали систему.

Среднее количество установок за день

• iOS – 40/день
• Android – 20/день
• Windows phone – 18/день
• Windows 8 – 20/день.

Нас, конечно, немного удивляет такая кучность по всем ОС, поскольку опубликованные данные аналитической компании Strategy Analytics свидетельствуют о том, что устройств под управлением ОС Windows в несколько раз меньше.

Количество установок во время маркетингового воздействия

График четко показывает, что публикация в СМИ влияет на скачивание приложения около месяца. В самый пик было около 1000 установок в день только для iOS.

Оценки и отзывы

Статистика по этим показателям для нас стала полной неожиданностью:

• iOS – за все время было оставлено около 20 комментариев и оценок (в основном все оценки 5 звезд)
• Android – пользователи этой операционной системы оказались самыми придирчивыми. Часть негативных отзывов мы получили в результате отсутствия поддержки планшетов, а часть − из-за размера приложения. Заметим, что пользователей iOS абсолютно не беспокоил размер приложения
• Windows phone – всего 20 отзывов со средней оценкой 4+
• Windows 8 – было поставлено 80 оценок с отзывами и все по 5 звезд. И это притом, что приложение опубликовано в магазине всего лишь два месяца, а iOS уже более полугода.

Трудозатраты на реализацию системы и кастомизацию под заказчика

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

Задача	Трудозатраты (часов)	Выполненные работы
Серверная часть	420	Проектирование и разработка
Ядро клиента	300	Проектирование и разработка
Графический интерфейс
Android	200	Разработка UI
iOS	140	Разработка UI
Windows 8	160	Разработка UI
Windows phone	180	Разработка UI
Создание дизайна	100	Создание макета
Администрирование	150	Настройка инфраструктуры, автосборок и развертывания решения в облако
Аналитика	350	Проектирование юзабилити системы и UI, написание спецификаций, коммуникации с заказчиком и ИТ-специалистами заказчика
Тестирование	300	Тестирование приложения на всех этапах разработки

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

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

P.S. Будем признательны Вам за ответы на такие вопросы:

1. Что мотивирует пользователей Windows 8 оставлять такое количество хороших отзывов и оценок?
2. Почему, несмотря на разницу в количестве устройств для различных ОС, ежедневное количество установок в среднем практически одинаково для всех платформ?