Локальные данные и offline-режим мобильных приложений¶
Требования применяются к локальному хранению; offline-нормы применяются только
к приложению, явно заявившему offline-сценарии. Уровни обязательности определены
в корневом README.md.
MOB-DATA-001. Классификация локальных данных¶
Уровень: MUST
Применяется к: каждому сохраняемому набору данных
Проект должен определить назначение, классификацию, срок хранения, backup- политику и условие удаления. Cache должен отличаться от источника данных и удаляться без нарушения корректности. Персональные данные не должны храниться дольше необходимого сценарию срока.
Обоснование¶
Необъявленное локальное состояние переживает logout, upgrade и потерю устройства.
Проверка¶
- inventory хранилищ;
- тест срока и очистки;
- review backup flags.
Исключения¶
Не допускаются для чувствительных данных.
MOB-DATA-002. Шифрование и удаление¶
Уровень: MUST
Применяется к: чувствительным локальным данным
Данные должны использовать платформенную защиту файлов и дополнительное шифрование с ключом Keychain/Keystore, если этого требует классификация. Logout, удаление аккаунта и отзыв доступа должны удалять credentials, защищённые данные и производные cache. Удаление ключа должно делать оставшийся ciphertext недоступным.
Обоснование¶
Sandbox без управления ключом недостаточен при backup или компрометации устройства.
Проверка¶
- extraction test заблокированного устройства и backup;
- тест logout и удаления аккаунта;
- проверка отсутствия ключа рядом с данными.
Исключения¶
Публичный cache может использовать только платформенную sandbox-защиту.
MOB-DATA-003. Версионирование локальной схемы¶
Уровень: MUST
Применяется к: базе и сериализованному состоянию между версиями приложения
Схема должна быть версионирована и мигрироваться транзакционно либо возобновляемо. Upgrade не должен молча терять пользовательские данные. Неуспешная migration должна иметь безопасное восстановление; destructive reset допустим только для явно воспроизводимого cache.
Обоснование¶
Store update устанавливается поверх состояния предыдущей версии.
Проверка¶
- migration tests со всех поддерживаемых версий;
- тест interruption и disk-full;
- проверка инвариантов после upgrade.
Исключения¶
Одноразовый cache может пересоздаваться при доказуемом источнике восстановления.
MOB-DATA-004. Контракт offline-сценария¶
Уровень: MUST
Применяется к: приложению, заявившему offline-работу
Для каждого offline-сценария должны быть определены доступные операции, максимальная давность данных, очередь изменений, пользовательское обозначение состояния и условия синхронизации. Приложение не должно сообщать серверный успех до подтверждения backend.
Обоснование¶
Offline UI без семантики результата создаёт ложное подтверждение.
Проверка¶
- сценарий запуска и работы без сети;
- тест pending, synced и failed состояний;
- проверка отображения давности.
Исключения¶
К приложению без заявленного offline-сценария требование не применяется; это не является исключением.
MOB-DATA-005. Конфликты и повторная синхронизация¶
Уровень: MUST
Применяется к: синхронизации локальных изменений
Отправка должна быть идемпотентной и возобновляемой после restart. Стратегия конфликта должна быть определена на тип данных и не должна молча применять last-write-wins без принятого решения. Неустранимый конфликт должен сохранять обе необходимые версии и требовать определённого разрешения.
Обоснование¶
Конкурентные изменения являются штатным состоянием offline-системы.
Проверка¶
- duplicate, reorder и concurrent update tests;
- restart посередине sync;
- тест конфликта и пользовательского разрешения.
Исключения¶
Last-write-wins допустим для данных, где потеря промежуточного значения явно разрешена контрактом.
MOB-DATA-006. Изоляция данных между аккаунтами¶
Уровень: MUST
Применяется к: приложению, допускающему вход или переключение между несколькими аккаунтами на одном устройстве
Credentials, защищённые данные, cache, media, черновики и offline-очереди должны быть разделены стабильным account identifier либо отдельными ключами и хранилищами. До активации другого аккаунта приложение должно остановить синхронизацию предыдущего и не должно показывать или отправлять его данные в контексте нового аккаунта.
Общий публичный cache MAY переиспользоваться только при отсутствии account- bound полей и разрешённой классификации. Пустой или неизвестный account identifier не должен отображаться как общий namespace.
Обоснование¶
Переключение без полного logout оставляет процесс живым и может связать queue или cache предыдущего пользователя с новой identity.
Проверка¶
- offline-тест переключения с cache, draft, media и pending mutation;
- конкурентный ответ старой сессии после активации новой;
- extraction test namespaces и ключей двух аккаунтов.
Исключения¶
Приложение без поддержки нескольких сохранённых аккаунтов должно выполнять полную очистку предыдущего контекста до нового login.
MOB-DATA-007. Восстановление на новом устройстве¶
Уровень: MUST
Применяется к: данным приложения, включённым в platform backup или device-to-device migration
Проект должен определить, какие данные переносятся, какие пересоздаются и какие запрещены в backup. После restore приложение должно обнаруживать ciphertext без доступного ключа, несовместимую schema и отсутствие device-bound credentials, не интерпретируя их как пустое успешное состояние.
Credentials, biometric enrollment и privacy permissions должны запрашиваться заново, если платформа не предоставляет проверяемую переносимую гарантию. Destructive reset допускается только для воспроизводимого cache; для невосстановимого пользовательского состояния должен существовать явный результат и путь восстановления либо экспорт до миграции.
Обоснование¶
Backup данных без device-bound ключа создаёт формально восстановленные, но нечитаемые данные и риск молчаливой потери.
Проверка¶
- platform restore и device-to-device test на новом device identity;
- тест отсутствующего ключа, старой schema и повторного запроса permissions;
- проверка сохранения либо явного результата для offline drafts.
Исключения¶
Приложение MAY запрещать перенос всех локальных данных, если это явно отражено в backup flags и пользовательском контракте.