- PVSM.RU - https://www.pvsm.ru -
В статье описана история поиска удачных решений одной аутсорсинговой американо-украинской компании. События не вымышлены, совпадения не случайны.
В последние несколько лет рынок мобильных платформ поставил разработчиков и клиентов перед выбором: разрабатывать под какую-то одну платформу, фокусироваться на двух популярных платформах, либо же пытаться охватить все популярные решения для мобильных устройств. И, конечно же, сами клиенты зачастую хотят покрыть наибольшую долю рынка мобильных платформ. Но в таком случае придется писать как минимум четыре (!) мобильных приложения под iOS, Android, Blackberry и Windows Phone.
И тут возникает необходимость поиска компромиссного решения между стоимостью, производительностью и функциональностью, поскольку написание отдельного нативного приложения под каждую из платформ ведет к многократному удорожанию разработки:
Но, если нет категоричной привязки к управлению железом, нет необходимости обрабатывать большие массивы данных на устройстве, то можно попробовать найти более экономичные в разработке решения.
Таким образом, мы подходим к проблеме выбора менее трудоемкого и дорогостоящего решения для реализации рядового приложения для всех популярных платформ без потери качества и скорости работы. Проведя небольшое исследование по освещенности данной проблемы ранее, мы нашли несколько публикаций, которые подтверждали правильность хода наших мыслей в таких авторитетных источниках, как Mashable.com [1], Forbes.com [2]. Как и следовало ожидать, никто не предлагал быстрого, простого и универсального решения и мы решили провести свой анализ и найти решение, которое не будет отпугивать своей дороговизной представителей среднего и малого бизнеса, которым не всегда по карману разработка сразу нескольких нативных приложений.
Поскольку, мы уже сами сталкивались с разработкой разноплановых проектов для наших клиентов и накопили огромный опыт, мы уже знали преимущества и недостатки каждого из вариантов. У чистых кросплатформенных приложений, реализованных, к примеру при помощи Phone Gap [3] были серьезные проблемы с производительностью при реализации под нужды заказчика сложных кастомизированных решений.
С чистыми мобильными сайтами для смартфонов проблема была немного иного характера: по статистике, пользователи на четверть больше времени проводят за работой в приложениях, мобильные сайты в отличие от приложений не так интерактивны в своем интерфейсе, не доступны в режиме оффлайн и часто имеют ограниченную функциональность (к примеру, доступ к данным о местоположении пользователя).
Следует также обозначить существование глобального преимущества нативных приложений: говоря о разработке под каждую из платформ нативного приложения, мы подразумеваем, что приложение по умолчанию кэширует максимум информации на стороне клиента. Когда же мы говорим о решении, основанном на любом веб-интерфейсе (будь то сайт либо мобильное веб-приложение), зачастую при разработке не уделяется достаточного внимания уровню кэширования данных, а следовательно производительность может пострадать.
Также, для работы приложения, основанного на веб-интерфейсе в любом случае понадобится доступ к интернет. Но, если мы делаем приложение на основе клиент-серверного решения, которое на стороне сервера производит огромные объемы вычислений, а клиенту отдает уже их результаты, необходимость подключаться к глобальной сети будет скорее связана с потребностью отдавать клиенту самую релевантную информацию ежесекундно.
Проанализировав все варианты, команда пришла к выводу, что в некоторых случаях разработки кросплатформенных мобильных приложений можно получить фактически все преимущества использования нативного приложения, используя гибрид веб-сайта и приложения:
И при условии, что клиент будет подключать устройство через провайдера, обеспечивающего высокую скорость передачи данных, можно будет получить такую производительность, которая составит достойную конкуренцию производительности нативных решений. Конечно же, если клиент будет подключаться к сетям с низкой скоростью передачи данных, любое клиент-серверное приложение будет показывать менее высокую производительность вне зависимости от способа его реализации.
С ростом доли мобильного трафика возникла потребность в реализации мобильного решения для удобства пользователей на сайте Pikaba.com.
В начале 2012 года на нашей базе было реализовано кросплатформенное мобильное приложение на jQuery Mobile Framework. При этом уже использовался гибрид сайта с браузерной обверткой: кастомизированные шаблоны, стили и переходы между экранами.
Всё это приводило к тому, что скорость работы приложения на конечном устройстве оставляла желать лучшего и пришлось искать более изящное и производительное решение, которое будет менее затратно, чем написание нативных приложений под каждую из платформ. И команда разработчиков нашла его: SPA сайт на JavaScript, который должен был загружаться в приложение, основанное на браузере с урезанным браузерным функционалом.
Оставалось самое интересное: выбрать фреймворк для работы с JavaScript. Среди наиболее вероятных кандидатов можно указать Backbone.JS Framework [4] и Google Closure Tools [5]. О выборе того или иного стека технологий можно долго размышлять и, скорее, это дело вкуса, привычки и привязанности в принятии решения в пользу того или иного фреймворка, однако мы остановили свой выбор на Google Closure Tools. Определяющими стали такие параметры:
К тому же, не смотря на то, что компилятор JavaScript от Google в принципе был всеядным и мог бы работать с любым фреймворком (к примеру, тем же самым Backbone.JS), команда разработчиков решила остановиться на тандеме двух продуктов от одной компании, поскольку связка Google Closure и компилятора обещала иметь долгосрочную поддержку со стороны Корпорации Добра и первоочередное внедрение самых новых технологий.
Определившись со стеком технологий, к концу 2012 года мы приступили к разработке кросплатформенного гибридного мобильного приложения с минимальным объемом функционала, который позволял бы пользователям:
Таким образом, первоочередной задачей было создать весь необходимый функционал для покупателей. Функционал для продавцов должен был реализовываться позднее.
Также перед разработчиками стояла задача разработать свой MVC Framework для взаимодействия c Google Closure. Конечно же, никто не забывал о существовании таких фреймворков, как AngularJS [8], EmberJS [9], KnockoutJS [10], в которых реализована модель MVC изначально и взаимодействие с UI было бы проще и сводилось бы к минимуму. Но “плюшки” от Google Closure Tools в виде всеядного компилятора, поддержки и инструментов для написания юнит-тестов стали достойной платой за эти незначительные неудобства.
По итогу, вышеобозначенный функционал был написан и оттестирован гораздо быстрее, чем предыдущее решение, поскольку использовался TDD [11].
Конечно же, не бывает универсальных решений для всех запросов клиентов, но наша команда для себя нашла одно из решений, которое, при своей относительной финансовой экономичности, является неплохой заменой реализации нативного приложения под несколько платформ и покрывает довольно-таки немалую долю потенциальных заказов на разработку приложений.
Гибридное решение при помощи мобильного сайта с обверткой тем не менее остается мобильным сайтом со всеми его преимуществами: мы можем подключать 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
Источник [12]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/mobile-development/40218
Ссылки в тексте:
[1] Mashable.com: http://mashable.com/2012/02/16/cross-platform-app-design-pros-cons/
[2] Forbes.com: http://www.forbes.com/sites/fredcavazza/2011/09/27/mobile-web-app-vs-native-app-its-complicated/
[3] Phone Gap: http://phonegap.com/
[4] Backbone.JS Framework: http://backbonejs.org/
[5] Google Closure Tools: https://developers.google.com/closure/
[6] Jasmine: http://en.wikipedia.org/wiki/Jasmine_(JavaScript_framework)
[7] Model–view–controller: http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller
[8] AngularJS: http://angularjs.org/
[9] EmberJS: http://emberjs.com/
[10] KnockoutJS: http://knockoutjs.com/
[11] TDD: http://en.wikipedia.org/wiki/Test-driven_development
[12] Источник: http://habrahabr.ru/post/188830/
Нажмите здесь для печати.