Существует три основных причины, по которым ваш клиент может потребовать собственное приложение для телефона, а не веб-приложение:
- Родные приложения работают быстрее. Это, безусловно, имеет значение, если вы создаете следующую Angry Birds, но лишь немногие приложения нуждаются в игровой отзывчивости. (Тем не менее, с небольшой осторожностью можно создать быструю игру с использованием технологий HTML5. Другой вопрос, будет ли она работать на разных устройствах).
- Клиент не знает ничего лучшего: «Приложения классные! У всех наших конкурентов есть приложения — нам нужно одно ». Небольшое образование решает эту проблему.
- Мобильные приложения работают в автономном режиме. Но веб-приложения тоже могут — просто технологии относительно новы, и мало кто из нас беспокоится. Еще.
Внедрение AppCache для работы веб-приложения в автономном режиме возможно в течение нескольких лет . Процесс определяет, какие файлы должны быть кэшированы, чтобы браузер мог выполнить приложение, когда интернет-соединение падает. Это достаточно просто, но:
- Веб-разработчики содрогаются при мысли об ошибке подключения. Я пишу эту статью в поезде, и я чувствую, что потерял несколько основных органов. Хотя связь улучшается, она все еще остается проблемой для жителей пригородной зоны и многих миллионов людей, которые живут в отдаленных районах и развивающихся странах.
- Добавление автономных возможностей в существующее приложение затруднительно. Вам необходимо переделать вызовы Ajax и сетевые запросы, а затем рассмотреть возможность изменения состояния подключения. Но что если мы рассмотрим это с самого начала?
Mobile-first признан хорошей практикой. Вы начинаете с простого — возможно, линейного — просмотра вашего сайта, который работает во всех браузерах независимо от возраста и устройства. Более современные браузеры затем используют медиазапросы для применения улучшений стилей и представления более типичного рабочего стола на больших экранах. Другими словами, макет постепенно улучшается для лучших браузеров, использующих большие дисплеи.
Можно ли использовать подобную методологию для автономных приложений? Приложение предполагает, что оно находится в автономном режиме, и действует соответствующим образом. Когда связь возобновится, приложение будет постепенно улучшено для извлечения дополнительных данных или сохранения в облаке.
Offline-first — это концепция, которая обсуждалась несколькими другими, хотя и не получила широкого распространения. Есть несколько общих понятий, которые делают его жизнеспособным.
1. Удалить доверие сервера
Большая часть логики приложения должна быть перенесена с сервера на клиент. Сервер, по сути, станет легким хранилищем данных, но, что немаловажно, клиентское приложение должно работать независимо от состояния соединения.
2. Создайте прокси данных на стороне клиента
Вы не можете зависеть от вызовов Ajax. Прокси-сервер данных будет управлять всей маршрутизацией, например
- Если соединение доступно, можно выполнить Ajax-вызов живому серверу (при условии, что это необходимо).
- Если соединение недоступно — или происходит сбой во время вызова Ajax — используется localStorage, IndexDB или другой подходящий механизм хранения на стороне клиента.
Обратите внимание, что HTML5 Service Workers направляют все запросы данных через именованный файл JavaScript. В то время как в настоящее время существует небольшая поддержка или стандартизация браузера, технология специально разработана для этой цели.
3. Синхронизировать, когда это возможно
Вам потребуется процесс для обработки синхронизации между клиентом и сервером при восстановлении соединения. Это можно сделать эффективным, используя фоновые процессы Web Worker и пакетную загрузку / загрузку в периоды простоя.
4. Учитывайте факторы использования устройства
Мобильные устройства имеют дополнительные сложности. Например:
- Акт переключения на другое приложение может закрыть браузер. В идеале ваше веб-приложение должно всегда сохранять состояние приложения, чтобы пользователь мог вернуться в место, которое он оставил.
- API видимости страницы можно использовать для снижения требований к обработке и пропускной способности, когда ваше приложение не работает на открытой вкладке браузера.
- В идеале ваше приложение должно использовать API-интерфейс состояния батареи, чтобы вести себя хорошо. Например, он может вернуться к localStorage, когда уровень заряда батареи упадет ниже критического уровня, даже если соединение доступно.
5. Тест. Тогда проверьте снова.
Тестирование является сложным, так как ваше приложение должно оставаться работоспособным независимо от возможности подключения, например
- Приложение установлено на устройстве, которое не поддерживает localStorage или другую важную технологию.
- Связь падает и перезапускается через случайные интервалы.
- Приложение кешируется, но соединение падает до того, как может быть установлена первая связь с сервером.
- Приложение запускается на двух или более устройствах одновременно.
Тщательное тестирование на ряде устройств представляется единственным вариантом.
Не каждое приложение может окунуться в автономный режим; многопользовательская игра была бы бессмысленной. Тем не менее, этот метод может использоваться многими веб-приложениями, если он рассматривается с самого начала. Мне это нравится, но я подозреваю, что накладные расходы на реализацию в существующих системах могут сделать отдельные мобильные приложения более рентабельными!
Вы рассматривали офлайн-сначала? Вы уже делаете это? Были ли другие осложнения? Или это слишком много усилий для слишком маленькой выгоды?