Архитектура Android: где мы должны держать курсор (и)?

Question

Архитектура Android: где мы должны держать курсор (и)?

1

Сценарий:

public class MyApplication extends Application{...}

Три действия, обзор, список и карта,
отображая те же данные, предоставляя только различные UI/UX.

Данные, передаваемые в Contentprovider db и часто обновляемые извне с помощью SyncAdapter,
часть другого приложения.

Чтение данных из Contentprovider в курсор.
Do cursor.setNotificationUri(),
чтобы заставить курсор прослушивать изменения db/Uri.

Alt1. Удерживайте курсор в MyApplication.
Обзор, список и карта затем запрашивает MyApplication для данных.
При изменении db в MyApplication содержится ссылка на каждую активность
и уведомляет их о необходимости снова запрашивать данные из MyApplication.

Alt2. Удерживайте один курсор в каждом действии.
При изменении db каждая операция снова запрашивает курсор для данных.

Где мы должны держать курсор (ы)?

user77115 30 дек. 2010, в 13:58

Источник

0

+1 за вопрос. Особенности архитектуры Android - это вопрос, который стоит обсудить глубже.
Vit Khudenko 30 дек. 2010, в 22:47

Теги:

android

1 ответ

Ещё вопросы

+1 за вопрос. Особенности архитектуры Android - это вопрос, который стоит обсудить глубже.

codeScriber · Answer 1 · 2010-12-30T13-59-00.000Z

Я столкнулся с аналогичной проблемой, но не с DB и курсором, а с простым веб-запросом\response.
Проблема, с которой вы столкнетесь достаточно скоро, - это то, что срабатывает, когда ваша деятельность умирает посреди ответа на запрос. Я бы предложил следующее:

сделать базовую активность, наследующую из этого будет курсор для запрос.
убедитесь, что у вас есть способ заполнения топор с данными в onResume начать слушать трансляцию приемник.
когда вы закончите обновление db в отдельная тема, уведомлять все приемников.
когда вы выполняете команду create, проверьте данных в БД, чтобы увидеть, пропустили ли вы вызов из эфира, потому что ваша деятельность умер.

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

Спасибо, я ценю ваш вклад. Исходя из вашего ответа, я не уверен, что вы используете пользовательское приложение. Когда AndroidOS заканчивает жизнь Действия, Приложение все еще живет. Если приложение удерживает курсор, мы сделаем запрос только один раз, но будем хранить ссылки на действия. Если у каждого действия есть один курсор, мы будем использовать больше ресурсов базы данных, но не существует связанного действия Application <->. Мой вопрос связан с недостатками и преимуществами обоих подходов.
Не думайте, что Application живет вечно. На реальном устройстве это может быть убито как часть убийства фонового процесса. Например, если вы получаете входящий телефонный звонок, то ваше приложение переходит в фоновый режим. Процесс вашего приложения будет восстановлен, когда приложение снова появится на переднем плане (телефонный звонок завершен). При восстановлении экземпляр Application будет воссоздан, однако только вы отвечаете за обработку его состояния, например, если у вас есть какое-то поле в экземпляре Application и это поле было установлено какой-то другой частью приложения, то теперь вы можете получить null там вместо этого.