Потенциальному
заказчику от бизнеса надо понимать преимущества и слабые стороны предлагаемой
реализации кроссплатформенности, чтобы потом не пришлось заказывать эту работу
заново другой команде. По большому счету, разных технических подходов немного:
нативные приложения для каждой платформы, универсальные веб-приложения,
использование кодогенераторов для создания нативных приложений и гибридные
решения.
Не нужно
забывать, что мобильное разнообразие не заканчивается на уровне операционных
систем и средств разработки (которые, кстати, существуют в нескольких версиях).
На рынке представлены устройства различных форм и размеров, с разным
разрешением экрана. Даже iPad и
iPad mini,
iPhone 4 и
iPhone 5 – это не одно и то
же. Что уж говорить об
Android-устройствах!
Есть очень
много
унаследованных устройств, особенно в странах третьего мира, которые, тем
не менее, активно используются, и поставщики услуг не хотят терять своих
клиентов даже в самых отдаленных уголках
Африки или
Индии. Кстати, аналитики
редко учитывают этот фактор, увлекаясь вместе с вендорами оценкой перспектив
новейших моделей модных гаджетов, игнорируя суровую правду жизни, где, например,
приложения ОС
Symbian
(которую уже похоронили) по-прежнему нужны.
Разработчики
компании Octopod из
Санкт-Петербурга нацелены на создание универсальной
платформы, обеспечивающей поддержку максимального количества устройств и
операционных систем. Поэтому им приходится проводить широкомасштабное
тестирование своего продукта на всевозможном оборудовании. Они подсчитали, что
встречается более десяти разных размеров и пропорций экранов, используется
более 30 режимов разрешения и более 2 тыс. моделей
мобильных телефонов,
смартфонов и
планшетов. Вся эта груда
гаджетов, используемых для тестирования,
весит более 50 килограмм.
Нативные
приложения: за и против
Каждая
мобильная платформа предлагает свой инструментарий для разработки приложений.
Безусловно, с технической точки зрения это наилучшее решение – тогда ваше
приложение сможет использовать все особенности и преимущества платформы,
покажет наилучшую производительность и будет оптимально расходовать ресурсы. Но
что скажет бизнес?
Если у вас
есть неограниченный запас времени и денег, разрабатывайте нативные
мобильные
приложения для каждой платформы. Если у вас немного меньше ресурсов, нужно
искать разумный компромисс, оптимизируя цену, качество и скорость разработки.
Пожалуй,
этим все сказано. Рынок труда мобильных разработчиков крайне перегрет, их везде
ждут с распростертыми объятиями и в случае любого конфликта с
работодателем они
легко меняют компанию. Собрать команду
программистов, одинаково хорошо знающих
хотя бы iOS и Android,
практически нереально, для этого нужны слишком разные навыки –
Objective-C для
iOS и Java для
Android, плюс специфические
SDK. Поэтому придется содержать две, три или даже четыре команды,
если нужно поддерживать еще
BlackBerry и Windows.
Дорого и велики риски, что продукты окажутся ограниченно совместимыми по
user experience –
каждая команда создаст уникальное решение, используя особенности своей
платформы. Резюме: если широкое покрытие рынка важно, лучше избегать создания
нативных приложений и выбрать какой-либо из вариантов кроссплатформенной разработки.
Веб-приложения
на мобильных устройствах
Все
смартфоны и планшеты сегодня снабжены веб-браузером, что позволяет
просматривать любые сайты и запускать почти любые
веб-приложения как есть, без
доработки. Нельзя, однако, сказать, что это нравится пользователям – если сайт
не был адаптирован для просмотра через маленький
экран смартфона, то
пользователь обратится к этой возможности только в самом критическом случае.
Поэтому разработчикам приходится создавать специальные версии сайтов для
мобильных устройств, которые отличаются дизайном, размером управляющих
элементов и структурой.
В
принципе, для некоторых областей этого вполне достаточно. Например, для чтения
газет и новостных сайтов на
iPad или
Galaxy.
Пользователям таких приложений не нужна расширенная функциональность и какие-то
особые сервисы, поэтому ограничения, присущие такой архитектуре, являются
приемлемыми: отсутствие доступа к датчикам и кнопкам
гаджета, невозможность
использования специфичекских функций пользовательского инттерфейса, необходимость
постоянного подключения к интернету и др. Это компенсируется скоростью и
простотой разработки.
В
простейшем варианте на мобильном устройстве вам нужен только браузер, вся
логика и пользовательский интерфейс реализуются на сервере при помощи обычного
инструментария
Java,
PHP или
Ruby. Возможно
подключение веб-сервисов третьих фирм, что позволяет строить
облачные
приложения.
Более
продвинутая веб-архитектура подразумевает использование на стороне клиента
активных компонентов JavaScript,
обеспечивающих работу пользовательского интерфейса, а бизнес-логика по-прежнему
исполняется на сервере. Из популярных фреймворков можно назвать zepto.js,
jQuery, Sencha,
jQTouch, Wink Toolkit, joApp – и многие
другие.
Для
создания полноценных
мобильных приложений веб-архитектура, видимо, не лучший
выбор, в силу упомянутых ограничений. Но для быстрого прототипирования этот
путь вполне подходит.
Следует
сказать, что большие надежды в области создания кроссплатформенных приложений
возлагались на HTML5, который
должен был воплотить многие требования по работе с
мультимедийным контентом и
позволить строить продвинутые
пользовательские интерфейсы. Разработка стандарта
идет с 2004 г и, увы, еще не завершена, консорциум
W3C обещает выпустить стабильную
спецификацию лишь в конце 2014 г.
Первоначальный
энтузиазм по поводу нового стандарта поугас: стало очевидно, что 100%-й
совместимости со всеми платформами и устройствами все равно достичь не удастся,
и разработчикам также придется учитывать особенности браузеров.
Инструментарий: богатый
выбор
Если вас
не устраивает ограниченная функциональность веб-приложений, и по экономическим
соображениям нет смысла вкладываться в разработку
нативных приложений под все
нужные платформы (даже в случае, когда их всего две –
iOS и
Android), то придется искать
какой-то третий путь, позволяющий и сэкономить и обеспечить нужное покрытие
рынка.
Использование
кодогенераторов подразумевает, что на основе единой модели автоматически
создается несколько нативных приложений, можно сказать "one language to
build them all". Этот подход применяется, когда нужен доступ к
оборудованию на физическом уровне и важно обеспечить
пользовательский интерфейс
в нативном стиле. В качестве примера можно назвать продукты Applause и Mono.
Недостатком кодогенераторов является необходимость заново пересобирать
приложения под все платформы при внесении изменений. Фактически на выходе все
равно имеется несколько нативных приложений, которые надо по отдельности
публиковать
в магазинах вендоров.
Более
перспективным, по мнению аналитиков, является гибридный подход.
Gartner говорит,
что гибридные приложения, которые предлагают баланс между
HTML5 веб-приложениями и нативными
разработками, будут использоваться более чем на половине мобильных устройств к
2016 г.
Категория |
Нативные |
Гибридные |
Веб |
Потребители |
40 |
40 |
20 |
Корпорации |
10 |
60 |
30 |
Сегмент
гибридных решений нельзя считать монолитным — на самом деле разработчики
предлагают очень разные архитектуры, нацеленные на разные бизнес-задачи. На
одном полюсе находятся конструкторы приложений, предлагающие набор типовых
функциональных блоков, из которых можно быстро собрать готовое приложение. На
другом – платформы с собственным
middleware, которые, оставаясь универсальными, позволяют
проектировать уникальные приложения, использующие особенности разных платформ.
Общим в
архитектуре гибридных решений является использование нативных библиотек и
JavaScript для
реализации пользовательского интерфейса. Из числа таких платформ можно
упомянуть, например, PhoneGap.
Нативная оболочка работает как прокси, позволяя
интерфейсу на JavaScript обращаться
к вызовам API
мобильной ОС и датчикам устройства, чего нельзя сделать
напрямую из
браузера.
К
гибридным можно отнести также интерпретируемые приложения, которые используют
нативные
API, но
бизнес-логику описывают на своем абстрактном уровне. Интерфейс чаще всего тоже
построен на JavaScript или
Lua.
Представители этого семейства – Appcelerator,
iPFaces, JMango, Octopod и Prhomobile от
Motorola.
Если
требуется полноценное приложение, отвечающее всем нуждам заказчика, одной
помощью конструктора не обойтись – для полноценного мобильного решения нужен
системный и комплексный подход к разработке. Несмотря на кажущееся усложнение
архитектуры, скорость разработки при использовании подобных платформ
увеличивается в несколько раз, а созданные с их помощью приложения работают не
менее производительно, чем нативные.
Новые
вызовы
Мир
мобильных платформ сегодня чрезвычайно разнообразен. Унификация, как это
случилось с
десктопами под
Windows,
мобильным устройствам не грозит – на этом рынке продолжается кипучая
деятельность.
Несмотря
на то, что планы разработчиков постоянно меняются, не стоит расслабляться и в
отношении еще двух систем, которые смогут работать и на мобильных устройствах,
–
ChromeOS и
FireFoxOS. Так что рыночный пейзаж средств создания кроссплатформенных
приложений станет скоро еще сложнее.