Если вы веб-разработчик, вы, вероятно, знаете о прогрессивных веб-приложениях (PWA) или уже реализовали свои собственные. Если вы не знакомы, вот обзор того, что такое прогрессивные веб-приложения и почему они важны в современной веб-разработке.
Прогрессивное веб-приложение определяется как отзывчивый, независимый от подключения, похожий на приложение, свежий, безопасный, обнаруживаемый, повторно привлекаемый, устанавливаемый и связываемый веб-интерфейс. Это длинное описание. Как насчет более простого? Ну, я боюсь, что это настолько просто, насколько это возможно. Я бы сказал, что PWA — это просто веб-приложение с ОТЛИЧНЫМ пользовательским интерфейсом, но это тоже не так описательно.
Чтобы понять это определение более подробно, давайте рассмотрим каждый из основных принципов. Возможно, вы уже знакомы с некоторыми из них, а другие могут застать вас врасплох или показаться неоднозначными.
Принципы прогрессивных веб-приложений:
· Отзывчивый
· Независимый от подключения
· Похожий на приложение
· Свежий
· Безопасный
· Доступный для обнаружения
· Повторно подключаемый
· Устанавливаемый
· Доступно по ссылке
Отзывчивый
Это может означать две вещи в зависимости от вашей интерпретации. Для веб-разработчиков это означает, что элементы, отображаемые в приложении, соответствующим образом масштабируются на разных размерах экрана. Для других разработчиков это может быть связано с производительностью, обычно указывающей на то, что приложение быстро реагирует на взаимодействие с пользователем, события, загрузку страниц и т. д. Создание производительного приложения важно, и прогрессивные веб-приложения делают это естественным образом. Однако это не то, к чему мы обращаемся, поэтому мы будем следовать первому определению. Адаптивные «веб-приложения» хорошо смотрятся на любом устройстве. Независимо от того, является ли экран широким, узким, коротким или высоким, макет приложения масштабируется и подстраивается под экран пользователя соответствующим образом.
Независимый от подключения
Поскольку мы говорим о веб-приложениях, на каком-то этапе жизненного цикла приложения необходимо сетевое подключение, особенно при первом посещении приложения. Но это не всегда возможно. Когда сеть недоступна или слишком медленная, приложение все равно должно работать на устройстве. Навигация по приложению не должна показывать пользователю пустые страницы или ошибки 400. Использование механизмов хранения браузера делает это возможным.
App-подобный
Я думаю, что «нативное приложение» — лучший способ описать этот принцип. Нативные приложения выглядят так, как будто они были созданы для устройства, на котором они используются. Некоторые приложения созданы специально для таких платформ, как iOS или Android, и их веб-аналоги не обеспечивают такой же возможности, особенно на мобильных устройствах. Прогрессивные веб-приложения нацелены на предоставление одинаковых возможностей на ВСЕХ устройствах. Пользователи могут переключаться со своего телефона на ноутбук и легко выполнять те же задачи.
Свежий
Мне нравится называть это A.F.A.P. — данные в вашем приложении должны быть максимально свежими. Если новые данные доступны и актуальны для клиента, то приложение необходимо обновить самыми свежими данными. Управление сетевыми запросами и хранилищем браузера необходимо для обеспечения удобного взаимодействия с пользователем и поддержания актуальности контента на клиенте.
Безопасно
Безопасность прежде всего! Что хорошего в приложении, если им небезопасно пользоваться? Большинство потребительских веб-приложений содержат конфиденциальную информацию, которая должна быть известна только взаимодействующим сторонам. Необходима защита данных, совместно используемых в приложении. Для простоты используйте протокол HTTPS, чтобы добавить уровень безопасности к сетевому трафику.
Обнаруживаемый
Возможность обнаружения в отношении прогрессивных веб-приложений важна. Приложение должно быть легко найдено в Интернете. Если поисковые системы не могут найти приложение, то как его найдут потенциальные пользователи? Применение методов поисковой оптимизации может помочь. Манифест приложения также играет важную роль в идентификации приложения для браузера. Он содержит информацию о приложении, включая имя, автора и описание. Манифест также помогает идентифицировать PWA на устройстве, на котором оно установлено. Да, PWA можно установить (это тоже другой принцип).
Повторно привлекаемый
Приложения с возможностью повторного вовлечения могут отвлекать пользователя, отправляя push-уведомления. Это способ сообщить пользователям, что произошло что-то интересное, требующее их внимания. Мы привыкли к этому понятию на наших смартфонах и в родных мобильных приложениях, но браузеры поддерживают это также через API-интерфейсы Push и Notification.
Устанавливаемый
Прогрессивные веб-приложения можно устанавливать прямо на главный экран мобильного устройства. В первую очередь это функция мобильного браузера, но с Chrome вы можете делать это и на своем настольном компьютере. Это также поддерживается в iOS Safari, поэтому, если у вас есть iPhone, вы можете присоединиться к увлечению PWA. Что действительно здорово в установке веб-приложений, так это то, что вам не нужно заходить на такие рынки, как App Store или Google Play Store, чтобы загрузить приложение. Просто зайдите на сайт, нажмите «Добавить на главный экран», и приложение сразу появится на главном экране.
Ссылка
Связываемое веб-приложение является общедоступным, поэтому приложения, размещенные на частных доменах, не применяются. Все, что вам нужно, это URL-адрес.
"Выучить больше"
Создание прогрессивного веб-приложения
Так как же все это воплощается на практике? По сравнению со стандартным веб-приложением для создания PWA требуется всего три дополнительных требования:
- Подавать веб-приложение через HTTPS
- Добавьте файл манифеста приложения
- Используйте сервисного работника
HTTPS является протоколом де-факто для современных веб-приложений, и прогрессивные веб-приложения не являются исключением.
Манифест приложения — это файл JSON, содержащий метаданные о приложении. Он предоставляет только основную информацию. В приложении для Android файл манифеста намного сложнее, и его может потребоваться изменить в ходе разработки приложения. Манифесты веб-приложений требуют меньше усилий, и их не нужно часто обновлять после создания, поскольку они не содержат параметров конфигурации или зависимостей.
Последним шагом в создании прогрессивного веб-приложения является добавление работника службы. Здесь происходит волшебство и включаются автономные возможности. Service Worker — это просто еще один файл JavaScript — очень мощный файл JavaScript. На самом деле он выполняется в отдельном потоке в браузере, поэтому выполнение в потоке сервисного работника не будет прерывать основной поток приложения. Это дает разработчику гибкость для создания лучшего пользовательского интерфейса за счет параллелизма. Service Worker может обрабатывать сетевые запросы/ответы и кэширование. Удаление этой работы из основного потока отделяет логику приложения от управления данными и операций, связанных с сетью.
Как видите, большая часть прогрессивной работы здесь связана с реализацией сервис-воркера. Но перед внедрением необходимо рассмотреть архитектуру приложения.
Структура приложения PWA
Оболочка приложения — это концепция, описывающая инфраструктуру приложения. Он состоит из всех статических файлов, необходимых вашему приложению для работы. В контексте веб-разработки это будет включать HTML, CSS, JavaScript и файлы изображений.
Контент — это данные, которые могут меняться на протяжении всего жизненного цикла приложения. Он исключен из оболочки приложения, поскольку является динамическим и потенциально может устареть при загрузке приложения. Обычно он предоставляется через службу API и легко запрашивается. Этим контентом необходимо управлять в приложении, чтобы обеспечить доступность самого свежего контента по запросу. Эту ответственность берет на себя сервисный работник.
При первой загрузке приложения файлы оболочки приложения должны кэшироваться, чтобы приложение могло работать без подключения к сети.
Хороший PWA никогда не будет отображать этот экран:
Когда страница не загружается, пользователь полностью отключается от приложения. Очевидно, что проблемы, связанные с сетью, влияют на взаимодействие с пользователем, но это не должно отталкивать пользователей от приложения. Идея состоит в том, чтобы походить на собственный интерфейс, и PWA может удерживать пользователей в приложении, даже если в приложении отображается пустой экран. Чтобы удерживать внимание пользователей, когда сеть работает медленно, вы можете использовать анимацию или обеспечить взаимодействие на стороне клиента, которое дает некоторую визуальную обратную связь. Это может быть простая кнопка обновления со счетчиком, небольшая головоломка или интерактивная 3D-модель. Будь креативным!
Одним из недостатков использования модели оболочки приложения является ее производительность. Это замедляет начальную загрузку; однако это можно улучшить. Чтобы сократить время, необходимое для загрузки файлов оболочки приложения, вы можете попробовать минимизировать код (чтобы уменьшить размер файлов), связать файлы (чтобы минимизировать количество сетевых запросов) или удалить код, который не используется. Вы можете отправить этот удаленный код клиенту, когда это необходимо. Это зависит от требований.
Описанная здесь архитектура очень распространена. Если вы разрабатывали приложения для других платформ, вы можете узнать похожую структуру дизайна. Например, мобильные приложения, которым требуется доступ к сети, используют аналогичный подход для взаимодействия со службами. Обычно есть несколько классов Factory, которые обрабатывают сетевые запросы и ответы. Класс Factory обеспечивает уровень абстракции и лучше всего работает, если создается асинхронно. Логика приложения не должна ждать запроса. Это может позволить пользователю двигаться дальше и уведомить его, когда запрос будет выполнен. Это также упрощает тестирование за счет разделения утилит доступа к данным и логики пользовательского интерфейса.
Использование модели App Shell — хорошее начало, но это не обязательное требование для прогрессивного веб-приложения. Если у вас есть существующее приложение, вы можете оценить, какие части вашего приложения используются чаще всего, и оптимизировать первоначальную загрузку. Если 95% вашей пользовательской базы используют только 25% вашего приложения, может иметь смысл загружать и кэшировать только 25% приложения (которое используется наиболее активно). Другие части могут быть загружены и кэшированы по мере необходимости. Все зависит от того, как пользователи взаимодействуют с вашим приложением.
Сервисный работник
Реализации сервис-воркеров будут различаться от одного приложения к другому, но есть несколько вещей, о которых вы должны знать, чтобы начать использовать их в своих приложениях. Ранее я упоминал, что сервис-воркер работает в другом потоке в браузере. Это означает, что у него есть жизненный цикл, которым нужно управлять, как и у вашего приложения.
Вот основные события жизненного цикла сервис-воркера:
1. Зарегистрироваться
Регистрация сервис-воркера произойдет при первой загрузке приложения в браузере. На самом деле это не событие Service Worker, так как Service Worker не существует в контексте браузера в данный момент времени. Но это важный шаг. Основной файл JavaScript приложения должен проверять, поддерживается ли API ServiceWorker в браузере, и если да, то регистрировать сервис-воркер. После успешной регистрации файл сервис-воркера загружается, после чего начинается установка.
if ('serviceWorker' in navigator) {navigator.serviceWorker.register('./service-worker.js');}
Этот код регистрирует сервис-воркера в браузере (если поддерживается). Все следующие события обрабатываются в файле сервис-воркера.
2. Установить
Событие Install — это первое событие, которое Service Worker может обработать самостоятельно. Он запускается сразу после регистрации/скачивания. По завершении установки рекомендуется начать кэширование статических ресурсов, поскольку событие установки происходит только один раз.
self.addEventListener('install', function(e) {
e.waitUntil( // waitUntil() from ExtendableEvent
caches.open(cacheName).then(function(cache) {
console.log('[ServiceWorker] Caching app shell');
return cache.addAll(filesToCache);
})
);
});Метод waitUntil() принимает обещание, которое будет выполнено после завершения события установки.
3. Активировать
Событие активации означает, что сервис-воркер установлен. После завершения активации сервисный работник получает контроль над основным приложением. Когда служба становится «активной», она также должна проверять кэшированные ресурсы и обновлять данные, если они устарели. Это может потребовать выполнения дополнительных сетевых запросов для проведения сравнений, но это не должно быть проблемой, поскольку выполнение запроса не повлияет на приложение. Service Worker также может выполнять операции с функциональными событиями, такими как Fetch, Push и Message, когда он находится в активном состоянии.
Примечание. После того как сервис-воркер зарегистрирован и установлен, он будет существовать в браузере до тех пор, пока пользователь не удалит его. Файл не удаляется автоматически, когда пользователь закрывает приложение, и браузер будет загружать файл сервис-воркера каждые 24 часа, чтобы избежать плохого/устаревшего кода.
4. Получить
Событие Fetch запускается всякий раз, когда вызывается сетевой запрос от основного приложения. Когда это происходит, сервис-воркер становится ответственным за запрос. Если запрошенная информация уже кэширована, сервисный работник может вернуть эту информацию и вообще обойти сеть. Или он все еще может отправить запрос, сравнить ответ с кэшированной информацией и при необходимости обновить. Выберите стратегию, которая лучше всего работает для пользователей.
События Push и Message также являются событиями, которые сервис-воркер отслеживает, когда они активны. Их можно использовать для реализации push-уведомлений и синхронизации отправляемых данных.
Как видите, сервис-воркер — это место, где выполняется большая часть работы, и это важная часть для создания прогрессивного веб-приложения. Он действует как сетевой прокси и служба управления хранилищем для вашего приложения и является отличным инструментом для улучшения взаимодействия с пользователем в веб-приложениях.
Создание прогрессивного веб-приложения
Попробуйте создать PWA. Начать работу легко, если у вас уже есть веб-приложение. Сейчас мы работаем над статьей, описывающей, как мы построили PWA с помощью Wijmo. Это пример того, как перевести существующее приложение на прогрессивные стандарты.
Если вам нравится идея прогрессивных веб-приложений, но вы все еще не уверены, подходят ли они для вашего бизнеса, ознакомьтесь с 7 причин, по которым вашей компании нужны прогрессивные веб-приложения.
от Троя Тейлора
