Приложение после длительного пребывания в фоне показывает устаревшие данные. Как проверить, что причина связана с отсутствием валидации кэша при возврате?
Нужно изменить данные на сервере, перевести приложение в фон дольше заданного срока, затем вернуть его на экран и проверить сетевой обмен и отображаемый результат. Доказательством проблемы с валидацией кэша будет использование старого ответа без условного запроса или другого решения о свежести данных.
Проверка должна учитывать, что iOS и Android могут приостановить приложение, разорвать сетевое соединение или завершить процесс. Поэтому при возврате приложение не должно безусловно считать ранее загруженные данные актуальными.
Мобильные приложения изначально работали в условиях нестабильной связи, ограниченного трафика и частого переключения между активным и фоновым состояниями. Кэширование уменьшало задержку и расход сети, но создавало риск показа устаревшей информации.
HTTP-механизмы вроде срока свежести и условной валидации появились как компромисс: клиент может использовать локальный ответ, пока он считается свежим, а затем проверить его актуальность дешевле, чем повторно загрузить всё содержимое.
Пользователь мог изменить заказ, баланс или статус операции с другого устройства, пока приложение находилось в фоне. Если при возврате экран просто использует память или локальный кэш, он покажет старое состояние, хотя сервер уже содержит новые данные.
Дополнительный риск связан с сетевым соединением: после приостановки процесса ранее открытый канал может быть недействителен. Ошибка обнаруживается не всегда сразу, поэтому простая проверка факта наличия данных в памяти недостаточна.
Сценарий проверки строится так:
Нужно установить, какое решение принимает клиент. Корректное поведение может быть реализовано через ограниченный срок свежести, условный запрос с валидатором вроде ETag или Last-Modified, либо через явную политику обновления при возврате на экран. При неизменившемся ресурсе сервер может подтвердить актуальность без передачи полного тела, а при изменении должен вернуть новые данные.
Важно проверять не только UI, но и запрос. Если клиент отправляет условный запрос и корректно обрабатывает ответ без изменений, это подтверждает валидацию. Если он всегда показывает локальную копию, тест должен зафиксировать нарушение политики свежести.
При отсутствии сети допустим контролируемый показ кэша с понятным признаком офлайн-состояния, если это предусмотрено требованиями. Нельзя безусловно считать кэш актуальным только потому, что запрос не удалось выполнить.
Не следует полагаться на одинаковые гарантии фоновой работы iOS и Android. Тест должен проверять наблюдаемое поведение после возврата, включая холодный запуск после завершения процесса, а правила TTL и момент обязательной перепроверки должны быть определены продуктом.
В приложении банка баланс обновлялся при первом открытии экрана, но после нескольких часов в фоне отображалась старая сумма. Рассматривались три варианта: всегда загружать полный баланс, полностью запрещать показ кэша и использовать условную валидацию с коротким TTL.
Полная загрузка давала наиболее простой контроль, но увеличивала задержку и расход трафика. Полный отказ от кэша ухудшал работу при слабой связи. Выбрали TTL с условным запросом при возврате из фона и отображением времени последнего успешного обновления.
Тест с изменением баланса на сервере показал, что после возврата клиент отправляет проверку актуальности и получает новые данные. В авиарежиме приложение показывает последнюю копию с офлайн-индикатором, а после восстановления связи обновляет её. Это устранило stale data, не создавая лишних полных загрузок.
1. Достаточно ли проверить только время, проведённое приложением в фоне?
Нет. Важен не только длительный интервал, но и изменение данных на сервере, завершение процесса, смена сети и наличие или отсутствие ответа. Короткий уход в фон тоже может привести к устаревшему состоянию, если ресурс изменился или сервер отменил прежнюю сессию.
2. Можно ли считать успешное отображение экрана доказательством корректного обновления?
Нет. Экран может отрисовать старые данные из памяти без единого сетевого запроса. Нужно проверять сетевой журнал, заголовки кэширования, обработку ответа сервера и соответствие отображаемой версии актуальному состоянию на сервере.
3. Что должно произойти, если приложение вернулось из фона без сети?
Поведение определяется требованиями, но оно должно быть явным: показать разрешённые кэшированные данные с указанием их давности либо показать ошибку обновления. После восстановления связи приложение должно повторить валидацию безопасным способом, не создавая конфликтов и не выдавая старую копию за актуальную.