Статьи

Автономные возможности: собственные мобильные приложения и мобильные веб-приложения

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

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

Итак, когда работникам нужны возможности автономной работы с мобильными устройствами, нужно ли разрабатывать собственное мобильное приложение на устройстве, например, с Objective-C для iPhone, или мобильное веб-приложение является приемлемым вариантом?

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

Краткий ответ: Мобильные веб-приложения готовы к работе в автономном режиме

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

Как возможно автономное веб-приложение?

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

Мобильные веб-приложения могут быть построены с тремя основными возможностями, и все они являются частью новых стандартов HTML5:

  1. Кэширование страниц в браузере приложений
  2. Локальное хранилище
  3. Локальная база данных

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

Локальное хранилище — это стандарт, который сохраняет данные локального веб-приложения (даже когда браузер выключен), используя систему ключ / значение, которая работает аналогично куки-файлам браузера. Однако он отличается от файлов cookie браузера двумя важными способами. Во-первых, куки-файлы отправляются на сервер при каждом HTTP-запросе, и для повторной отправки всех автономных данных, когда серверу это не нужно, потребуется много пропускной способности. Во-вторых, максимальный размер файлов cookie составляет около 4 КБ, в то время как локальное хранилище обычно дает приложению до 5 МБ данных для работы с каждым доменом. 5 МБ может показаться не таким уж большим, но при аккуратном использовании это может очень сильно сказаться на автономном локальном хранилище.

Локальная база данных снимает ограничение в 5 МБ для локального хранилища и позволяет индексировать данные, чтобы можно было быстро запросить несколько свойств. В настоящее время это только предлагаемый стандарт HTML5; до сих пор только Internet Explorer и Firefox реализовали это. Safari и Chrome используют устаревшую устаревшую систему под названием Web SQL. Это означает, что если вам нужен этот уровень функциональности, то для поддержки обоих стандартов во всех основных браузерах требуется значительное количество дополнительной работы и сложности. Надеемся, что это не всегда так, и основные браузеры будут соответствовать окончательным спецификациям HTML5.

Итак, является ли мобильное веб-приложение хорошим решением для автономных функций или нет?

Ключевым моментом здесь является то, нужны ли вашему приложению более высокие лимиты хранения (более 5 МБ) и функции индексирования, которые поставляются с локальной базой данных. Если требуется локальная база данных и поддержка основных браузеров, она объединяет колоду с веб-приложением из-за дополнительной работы и сложности, необходимых для поддержки двух совершенно разных стандартов.

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

Чтобы решить, достаточно ли хорошо локальное хранилище, рассмотрите следующие ограничения для приложения:

  1. Общий объем данных, которые вам нужно хранить в автономном режиме
  2. Количество элементов данных (записей), которые необходимо хранить в автономном режиме
  3. Количество свойств данных (полей), которые необходимо найти в

Если вам требуется менее 5 МБ в автономном режиме, локальное хранилище отвечает всем требованиям. Если у вас есть большое количество записей, но обычно только одно поле для поиска, локальное хранилище по-прежнему хорошо подходит. Если у вас есть много полей для поиска, но общее количество записей невелико, опять-таки Local Storage будет работать хорошо.

Ответив на эти вопросы о вашем приложении, вы должны иметь представление о практичности мобильного автономного решения.

Есть гораздо больше для решения натив против веб

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

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

Наконец, имейте в виду, что «натив против сети» — это упрощение выбора. Мобильные веб-приложения можно создать, просто добавив тег видового экрана на существующий сайт, адаптивный рендеринг (медиазапросы CSS) и выделенные представления для мобильных устройств. Нативные приложения можно создавать с помощью инструментария вендора (например, Objective-C), или с помощью платформы абстракции (например, Titanium), или связывая HTML с собственной библиотекой (например, Phonegap). Дилемма «натив против паутины» не должна рассматриваться как две крайности; на самом деле это континуум выбора от одного конца спектра к другому.

Думай офлайн

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

Есть ли у вас опыт использования кеширования HTML5, локального хранилища или локальных баз данных? Используете ли вы какие-либо мобильные веб-приложения, использующие автономное хранилище?