"постоянное состояние" и "текущее состояние"

Ответ 1

Вам не нужно сохранять пользовательские настройки в onPause, потому что, как вы говорите, инфраструктура делает это для вас.

Чтобы отличить постоянную информацию от информации о состоянии, подумайте о приложении текстового редактора.

Постоянные данные

Скажем, пользователь набрал пару слов, а затем вышел из приложения. Пользователь явно не сообщил нам сохранить эти данные в файл, но было бы неплохо сохранить эти данные, когда они вернутся. Это постоянные данные, и вы хотите сохранить их в onPause().

Данные состояния

Аналогично, скажем, у вас есть 2 вкладки и переменная, которая отслеживает выбранную вкладку. Это данные состояния, которые вы должны хранить в onSaveInstanceState().

Серое вещество

Наконец, представьте, что у вас есть класс в редакторе, который отслеживает количество символов и количество строк в редакторе. Это данные состояния, вы можете сохранить его в onSaveInstanceState(), или вы можете выбросить его и просто пересчитать его при повторном запуске. Если вы выбросите его, это может зависеть от того, сколько времени потребуется для вычисления, например, если вы можете предотвратить сетевой запрос путем хранения данных, сделайте это.

Дальнейшие мысли

Играя с вашим приложением, это должно быть очевидно, если есть область, где вы не смогли вырвать нужные данные. Не забудьте сделать что-то вроде нажатия кнопки "домой", а затем закрыть приложение из диспетчера устройств. Это позволит вам попасть в угловые случаи, когда приложение закрывается, а не просто приостанавливается.

Если ваше состояние пользовательского интерфейса согласовано во всех жизненных циклах, и ваши пользовательские данные остаются, хорошая работа.

Изменить на основе комментария

Я думаю, что здесь есть два критерия, чтобы определить, когда/что сохранить.

Первое довольно субъективно - вы хотите вообще сохранить данные? Там действительно ничего не заставило вас сохранить состояние или данные. Будет ли сохранение этой информации лучше для пользователей? Если вы пишете электронное письмо и пытаетесь скопировать/вставить текст из другого приложения, потеря вашего полупризнанного письма каждый раз, когда приложение будет закрыто, будет неприятно.

Вторая часть, определяющая, что нужно сохранить, зависит от того, можете ли вы восстановить свое состояние пользовательского интерфейса на основе данных, которые у вас есть. Например, если вы сохранили текстовые данные, это должно означать, что пользователь редактировал текст. Итак, теперь мы знаем, что нужно переключиться на вкладку редактирования текста и заполнить сохраненный текст.

Вообще говоря, если желание состоит в том, что вы хотите вернуть пользователя в одно и то же место, которое они остановили, вам нужно подумать о данных состояния, необходимых для возвращения к этой точке. Представьте себе загруженную версию вашего приложения

• какие данные необходимо изменить, чтобы превратить это в последнее состояние пользователя пила?
• какие данные вам нужно хранить, чтобы вернуться сюда?

На самом деле, как работает андроид, ваша деятельность разрушена и воссоздана, и ваша задача снова настроить фигуры в движении (если вы решите это сделать).

Ответ 2

Вот ответ. Вы можете сохранить состояние тремя способами.

1) Подклассическое приложение (не очень хорошая идея). 2) SharedPreferences (полезно для простых данных, быстрая и надежная) 3) База данных SQLite (более сложная, также надежная).

Теперь, чтобы ответить на ваш вопрос. У Android нет действительно никаких гарантий. В любое время он может и может уничтожить ваше приложение, не вызывая каких-либо конкретных функций, прежде чем он это сделает. Поэтому, если есть данные, которые необходимы для сохранения, ответ сохраняет его, как только вы его получите. Как правило, не так много преимуществ для сохранения чего-то позже, если вы знаете, что вам что-то нужно будет немедленно сохранить.

onSaveInstanceState() предназначен только для сохранения временных переменных, связанных с изменениями макета или ориентации.

В заключение постоянное состояние/данные (которое должно выдержать сбой) следует сохранить ASAP, не ждите onPause(), потому что нет гарантий, Это реальность.

Ответ 3

Случай, который у меня есть, - это игра, в которой я хочу сохранить постоянные данные на игровом сервере.

Как это может занять некоторое время, мне нехорошо попробовать и сохранить в onPause, а скорее в onStop.

В соответствии с тестами, которые я выполнил, onStop, похоже, может работать в фоновом режиме, а onPause блокирует, по крайней мере, это тот случай, когда я нажимаю на него (проверяется с помощью простого для 1 до 10m loop в onPause и onStop). Может ли кто-нибудь подтвердить эту теорию блокирования?

onStop NEEDS Honeycomb up (api11+), потому что перед этой версией вы можете быть убиты до вызова onClose.

Смотрите здесь и найдите killable в таблице. Если реальность соответствует документации, это еще один вопрос:).