(Фото Джона Флобранта на Unsplash)
Это суровая правда, с которой в какой-то момент сталкивается каждый разработчик программного обеспечения: постоянный доступ в Интернет никогда не гарантирован. В настоящее время Wi-Fi доступен повсюду, но обслуживание может быть нестабильным или перегруженным запросами на подключение (например, на крупных мероприятиях или конференциях). И вы не можете запретить своим пользователям доступ к вашему приложению, пока их соединение плохое или отсутствует. Итак, чем вы занимаетесь как разработчик? Примите это. Избавьтесь от опасений по поводу создания офлайн-возможностей, изучив основы Offline First.
Offline First — это принцип разработки программного обеспечения, который предполагает, что приложения могут и будут использоваться без подключения к сети в какой-то момент. Это особенно важно, если вы разрабатываете для мобильной аудитории, которая может отключаться несколько раз в день. Создание приложений Offline First увеличивает полезность вашего приложения и приводит к большему удовлетворению запросов пользователей.
Первое впечатление оффлайн
Вот некоторые из вещей, которые вы можете сделать, чтобы принять образ мышления в первую очередь автономно.
Кэшировать раньше, кешировать часто
Как гласит старая пословица, «ранняя пташка прячет червя». 😉
Если не считать плохих шуток, кешируйте ваш контент на раннем этапе и часто, пока соединение стабильно, чтобы избавиться от головной боли, когда сетевые соединения более нестабильны.
Кэширование содержимого повышает производительность приложения, поскольку теперь локальная информация извлекается быстрее. Приложения можно открывать и закрывать, сохраняя при этом свое состояние. Ознакомьтесь с некоторыми конкретными стратегиями кэширования в разделе Service Workers ниже.
Определите, что не подлежит обсуждению
С другой стороны, некоторые функции не подлежат обсуждению: вам просто нужно быть подключенным к Интернету, чтобы использовать их, например, службы определения местоположения.
Ничего страшного! Определите, какие функции требуют подключения к Интернету, а затем создайте сообщения или предупреждения, информирующие пользователей о потребностях этих функций. Пользователи оценят это, потому что вы избавитесь от догадок, чтобы понять ограничения вашего приложения в автономном режиме.
Будьте готовы к конфликту
Противоречивая информация может стать большой проблемой. Может быть недостаточно просто объединить и отменить все изменения, кроме последнего раза, когда пользователь был в сети. Пользователи должны четко понимать, что происходит, когда конфликт неизбежен. Когда они узнают свои варианты, они могут выбрать то, что им подходит.
Есть несколько решений для обработки противоречивой информации. Вам решать, хотите ли вы, чтобы пользователь сам выбирал, какую версию оставить, или установить правило «выигрывает последняя запись». Что бы вы ни выбрали, приложение должно с этим справиться.
Знайте, когда применять обновления
Выполняйте обновления слишком часто, и вы можете упустить преимущества первого автономного режима. При обновлении слишком медленно вы можете создать больше конфликтов, чем необходимо, и расстроить пользователей.
Знание что обновлять вместе с когда обновлять, также является важным соображением. Загрузка только самых важных данных на серверы позволяет сэкономить на хранилище и время, необходимое для загрузки.
Ожидайте неожиданного
Пользователи непредсказуемы. Хотя вам следует проверять самые разные ситуации, вы не можете учесть все. Отслеживайте, что на самом деле делают пользователи, продолжая тестирование и опросы, когда пользователи не в сети.
Одним из личных примеров является моя жена, которая взяла электронные книги из библиотеки, чтобы читать на своем Kindle. Поскольку одолженные книги «истекают» по истечении установленного срока проката, она держит свой Kindle в автономном режиме как можно дольше, чтобы гарантировать, что, если ей понадобится больше времени, чтобы закончить книгу, она могла сделать это, не теряя к ней доступа.
Я не знаю, ожидали ли разработчики приложения Kindle от людей, которые будут так цепляться за книги, но это один из примеров того, как люди остаются в автономном режиме столько, сколько требуется для их вариантов использования. Идея о том, что каждый хочет постоянно быть в сети, должна быть проверена на основе ваших собственных предположений.
Это те концепции, о которых вам нужно знать. Чтобы воплотить эти концепции в жизнь, вам понадобятся подходящие инструменты. К счастью, существует ряд существующих инструментов, облегчающих разработчикам программирование с ориентацией на автономный режим.
Инструменты
API сетевой информации
API сетевой информации — важный инструмент для разработчиков, которые хотят обеспечить бесперебойную работу пользователей. Разработчики могут использовать этот API для создания путей, которые открывают приложение в онлайн или автономном режиме с момента открытия приложения пользователем. Это сокращает количество ошибок, которые пользователь видит, когда приложение пытается найти соединение, но не открывается вообще.
API сетевой информации даже различает сети Wi-Fi и сотовые сети, позволяя точно контролировать то, как обслуживается контент. API также обнаруживает изменения, которые позволяют приложениям продолжать работать, когда пользователь переходит от одного сетевого подключения к другому (например, вход и выход из туннелей метро).
Например, когда пользователь использует более медленное соединение, он получает предупреждение о возможном снижении производительности:
if (navigator.connection.effectiveType! = '4g') {
console.log («медленное соединение!»);
// показываем модальное диалоговое окно, предупреждающее пользователя о том, что видео будет загружено с более низким разрешением
}
else {
console.log («Готово!»);
// немедленная загрузка видеофайла
}
Другой вариант — Capacitor’s Network API. Он расширяет API сетевой информации, предоставляя еще больше полезных функций для веб-приложений и мобильных приложений, таких как мониторинг сети на предмет изменений статуса, на которые ваше приложение может затем реагировать.
импортировать {плагины} из '@ конденсатор / сердечник';
const {Сеть} = Плагины;
let handler = Network.addListener ('networkStatusChange', (status) => {
console.log («Статус сети изменен», статус);
});
// Получить текущий статус сети
let status = await Network.getStatus ();
// Пример вывода:
{
"connected": правда,
"connectionType": "Wi-Fi"
}
Мониторинг сети с помощью этих двух API-интерфейсов — важный первый шаг к тому, чтобы сделать вашу работу в автономном режиме максимально гладкой.
Работники сферы обслуживания
Сервис-воркеры позволяют вам управлять сетевыми запросами, кэшировать эти запросы, а затем разрешать пользователям доступ к кэшированному контенту в автономном режиме.
С помощью Cache API просто добавлять ресурсы с помощью встроенного метода add . Например:
const resource = caches.add ('/ styles.css');
или вы можете использовать addAll для добавления нескольких файлов, который использует обещание для обеспечения кэширования всех ресурсов и отклоняет запрос, если один из них не загружен. Например:
const resources = caches.addAll ('/ styles.css', '/fonts.woff', 'otherdata /');
После установки приложения может срабатывать прослушиватель событий, который создает кэш и загружает его содержимое, готовое к использованию после завершения установки:
self.addEventListener ('install', function (event) {
event.waitUntil (caches.open ('статические файлы')
.then (функция (кеш) {
вернуть caches.addAll ([
'/css/styles.css',
'/static/images/',
'/fonts/fonts.woff'
]);
})
);
}
);
Оттуда вы можете создавать дополнительные функции, которые проверяют наличие обновлений кэшированного содержимого, удаляют устаревшие файлы или добавляют дополнительные файлы по мере необходимости.
Автономное хранилище
Еще одно важное соображение — это локальное сохранение данных. Есть несколько решений: localStorage, IndexedDB и Ionic Offline Storage.
localStorage
localStorage содержит встроенные методы для создания и хранения пар ключ -> значение. Они сохраняются в автономном режиме и при закрытии браузера. Вы можете объявить и получить данные, используя setItem и getItem . Следующий код устанавливает значение «name» и возвращает его при вызове.
var offlineStore = window.localStorage;
offlineStore.setItem ('имя', 'Джон');
var name = localStorage.getItem ('имя');
Используйте метод clear для удаления данных.
localStorage.clear ('имя');
IndexedDB
localStorage отлично подходит для хранения строк, но что, если вы хотите хранить более сложные данные, такие как изображения или капли? Вот где на помощь приходит IndexedDB. IndexedDB позволяет вам создать новое подключение к локальной базе данных и сопоставить объекты с предоставленной вами схемой. Для этого требуется больше кода, чем для localStorage, но вы можете воспользоваться дополнительными функциями.
При создании IndexedDB вы создаете «хранилище» для своих данных, и IndexedDB позволяет вам перейти оттуда. Вот пример создания IndexedDB книг и их авторов:
// при необходимости создает новую версию базы данных
const dbName = "books_db";
let request = window.indexedDB.open (dbName, 1), db, tx, store, index;
request.onupgradeneeded = function () {
пусть db = request.result,
store = db.createObjectStore ("booksStore", {keyPath: "isbn"}),
index = store.createIndex ("название", "название");
}
request.onsuccess = function () {
// база данных, куда идут данные
db = request.result;
// определяет разрешенные транзакции
tx = db.transaction ("книжный магазин", "чтение и запись");
// хранилище, которое вы создаете для данных, которое использует ключ isbn.
store = tx.objectStore ("книжный магазин");
// индекс, который можно использовать для поиска данных
index = store.index ("название");
// вставляем данные
store.put ({isbn: 1234, название: «Моби Дик», автор: «Герман Мелвилл»});
store.put ({isbn: 4321, название: «Эмма», автор: «Джейн Остин»});
// получаем данные
пусть book1 = store.get (1234);
book1.onsuccess = function () {
console.log (book1.result);
}
// закрываем соединение с базой данных после завершения транзакции
tx.oncomplete = function () {
db.close ();
};
};
Вы можете узнать больше, прочитав документацию IndexedDB. Существуют и другие решения, такие как localForage, который представляет собой API-оболочку для IndexedDB, цель которого — облегчить работу с ним.
Автономное хранилище Ionic
Для более сложных и надежных систем хранения данных попробуйте решение Ionic для автономного хранения данных. Это кроссплатформенная система хранения данных, которая работает на iOS и Android и работает на базе SQLite (ядро базы данных SQL). Поскольку он обеспечивает оптимизированный по производительности механизм запросов и шифрование данных на устройстве (256-битный AES), он отлично подходит для приложений, управляемых данными.
Поскольку он основан на промышленном стандарте SQL, разработчикам легко добавлять в свои проекты. Например, создание новой таблицы и вставка исходных данных:
this.database.transaction ((tx) => {
tx.executeSql ('СОЗДАТЬ ТАБЛИЦУ, ЕСЛИ ПО НЕ СУЩЕСТВУЕТ (имя, компания)');
tx.executeSql ('ВСТАВИТЬ В ЗНАЧЕНИЯ ПО (?,?)', ['offline', "ionic"]);
tx.executeSql ('ВСТАВИТЬ В ЗНАЧЕНИЯ ПО (?,?)', ['auth-connect', "ionic"]);
});
Запрос данных включает в себя запись операторов SELECT с последующим просмотром результатов данных:
this.database.transaction ((tx) => {
tx.executeSql ("ВЫБРАТЬ * из программного обеспечения", [](tx, результат) => {
// Строки - это массив результатов. Используйте индексирование с нуля для доступа
// каждый элемент в наборе результатов: item (0), item (1) и т. д.
for (let i = 0; i <result.rows.length; i ++) {
// {имя: "offline-storage", компания: "ionic", тип: "native", версия: "2.0"}
console.log (result.rows.item (i));
// ионный
console.log (result.rows.item (i) .company);
}
});
});
Узнайте больше о создании быстрых приложений на основе данных здесь.
Сообщения о доступности
Важно общаться с пользователями, когда их опыт работы в автономном режиме меняется. Ваше приложение должно проактивно сообщать пользователям, когда они в сети или офлайн. Используйте прослушиватели сетевых событий для обнаружения изменений в подключении пользователя и отправки сообщений, извещающих пользователя о том, что не все функции могут быть доступны.
Ionic Framework Toast Component — это инструмент, который поможет вам быстро и легко настроить сообщения о доступности. Как только ваше приложение обнаружит, что оно отключено, используйте тост, чтобы уведомить пользователя:
// Отображать всплывающее сообщение, если сетевое соединение отключается
async function showOfflineToast () {
const toast = document.createElement ('ion-toast');
// Отображаем сообщение о том, что пользователь сейчас не в сети.
toast.message = 'Последние сообщения чата появятся, когда вы снова в сети.';
// Отображаем тост-сообщение в течение 2 секунд
toast.duration = 2000;
}
Начало создания автономных приложений
Пользователи будут отключены в какой-то момент из-за прерывистого сетевого подключения или их местоположения (например, удаленные районы или толстостенные здания). Они могут просто беспокоиться об ограничении использования полосы пропускания для экономии затрат, предпочитая автономные режимы необходимости постоянного подключения. Независимо от причины, мы должны учитывать эти сценарии.
Если вам сложно начать работу с Offline First, не волнуйтесь. Используйте следующий контрольный список, чтобы убедиться, что вы на правильном пути при разработке автономного режима. Ваши пользователи будут вам благодарны!
- Вы проектируете для работы в автономном режиме?
- Вы проверяете сетевые подключения с помощью сетевого API? Какие типы соединений вы обнаруживаете?
- Вы настроили сервис-воркера для обслуживания офлайн-контента?
- Какие функции не могут работать без подключения к Интернету? Как вы сообщите пользователям, что возможно, а что нельзя в автономном режиме?
- Какие у вас решения для хранения автономного контента? Будете ли вы полагаться на localStorage или более надежную систему, такую как IndexedDB?
Какие советы и рекомендации вы используете при создании автономных приложений? Дайте нам знать ниже.
