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

• собственный код,
• гибридные мобильные приложения,
• мобильные веб-приложения.

Разработка приложения в HTML5 – это в первую очередь возможность создания универсального для нескольких платформ кода, вместо того, чтобы создавать все приложение с нуля для каждой платформы. Таким образом, пользовательский интерфейс, а может быть и весь интерфейс в целом, будет сделан в HTML.

«Гибридные приложения» — это термин, который зачастую используется для приложений, пользовательский интерфейс которых в основном разрабатывается в HTML5 и которые опираются на естественный код для доступа к функциям конкретных устройств, которые не доступны для веб-приложений. Основная часть этого естественного кода не является визуально доступной, происходит простая передача данных в HTML5 слой приложения, где они предоставляются пользователю. Подобную возможность обеспечивают такие библиотеки, как например, PhoneGap.

Хочу отметить, что основная часть обсуждений посвящена вовсе не значимости HTML5 для создания пользовательского опыта взаимодействия с мобильными приложениями. Марк Цукерберг описывает некоторые трудности, с которыми ему довелось столкнуться при разработке HTML5 версии Facebook для мобильных устройств. С этими трудностями сталкиваются многие разработчики. Некоторые проблемы с Facebook, скорее всего, могут быть решены путем использования методов, подробно описанных Sencha в его Fastbook приложении и LinkedIn в его публикации с бесконечной прокруткой. Несмотря на последнюю статью, LinkedIn призвает переключаться между двумя направлениями и в большей степени склоняться к использованию собственного кода.

Почему бы не воспользоваться сочетанием технологий?

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

Нужно понимать, что разработка пользовательского интерфейса с помощью двух или более различных технологий имеет некоторые недостатки. Главным образом, вам потребуются разработчики, которые смогут работать как с собственным, так и с HTML5 кодом. Часть пользовательского интерфейса, созданная с помощью собственного кода, не может быть так просто использована на других платформах и должна быть переработана. Учитывая широкую сферу знаний, необходимых для использования этой техники и трудности, описанные выше, хочет ли кто-то из вас использовать технологию, которая предполагает смешивание двух типов кода для построения пользовательского интерфейса?

HTML для большого шаблона документа.

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

Рассмотрим iPad приложение, скрин которого вы можете увидеть ниже. Данное приложение было разработано для компании, занимающейся генетическим секвенированием (определение первичной структуры макромолекул). Перед нами пример гибридного интерфейса:

(Посмотреть увеличенную версию).

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

Подобные документы лучше всего создавать с помощью HTML. Попытки создать нечто подобное с помощью собственного кода повлекли бы за собой значительно большие усилия, при этом вряд ли бы удалось в полной мере достигнуть требуемых результатов. В этом приложении HTML5 шаблон создан с помощью GRMustache библиотеки для iOS.

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

Обратите внимание, что, когда пользователь выполняет прокрутку вверх, собственный заголовок документа в верхней части начинает динамически изменяться. Этот механизм позволяет отображать больше содержимого и демонстрирует, как различные части пользовательского интерфейса могут взаимодействовать друг с другом. Чтобы загрузить соответствующие документы пользователь может кликнуть по ссылкам или нажать HTML кнопки, что вызовет встроенную программу веб просмотра. Далее в этой статье мы увидим, что создать связь между собственным и HTML кодом относительно просто.

Какой подход лучше.

Мы уже видели, что приложение может легко сочетать две технологии, чтобы обеспечить удобство работы. Для iOS вы можете использовать собственную функцию UINavigationController и связанную с ней функцию UINavigationBar или использовать панель меню в приложениях на базе Android. Остальная часть экрана может быть визуализирована с помощью HTML5.

На изображении ниже показан внешний вид приложения, в котором HTML5 используется для создания покупательской корзины, но сохраняет собственный контроллер навигации и панель вкладок для перемещения между страницами в рамках рабочего процесса:

(Посмотреть увеличенную версию).

(Посмотреть увеличенную версию).

В этом случае HTML5 контент загружается с сервера, и именно сервер контролирует рабочий процесс в течение всего опыта взаимодействия пользователя с приложением. API (программный интерфейс приложения) позволяет поставляемому сервером HTML контенту изменять содержимое навигационный панели, чтобы удовлетворять требованиям рабочего процесса.

Вы можете увидеть, что собственные элементы управления, такие как MapKit на IOS, обеспечивают превосходную производительность, которой можно достичь и с помощью HTML5. В этом случае, ваш HTML5 код можно связать с собственным слоем iOS и представлять собственный контент в отдельности или совместно с HTML контентом.

(Посмотреть увеличенную версию).

(Посмотреть увеличенную версию).

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

После того как пользователь завершил работу с картой, результаты взаимодействия могут быть переданы обратно в HTML5 документ для дальнейшей обработки. В зависимости от того, как вы хотите структурировать приложение, собственные «виджеты» могут быть реализованы для каждой платформы в отдельности (iOS, Android, Windows и т. д.), а затем будут вызываться из общего ядра HTML5 приложения. В рамках этой стратегии, HTML5 код будет обеспечивать рабочий процесс для приложения, а собственный контент будет функционировать в фоновом режиме, ожидая, когда возникнет необходимость его вызова.

Если все сделано правильно, то пользователь даже не сможет определить, какие части интерфейса сделаны в собственном коде, а какие в HTML.

Простота обновления приложения.

Большинство людей знают, что для того, чтобы обновить собственный код в IOS или Android приложении, необходимо повторно отправить приложение через каналы публикации для этой платформы. В случае IOS, чтобы получить обновление приложений, утвержденное Apple, может понадобиться до семи дней. Данная процедура обновления приложений крайне неудобна и отбирает слишком много времени, что не удовлетворяет маркетинговым требованиям и возможности быстро адаптироваться к изменения бизнес-среды. Создание элементов, относящихся к пользовательскому опыту взаимодействия, посредством HTML и JavaScript означает, что их обслуживание может проводиться динамически.

Как уже отмечалось ранее, вполне возможным является создание обслуживаемого контента, вызываемого собственным кодом вашего приложения. Такая возможность появляется благодаря механизму, который позволяет HTML коду взаимодействовать с собственным кодом в PhoneGap через интерфейс PhoneGap плагина. В рассмотренном нами ранее приложении, также используется эта техника. Данный подход был выбран главным образом так, чтобы можно было вносить в процедуру покупки требуемые изменения, без необходимости совершения дополнительных операций с собственным приложением. Страница, обслуживаемая из интернета, теперь может легко отображать визуализированную с помощью собственного кода карту, используя любую возможность отображения, представляемую устройством. Хорошо структурированный интерфейс между вашей веб-страницей и окружающим собственным контейнером делает это возможным.

Внимательно посмотрите на контент!

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

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

Обратите внимание на следующие моменты.

• Брать контент непосредственно с веб-сервера это хорошо, но только в том случае, если пользователь находится в сети. Помните, что у мобильных приложения довольно часто возникают проблемы с подключением. Что произойдет, если подключение к сети прервется? Некоторые функции можно было бы сохранить за счет использования AppCache, но для этого заранее нужно все спланировать. Другой подход с обновлением HTML контента, хранящегося локально будет рассмотрен в следующем разделе.
• Хостинг контента на веб-сервере требует наличия определённой инфраструктуры. В настоящее время существует множество “компонентов”, которые должны быть рассмотрены как часть вашего полного приложения. Это уже не просто какой-то собственный код, поскольку он был введен в действие через AppStore и потенциально представляет собой набор конечных услуг. Необходимо соблюдать осторожность и следить за тем, чтобы обновления на сайте не противоречили существующему интерфейсу в мобильном приложении. Имейте в виду, что если возникнет необходимость изменения веб-сайта и придется выполнять обновление самого приложения, вам потребуется достаточно много времени, при этом нет гарантии успешности результата. По этой причине может возникнуть необходимость в пометке контента на веб-сайте версиями, чтобы иметь возможность работать с более старыми версиями приложения. Это очень похоже на функцию управления версиями, встроенную в некоторые REST интерфейсы для поддержки совместимости со старым клиент-приложениями.
• Apple неодобрительно относится к приложениям, которые являются лишь веб-просмотрщиками, завернутыми в собственное приложение. Материалы для IOS AppStore скорее всего не будут утверждены, если вы сделали не что иное как обертку веб-контента в собственное приложение. Apple предполагает, что ваше приложение будет использовать некоторые функции устройства, что невозможно осуществить в Mobile Safari. Проанализируйте, может ли ваше приложение извлечь выгоду от интеграции с камерой, списком контактов, локальным хранилищем данных, от работы в автономном режиме и так далее. Кроме того, нужно помнить, что контент, обслуживаемый веб-просмотрщиками должен всегда соответствовать оригинальному представлению приложения. Если вы создаете приложение с одной тематикой, а потом вдруг начинаете размещать совершенно не связанный с ней контент в веб-просмотрщике, то это будет нарушать правила Apple и приложение может быть удалено из AppStore. В соответствии с соглашением iOS разработчик не может выполнять изменения или обновления, которые значительного влияют на функциональные возможности приложения, по сравнению с первоначальной версией, которая была размещена на App Store.

Установка обновлений для вашего приложения.

Вы можете влиять на способ загрузки веб-контента, как уже было описано выше, и обновлять локальный контент из интернета. При таком подходе веб-контент (HTML, CSS и JavaScript) передается на сервер и загружается на мобильный клиент приложения всякий раз, когда выполняется обновление контента. Обновленный код может изменять пользовательский интерфейс, прикладной поток и так далее, без необходимости обновления приложения разработчиком через iOS App Store или Google Play.

Обратите внимание, что подобным способом вы можете обновлять только HTML, CSS и JavaScript код; собственный код не может быть обновлен. Apple допускает использование JavaScript кода, который будет загружаться и выполняться до тех пор, пока он работает в контексте UIWebView элемента управления в приложении IOS. Это единственная ситуация, в которой на iOS допускается “загрузка” кода.

(Посмотреть увеличенную версию).

Приложение выше работает на платформе Android. HTML контент был загружен на клиент комплектно и в настоящее время обслуживается локально. Обратите внимание на возможность использования панели меню, которая знакома пользователям Android, для выполнения навигации. Ниже то же самое приложение, но теперь оно работает на iOS, где используется UINavigationController :

(Посмотреть увеличенную версию).

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

Возможность динамического обновления локального контента фактически является частью коммерческой гибридной платформы Trigger.IO, разработанной специально для мобильных устройств. Функция Trigger.IO выгрузки позволяет вам выполнять обновление для HTML части вашего приложения. Следует отметить, что собственный код не может быть обновлен таким же образом. Однако, если большая часть потока приложения контролируется с помощью JavaScript и дополняется естественным кодом, а затем совершаются существенные изменения в рабочем процессе вашего приложения, то динамическое обновление является возможным.

Имейте в виду, что, в соответствии с соглашением iOS разработки, любые выполняемые обновления не могут кардинально изменить назначение приложения, его функции или функциональные возможности, по сравнению с той версией, которая была размещена на App Store. Таким образом, основные релизы скорее всего будут по прежнему осуществляться в традиционной форме.

Динамическая Перезагрузка контента для разработки и тестирования.

Способность приложения динамически загружать обновления также может ускорить процесс разработки. Процесс собственной разработки приложений как на базе  IOS, так и на Android обычно предполагает выполнение компиляции кода на персональном компьютере, а затем передается на устройство для тестирования. Некоторые программы, такие как Icenium, с его инструментальными средствами LiveSync и Ion, могут осуществлять компиляцию обновлений приложения в “облачной” (модель обеспечения повсеместного сетевого доступа по требованию к общему пулу (англ. pool) конфигурируемых вычислительных ресурсов, например …

Если вы хотите прочитать полностью статью, посетите сайт наших спонсоров