Предисловие:
В статье описана история поиска удачных решений одной аутсорсинговой американо-украинской компании. События не вымышлены, совпадения не случайны.
1. Как мы искали оптимальное решение
В последние несколько лет рынок мобильных платформ поставил разработчиков и клиентов перед выбором: разрабатывать под какую-то одну платформу, фокусироваться на двух популярных платформах, либо же пытаться охватить все популярные решения для мобильных устройств. И, конечно же, сами клиенты зачастую хотят покрыть наибольшую долю рынка мобильных платформ. Но в таком случае придется писать как минимум четыре (!) мобильных приложения под iOS, Android, Blackberry и Windows Phone.
И тут возникает необходимость поиска компромиссного решения между стоимостью, производительностью и функциональностью, поскольку написание отдельного нативного приложения под каждую из платформ ведет к многократному удорожанию разработки:
- портирование или разработка под каждую новую платформу требует аналогичных затрат времени по написанию кода;
- увеличивается количество разработчиков, задействованных в разработке;
- вследствие, в разы возрастает цена разработки.
Конечно же, остаются ситуации, когда стоит писать нативные приложения:
- необходима очень высокая производительность;
- решение требует обработки большого количества данных на стороне клиента;
- при написании утилит по управлению железом либо операционной системой;
- при создании решений на основе видео или игровых сценариев, дополнительной реальности.
Но, если нет категоричной привязки к управлению железом, нет необходимости обрабатывать большие массивы данных на устройстве, то можно попробовать найти более экономичные в разработке решения.
Таким образом, мы подходим к проблеме выбора менее трудоемкого и дорогостоящего решения для реализации рядового приложения для всех популярных платформ без потери качества и скорости работы. Проведя небольшое исследование по освещенности данной проблемы ранее, мы нашли несколько публикаций, которые подтверждали правильность хода наших мыслей в таких авторитетных источниках, как Mashable.com, Forbes.com. Как и следовало ожидать, никто не предлагал быстрого, простого и универсального решения и мы решили провести свой анализ и найти решение, которое не будет отпугивать своей дороговизной представителей среднего и малого бизнеса, которым не всегда по карману разработка сразу нескольких нативных приложений.
За эталон мы взяли лучшие характеристики нативных приложений:
- лучшую производительность;
- доступ к настройкам hardware (камера, локальное хранилище данных, микрофон), открываемый нативными API;
- отсутствие пропасти между фантазией разработчиков и возможностями платформ.
Ниже, в Таблице 1 изложены основные факторы, важные для определения оптимального варианта:
Перед нами встал выбор между другими основными популярными решениями:
- чистыми кросплатформенными приложениями (к примеру, реализованными при помощи Phone Gap);
- гибридными кросплатформенными решениями (мобильным сайтом + обверткой для каждой из платформ);
- сайт для мобильных телефонов на HTML5.
Поскольку, мы уже сами сталкивались с разработкой разноплановых проектов для наших клиентов и накопили огромный опыт, мы уже знали преимущества и недостатки каждого из вариантов. У чистых кросплатформенных приложений, реализованных, к примеру при помощи Phone Gap были серьезные проблемы с производительностью при реализации под нужды заказчика сложных кастомизированных решений.
Проблемы в разработке таких мобильных приложений при помощи Phone Gap начинались уже на ранних этапах:
- изначально фреймворк был сложен для быстрого старта;
- он имел высокий порог вхождения (разработчикам пришлось провести много времени за изучением документации по внедрению элементарных изменений в настройки);
- мы наблюдали низкую производительность приложения на выходе за счет тяжеловесности самого функционала, исходных модулей, которые сложно было кастомизировать под наши нужды;
- существующие погрешности в системе могут замедлить процесс разработки;
- доступ к операционной системе и железу устройств осуществлялся не через нативный API, а через API Phone Gap Framework, что также приводило к падению производительности и в некоторых случаях ограничивало возможности приложений.
С чистыми мобильными сайтами для смартфонов проблема была немного иного характера: по статистике, пользователи на четверть больше времени проводят за работой в приложениях, мобильные сайты в отличие от приложений не так интерактивны в своем интерфейсе, не доступны в режиме оффлайн и часто имеют ограниченную функциональность (к примеру, доступ к данным о местоположении пользователя).
Следует также обозначить существование глобального преимущества нативных приложений: говоря о разработке под каждую из платформ нативного приложения, мы подразумеваем, что приложение по умолчанию кэширует максимум информации на стороне клиента. Когда же мы говорим о решении, основанном на любом веб-интерфейсе (будь то сайт либо мобильное веб-приложение), зачастую при разработке не уделяется достаточного внимания уровню кэширования данных, а следовательно производительность может пострадать.
Также, для работы приложения, основанного на веб-интерфейсе в любом случае понадобится доступ к интернет. Но, если мы делаем приложение на основе клиент-серверного решения, которое на стороне сервера производит огромные объемы вычислений, а клиенту отдает уже их результаты, необходимость подключаться к глобальной сети будет скорее связана с потребностью отдавать клиенту самую релевантную информацию ежесекундно.
Проанализировав все варианты, команда пришла к выводу, что в некоторых случаях разработки кросплатформенных мобильных приложений можно получить фактически все преимущества использования нативного приложения, используя гибрид веб-сайта и приложения:
- для клиент-серверного приложения в любом случае нужен доступ к интернету (поскольку идет обращение к Web API);
- есть доступ к данным о местоположении;
- приложение будет доступно сразу после установки (без необходимости заходить в нативный браузер и набирать адрес в строке);
И при условии, что клиент будет подключать устройство через провайдера, обеспечивающего высокую скорость передачи данных, можно будет получить такую производительность, которая составит достойную конкуренцию производительности нативных решений. Конечно же, если клиент будет подключаться к сетям с низкой скоростью передачи данных, любое клиент-серверное приложение будет показывать менее высокую производительность вне зависимости от способа его реализации.
2. Как мы пришли к Google Closure
С ростом доли мобильного трафика возникла потребность в реализации мобильного решения для удобства пользователей на сайте Pikaba.com.
В начале 2012 года на нашей базе было реализовано кросплатформенное мобильное приложение на jQuery Mobile Framework. При этом уже использовался гибрид сайта с браузерной обверткой: кастомизированные шаблоны, стили и переходы между экранами.
Но уже на этапе реализации стало понятно, что данный фреймворк не подходит для решений, которые оперируют большими объемами данных и c реализацией большого количества кастомизированных функций:
- jQuery Mobile делал слишком много изменений в структуре (DOM);
- на серверной стороне делалось слишком много запросов к API;
- происходила двойная сериализация и десериализация данных за счет передачи данных между сервером и веб-приложением ASP.NET;
- на стороне сервера не было сжатия и оптимизации кода;
- на клиенте главным проявлением проблем в работе приложения была “задумчивость” при переходах между экранами.
Всё это приводило к тому, что скорость работы приложения на конечном устройстве оставляла желать лучшего и пришлось искать более изящное и производительное решение, которое будет менее затратно, чем написание нативных приложений под каждую из платформ. И команда разработчиков нашла его: SPA сайт на JavaScript, который должен был загружаться в приложение, основанное на браузере с урезанным браузерным функционалом.
В таком случае, мы на выходе получали сайт-приложение, которое:
- имело DOM, который был несравнимо компактнее предыдущего;
- производило вычисления на стороне сервера, при этом не нагружая клиентское устройство;
- отслеживало изменения хэштегов и подгружало асинхронно контент;
- имело фактически полный доступ к софту и железу устройства в отличие от обычного сайта, подгружаемого, через полноценный браузер;
- стоило в разработке в разы меньше, поскольку для платформ необходимо было написать только обвертку.
Оставалось самое интересное: выбрать фреймворк для работы с JavaScript. Среди наиболее вероятных кандидатов можно указать Backbone.JS Framework и Google Closure Tools. О выборе того или иного стека технологий можно долго размышлять и, скорее, это дело вкуса, привычки и привязанности в принятии решения в пользу того или иного фреймворка, однако мы остановили свой выбор на Google Closure Tools. Определяющими стали такие параметры:
- у команды уже был опыт работы с этим фреймворком, а это занижало порог вхождения в продуктивную стадию разработки приложения;
- наличие у Google собственного компилятора, который в том числе позволяет оптимизировать и собирать всесь код в один файл;
- возможность написания юнит-тестов прямо на базе Google Closure и отсутствие необходимости использовать дополнительные инструменты (например, тот же Jasmine);
- возможность реализации своего MVC (Model–view–controller) фреймворка.
К тому же, не смотря на то, что компилятор JavaScript от Google в принципе был всеядным и мог бы работать с любым фреймворком (к примеру, тем же самым Backbone.JS), команда разработчиков решила остановиться на тандеме двух продуктов от одной компании, поскольку связка Google Closure и компилятора обещала иметь долгосрочную поддержку со стороны Корпорации Добра и первоочередное внедрение самых новых технологий.
3. Как мы реализовывали проект Pikaba Mobile
Определившись со стеком технологий, к концу 2012 года мы приступили к разработке кросплатформенного гибридного мобильного приложения с минимальным объемом функционала, который позволял бы пользователям:
- авторизоваться и создавать аккаунты;
- создавать, редактировать и сохранять заявки;
- просматривать заявки, продукты и сервисы и осуществлять поиск по ним;
- осуществлять просмотр по профилям, гридам.
Таким образом, первоочередной задачей было создать весь необходимый функционал для покупателей. Функционал для продавцов должен был реализовываться позднее.
Также перед разработчиками стояла задача разработать свой MVC Framework для взаимодействия c Google Closure. Конечно же, никто не забывал о существовании таких фреймворков, как AngularJS, EmberJS, KnockoutJS, в которых реализована модель MVC изначально и взаимодействие с UI было бы проще и сводилось бы к минимуму. Но “плюшки” от Google Closure Tools в виде всеядного компилятора, поддержки и инструментов для написания юнит-тестов стали достойной платой за эти незначительные неудобства.
По итогу, вышеобозначенный функционал был написан и оттестирован гораздо быстрее, чем предыдущее решение, поскольку использовался TDD.
4. Маркетинговый Бонус
Конечно же, не бывает универсальных решений для всех запросов клиентов, но наша команда для себя нашла одно из решений, которое, при своей относительной финансовой экономичности, является неплохой заменой реализации нативного приложения под несколько платформ и покрывает довольно-таки немалую долю потенциальных заказов на разработку приложений.
Гибридное решение при помощи мобильного сайта с обверткой тем не менее остается мобильным сайтом со всеми его преимуществами: мы можем подключать Google Analytics и исследовать поведение пользователей в приложении, сегментировать аудиторию, пути ее передвижения внутри нашего сайта-приложения и производить множество аналитических операций.
Позитивным моментом также будет отсутствие острой необходимости выпускать обновления в Google Play, iTunes и других маркетах. Чтобы пользователь получил в своем приложении обновленную версию сайта с устраненными неисправностями или улучшенным функционалом, ему будет достаточно просто зайти в приложение еще раз.
К тому же это поможет клиентам сэкономить на поддержке в случае появления новых версий мобильных платформ, просто реализовав у нас новую обвертку и сфокусировавшись на улучшении базового функционала и добавление нового, не распыляясь на многократную доработку под разные платформы.
P.S. Приложение с условным названием Pikaba Mobile 2.0 уже готовится к публикации на iTunes и в Google Play, в планах — написать обвертки и протестировать приложение на Windows Phone и Blackberry OS.
P.S.S. Приобретенный опыт и уже готовую связку удалось применить уже через пару месяцев, когда появился небольшой Social Commerce проект для разработки со схожим функционалом. Мы ускорили разработку за счет использования MVC Framework из Pikaba Mobile.
Автор: pikok
