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

[Artem_zin]

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

[Nagg]

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

[dtx12]

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

[SamSol]

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

[mike114]

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

[SamSol]

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

[djvu]

Потомков показывать и редактировать вы собираетесь во фрагментах?
В этом случае Гугл рекомендует обмен данными производить через родительскую 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]

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

[bimeg]

дел

[anton9088]

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

[tehnolog]

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

[anton9088]

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.

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

[Erny]

AsyncTask тут используется в качестве примера, да и 3 секунды укладываются в «a few seconds at the most». А так конечно каждой задаче — свое решение.

[kemsky]

Несколько секунд — этого достаточно, чтобы юзер успел свернуть прилагу.

[ComodoHacker]

Я один, открывая статью, ожидал увидеть хаб GTD, но никак не Android? :)