Android – обратный вызов запроса API после onDestroy

Надеюсь, я смогу объяснить это хорошо...

Я пытаюсь лучше понять, как обрабатывать обратные вызовы HTTP в Android, поэтому я создал простое приложение, которое использует Volley для HTTP-запросов. У него есть только кнопка, которая инициирует HTTP-запрос к службе, которая, по сути, просто обновляет число в базе данных и отправляет его в ответе JSON через 5 секунд. Activity получает ответ и отображает ответ в TextView. Я тестирую его на реальном устройстве, на котором включена опция «Не сохранять действия» в «Настройки» — «Параметры разработчика».

Это сценарий, который я тестирую:

  1. Запустить приложение.
  2. Нажмите кнопку, которая запускает HTTP-запрос.
  3. Сразу после нажатия кнопки нажмите кнопку «Домой» устройства, чтобы перевести приложение в фоновый режим. Метод onDestroy вызывается из-за опции «Не сохранять действия».
  4. Подождите несколько секунд для ответа HTTP. Я вижу, что устройство получает его, потому что оно печатается в мониторе logcat, и база данных обновляется.
  5. Перед запуском обратного вызова я проверяю, что активность все еще жива. Поскольку активность была уничтожена, обратный вызов игнорируется. Если приложение восстанавливается из фонового режима, сбоя не происходит, но ответ сети пропускается. Кроме того, если я снова нажму на кнопку, он отправит новый HTTP-запрос и снова увеличит число...

Итак, вопросы:

  1. Каковы наилучшие методы доставки сетевых ответов в пользовательский интерфейс? Я имею в виду, если вместо простой операции, скажем, это была форма регистрации, и я получаю телефонный звонок или что-то, что заставляет меня отправить приложение в фоновый режим, где может произойти что угодно, как я могу быть уверен, что не пропущу обратный вызов сети? ? Есть ли что-то, что может задержать выполнение обратного вызова, пока приложение снова не окажется на переднем плане?

  2. Есть ли способ сохранить пакет, подобный тому, который находится в onSaveInstanceState, после вызова onDestroy и восстановить его, когда приложение снова окажется на переднем плане?

  3. Допустим, информация, содержащаяся в ответе HTTP, является конфиденциальной. Есть ли рекомендуемый способ справиться с этим случаем? Я думал сохранить ответ во внутреннем хранилище и проверить его, когда приложение снова окажется на переднем плане, но я не знаю, возможно ли это сделать после вызова onDestroy, или это не очень хорошая идея с конфиденциальные данные.

Заранее спасибо!


person allo86    schedule 25.05.2017    source источник


Ответы (1)


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

2) Нет. Если вам нужен результат сетевого вызова в следующий раз, когда действие начнется таким образом, я предлагаю вам использовать загрузчик для загрузки данных. Таким образом, вы можете запросить результаты загрузчика в следующий раз и запускать запрос только при необходимости.

3) Делайте то, что я предложил в 2, и этот вопрос не нужен, все в памяти приложения.

person Gabe Sechan    schedule 25.05.2017
comment
Привет @Gabe ... 1. Под не пропустить обратный вызов я имел в виду не пропустить выполнение этого блока. На самом деле я получаю обратный вызов, но не могу использовать его для обновления своего пользовательского интерфейса, потому что он был уничтожен. 2 и 3. Спасибо, попробую с Загрузчиком. У вас случайно нет примера? - person allo86; 25.05.2017
comment
Загрузчик также решает эту проблему - person Gabe Sechan; 25.05.2017
comment
Я пытаюсь объединить загрузчики с MVP. Я прочитал несколько статей, в которых рекомендуется использовать загрузчики для сохранения презентаторов, но я также отправляю запрос Volley от своего презентера (например, для входа пользователя), и у меня та же проблема, что и раньше: обратный вызов может быть доставлен в докладчик, когда представление (активность, фрагмент) не находится на переднем плане. Я думал об использовании загрузчика внутри Presenter, но это не очень хорошая идея, потому что Presenter должен избегать импорта Android. Вы знаете или имеете представление, как справиться с этой ситуацией? - person allo86; 30.05.2017