Это называется "очень низкое качество" в случае если сделано намеренно, либо "некорректно написанная программа", если так получилось само. В любом случае, представьте, что где-то там в реальном мире я последовал вашему совету и забил, а здесь - мы просто решаем задачку сильно оторванную от реальности :-)
@FoxInSox По-моему на изменения в данных можно подписаться только имея ContentProvider (где как раз уведомления об изменениях и реализуются). Где-то здесь я перестаю понимать для чего по-вашему нужна база в контексте этой задачи.
Есть куча способ запустить операцию асинхронно, AsyncTask - один из них. Основная его проблема в том, что после начала работы у него уже нет надёжного доступа к контексту запустившей его Activity.
Насчёт дополнительного сервиса не очень понял - как пользователь может это заметить?
1. По большому счёту единственное отличие вашего подхода от моего #3 в том, что вы предлагаете сохранять состояние в базу (против моего - "пусть висит в памяти").
2. С другой стороны, сочетание андроидовских SQLite+ContentProvider+Loader - это на самом деле просто очень специфическая реализация Observable/Observer. Кроме того, стоит отметить, что реализация минимального ContentProvider - это много кода.
Я, к сожалению, не могу согласиться, что этот подход лучше, т.к. выгоды минимальны, кода больше, а "некрасивость" реализации самой активити остаётся. Честно говоря, после вот этого легендарного выступления: www.youtube.com/watch?v=xHXn3Kg2IQE я даже попытался принять этот подход. Но на практике оказалось именно так, как я описал выше: куча лишнего кода, уродливо вцелом.
PS Полностью согласен - при общении через базу IntentService замечательно подходит. Но если сверху я вам написал, что-то вроде "я не хочу городить ContentProvider, потому что это много кода и мало выгоды в этой задаче", здесь я ещё добавлю - "какого чёрта в контексте одного единственного приложения я должен отказываться от POJO и работать через Intents?" Это ещё сколько-то кода, наличие которого сложно оправдать.
PS2 Здесь полностью согласен, обратите внимание - я там в явном виде написал, что это просто для упрощения задачи.
Не сказал бы, что это прямо _мои_ требования - сама платформа ("дух андроида") предполагает, что приложения должны себя вести именно таким образом:
1. Продолжать нормально работать при смене ориентации девайса - тут даже обсуждать нечего.
2. С нажатием кнопки "home" немного сложнее: в 95% случаев это что-то вроде "свернуть всё", в редких 5% это приведёт к полному завершению процесса приложения - здесь уже ничего не поделаешь. Но вот 95% - это совершенно штатный сценарий.
Поэтому и вопрос в такой формулировке: если описанное поведение - одно из базовых требований самой платформы, неужели во фреймворке нет каких-то подходящих инструментов?
Написано
Войдите на сайт
Чтобы задать вопрос и получить на него квалифицированный ответ.