Пример задачи для сохранения состояния или использования жизненного цикла в диалоге

Что проверяют

Различаете ли три разные ситуации: смену конфигурации, смерть процесса в фоне и обычное закрытие диалога. От этого зависит, куда класть состояние, и большинство ошибок в приложениях именно здесь.

Как отвечать

Разложите по уровням хранения:

• поворот экрана и другие смены конфигурации переживает ViewModel, привязанная к фрагменту диалога;
• смерть процесса в фоне ViewModel не переживает: мелкие значения (введённый текст, выбранный пункт, идентификатор) сохраняются в SavedStateHandle или в onSaveInstanceState;
• то, что должно жить после выхода из приложения, например черновик заметки, уходит в базу или DataStore.

Конкретно про диалог. DialogFragment пересоздаётся системой через конструктор без параметров, поэтому входные данные передаются через arguments, а не через поля или свой конструктор: поля после пересоздания будут пустыми. Введённый текст система восстановит сама, только если у поля ввода есть идентификатор в разметке. У программно созданного EditText его нет, и текст сохраняют вручную, а читают в onCreateDialog или onViewCreated, когда представление уже существует.

В Compose то же самое другими словами: rememberSaveable вместо remember, а факт показа диалога держат в состоянии экрана, а не в императивном вызове, иначе диалог исчезнет при повороте.

Где спотыкаются

Передают данные в диалог полями или конструктором с параметрами. До первого поворота работает, после пересоздания приходит пустая форма или падение.

Считают, что ViewModel переживает всё. Проверять надо не поворотом, а опцией «не сохранять действия» в настройках разработчика или принудительным завершением процесса: там видно, что без SavedStateHandle состояние теряется.

Кладут в Bundle тяжёлое: список объектов, картинку, ответ сервера. Лимит транзакции небольшой, и приложение падает с TransactionTooLargeException. В Bundle только идентификаторы и мелочь, остальное перечитывается из репозитория.