На iPad одно iOS-приложение открыто в двух окнах. Как проверить, что состояние одного окна не ошибочно используется другим?
Нужно создать два независимых окна приложения, выполнить в них разные действия и проверить, что каждое окно сохраняет собственное состояние, навигацию и несохранённые данные. После сворачивания, повторного открытия и пересоздания одного окна состояние второго не должно изменяться.
Ключевой ожидаемый вывод: данные, относящиеся к конкретному окну, должны быть привязаны к отдельной сцене, а не к единому глобальному состоянию процесса приложения.
Мобильные приложения изначально часто предполагали один активный экран и один экземпляр пользовательского интерфейса на процесс. Для iPadOS появилась модель нескольких окон одного приложения, поэтому жизненный цикл интерфейса стал отличаться от жизненного цикла самого процесса.
В современной архитектуре iOS отдельное окно обычно представляется объектом сцены. Процесс приложения может быть общим, но сцены имеют собственные окна, навигационные стеки и контекст отображаемых данных.
Ошибка возникает, когда разработчики хранят состояние текущего документа, выбранного аккаунта или навигации в глобальном объекте, общем для всех сцен. Открытие документа во втором окне тогда может изменить содержимое первого, а закрытие или восстановление одной сцены — затереть состояние другой.
Такой дефект особенно легко пропустить при тестировании только одного окна. Последствия включают отображение чужих данных, потерю несохранённых изменений, неверный возврат на экран и нарушение изоляции пользовательских действий.
Сначала нужно убедиться, что приложение действительно поддерживает несколько окон на iPadOS. Затем открыть два окна одного приложения и загрузить в них разные сущности, например два разных документа или проекта.
В первом окне следует изменить фильтр, позицию навигации и данные формы, а во втором — выполнить другие действия. После каждого шага проверяется, что изменения остаются только в соответствующем окне. Особенно важны переходы между окнами через системный переключатель, блокировка и разблокировка устройства, сворачивание приложения и закрытие одной из сцен.
Для проверки восстановления нужно выгрузить из памяти интерфейс одной сцены или воспроизвести её повторное подключение, если это поддерживается сценарием приложения. После возврата должны восстановиться данные именно этой сцены, а не последнего активного окна.
Тестировщик должен различать состояние сцены и общее состояние приложения. К сцене обычно относятся выбранный документ, стек навигации, введённые, но ещё не сохранённые данные и параметры конкретного окна. К общему состоянию могут относиться авторизация, настройки пользователя или общий кэш, однако даже общий кэш не должен приводить к подмене данных, отображаемых в другой сцене.
Полезно проверять не только визуальную независимость окон, но и побочные эффекты: не меняется ли заголовок второго окна, не отправляется ли действие из одной сцены в контексте другой, не появляется ли уведомление о несохранённых данных у окна, где изменений не было. Компромисс состоит в том, что синхронизация действительно общих данных допустима, но она должна быть явной и не смешивать идентичность сцены с общим состоянием приложения.
В приложении для работы с документами тестировщик открыл документ А в первом окне и документ Б во втором. После редактирования документа Б первое окно неожиданно стало показывать документ Б, хотя его навигация визуально сохранилась.
Рассматривались два варианта. Можно было запретить открытие второго окна, что быстро устраняло дефект, но лишало пользователей полезного сценария многозадачности. Можно было оставить многоконность и разделить состояние по сценам, сохранив общий только кэш документов; это требовало доработки и дополнительных тестов, но соответствовало назначению платформы.
Выбрали второй вариант. Идентификатор текущего документа, навигационный стек и черновик стали храниться в контексте конкретной сцены, а общий кэш использовался только для повторного получения данных. После этого редактирование документа Б не влияло на документ А, а при восстановлении каждого окна возвращался его собственный контекст.
Да, это не обязательно ошибка. Ошибка возникает не из-за одинаковых данных, а из-за неявного и неконтролируемого обмена состоянием. Если продукт предусматривает совместное отображение одного документа, изменения должны синхронизироваться предсказуемо, а конфликт редактирования — иметь определённую политику.
Нет. Дефект может проявляться только при отсоединении и повторном подключении сцены или после восстановления интерфейса системой. Поэтому нужно отдельно проверять фоновые переходы, закрытие одного окна, повторный запуск конкретной сцены и сценарий нехватки памяти, если он доступен в тестовой среде.
Не обязательно. Такие данные часто являются общими для приложения и могут использоваться всеми сценами. Однако изменение общего состояния не должно случайно подменять сценоспецифические данные: выход из аккаунта может завершить сессии всех окон, но выбранный документ и локальный черновик каждого окна должны обрабатываться по явно определённым правилам.