Мы хотели бы, чтобы наше веб-приложение было доступно в автономном режиме, в основном на мобильных устройствах. Мы написали для этого код с помощью сервис-воркера. Данные приложения хранятся в IndexedDb, а код приложения (html, js, css, и c) хранится в кэше SW. Все идет нормально. Мы знаем, что пользователь может удалить кеш браузера и наши данные, это не проблема. Но как насчет того, чтобы сам браузер стирал данные приложения? Мы не нашли исчерпывающей спецификации для этого, основная информация, которую мы нашли:
1) StorageManager функция, которая в настоящее время помечена как «экспериментальная» (с 2016 г.);
2) короткая статья из Google здесь об этом (также с 2016 года).
Пример кода следующий:
if (navigator.storage && navigator.storage.persist)
navigator.storage.persist().then(granted => {
if (granted)
alert("Storage will not be cleared except by explicit user action");
else
alert("Storage may be cleared by the UA under storage pressure.");
});
The Google В статье говорится:
Когда объем хранилища на локальном компьютере ограничен («нехватка хранилища»), пользовательские агенты автоматически очищают хранилище, чтобы освободить больше свободного места. Конечно, для автономных приложений это может быть неудачно, поскольку они, возможно, еще не синхронизировали свои данные с сервером, или это могут быть приложения, которые пользователь ожидает просто работать в автономном режиме (например, музыкальный проигрыватель); таким образом, Storage spe c определяет два разных режима хранения для данного домена - «лучший из возможных» и «постоянный». Режим по умолчанию, конечно же, «лучший из возможных». Хранилище для домена, который является «максимальным» (также известным как «непостоянный»), может быть очищено автоматически, без прерывания или запроса пользователя. Однако «постоянные» данные не удаляются автоматически. (Если после очистки всех непостоянных данных система все еще находится под давлением, пользователю необходимо вручную очистить все оставшееся постоянное хранилище.)
...
Начиная с Chrome 55, Chrome автоматически предоставит разрешение на сохранение, если выполняется одно из следующих условий:
- Сайт добавлен в закладки (и у пользователя 5 или меньше закладок)
- Сайт имеет высокий уровень взаимодействия с сайтом
- Сайт добавлен на главный экран
- На сайте установлено pu sh уведомления включены
Разрешение автоматически отклоняется во всех остальных случаи.
Цель состоит в том, чтобы пользователи могли полагаться на свои любимые веб-приложения и не обнаружили, что они были внезапно удалены.
Это для Chrome 55, предположим, что информация до настоящего времени. На первый взгляд их цель кажется разумной, но если вы присмотритесь, то реализация ориентирована на «большие» сайты (а-ля Google), а не на нишевые приложения, которые более ориентированы на задачи.
Действительно, при тестировании на различных телефонах Android на Chrome 80+ постоянство всегда отклоняется без взаимодействия с пользователем. Итак, это "максимум усилий".
Мы могли бы остановить расследование здесь и положить конец этому. В конце концов, нынешние телефоны и P C имеют нечестивый объем памяти, а мы используем всего несколько сотен КБ, так что с нами все будет в порядке. Проблема в том, что это не так: тестирование на новом флагманском телефоне Android с Chrome, наш код стирается всего за несколько секунд возни (достаточно закрыть и открыть страницу несколько раз). На других платформах все по-другому, но Android + Chrome будет наиболее востребованным.
Как ни странно, стирается только код в кэше SW (<100 КБ), а более крупный IndexedDb - нет. Итак, мы попытались также поместить код в IndexedDb, и в этом случае он кажется более «постоянным», но код для управления им также более сложен, поэтому он кажется несколько хакерским sh. </p>
Мы наедине с этой проблемой? Если нет, то как вы, люди, справляетесь с этим?
Дополнительный вопрос: есть ли где-нибудь более свежая документация по этому вопросу?