Erny 11 янв 2015 в 15:02

Транзакции фрагментов и потеря состояния активности

4 мин

12K

Разработка под Android*

+11

Комментарии 15

Artem_zin 11 янв 2015 в 15:26

1) Пользователь сворачивает приложение
2) Ваш Runnable добавляется в очередь после выполнения асинхронной задачи
3) Пользователь запускает другие приложения и всё такое
4) Android выгружает ваш процесс из памяти, чтобы дать её другим приложениям и ваша очередь никуда не сохраняется
5) Пользователь разворачивает ваше приложение
6) Очередь Runnable пуста, то что вы хотели выполнить не выполнится

Nagg 11 янв 2015 в 17:38

Если задача некритичная то и хрен с ней, а иначе — sticky service ;-)

dtx12 11 янв 2015 в 20:38

Ну так а что мешает сохранить очередь в bundle, а потом восстанавливать все обратно? Разве что придется немного изменить реализацию StateHandler.

SamSol 11 янв 2015 в 22:24

Мешает хотя бы то, что асинхронная задача может закончится после вызова onSaveInstanceState.

mike114 11 янв 2015 в 15:31

А встречал ли кто-нибудь толковые и всеобъемлющие рекомендации по сохранению состояния? Очень надоело лепить велосипеды под каждую задачу, а потом их чинить. Вот, например, получили мы иерархический JSON, показываем на первом экране родителя с какими-то данными, зависящими от потомков. Переходим на экран потомка, что-то меняем и возвращаемся обратно. Если хранить одну копию данных в приложении, то нужно как-то искать и присоединяться к нужной ветке на втором экране. Если сериализовать данные для каждого экрана, то как затем обновить восстановленного родителя при переходе на первый экран? А если еще и хранить эти данные в intent, то порой и места может не хватить.

SamSol 11 янв 2015 в 17:39

Есть суховатое руководство developer.android.com/training/basics/data-storage/index.html
Вкратце предлагают на выбор:
— хранить данные в SharedPreferences
— в файлах
— в SQL базе данных (android.database.sqlite)

djvu 12 янв 2015 в 12:12

Потомков показывать и редактировать вы собираетесь во фрагментах?
В этом случае Гугл рекомендует обмен данными производить через родительскую Activity:

All Fragment-to-Fragment communication is done through the associated Activity. Two Fragments should never communicate directly.

developer.android.com/training/basics/fragments/communicating.html

Как вариант, в случае, когда надо восстанавливать рабочий объект, после принудительного закрытия/сворачивания, можно воспользоваться сохранением/восстановлением savedInstanceState, в него помещать либо Serializable объекты либо преобразованные в JSON String объекты

Andoctorey 11 янв 2015 в 18:32

Если диалог необходимо обязательно показать после завершения длительной операции в фоне, то лучше использовать сервис, если нет, то чем плохо использовать проверку if (!getActivity().isFinishing())?

bimeg 11 янв 2015 в 18:35

дел

anton9088 11 янв 2015 в 18:50

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

tehnolog 11 янв 2015 в 19:13

А насколько длительных? Есть какое-то определение длительности? Миллисекунды, секунды, минуты? Документация умалчивает данный аспект.

-2

anton9088 11 янв 2015 в 21:11

AsyncTask is designed to be a helper class around Thread and Handler and does not constitute a generic threading framework. AsyncTasks should ideally be used for short operations (a few seconds at the most.) If you need to keep threads running for long periods of time, it is highly recommended you use the various APIs provided by the java.util.concurrent package such as Executor, ThreadPoolExecutor and FutureTask.

второй абзац из документации