Контент-провайдеры: обернуть статичным фасадом?

Question

Я столкнулся с небольшой дилеммой дизайна, я нацелился на Android 2.3.3 и имею собственную реализацию ContentProvider.Затем у меня есть класс статических методов для абстрагирования провайдера контента - предоставляя мне объекты, представляющие каждую сущность (строку) на основе моего запроса.Какое-то время мне было очень удобно работать так, пока я не захотел использовать всю коллекцию в нескольких местах для выполнения «тестов на попадание» и рисования на экране.У меня тогда возникла головная боль, связанная с обновлением представлений объектов, и в этот момент я решил сделать шаг назад и пересмотреть, где это взять.

Как я уже сказал, в настоящее время я использую 2.3.3,и понимаю, что в 3.0 CursorLoader преодолевает много проблем, с которыми я столкнулся.Мне все еще нужно поддерживать смартфоны, поэтому, если не будет обратного порта, я не смогу это сделать.

В качестве временного решения я начал регистрировать слушателей notifyChange, чтобы я мог перестроить коллекцию с помощью своего исходного запроса, номне кажется, что это сильно загружает процессор и потенциально медленный.Я еще не решил, следует ли мне откатиться от использования статического фасада и вместо этого использовать устаревший теперь вызов managedQuery из Activity.

Поэтому у меня есть два вопроса:

1) Есть липредпочтительный способ избежать проблем с работой с коллекцией, основанной на contentProvider?

2) Есть ли у вас какие-либо советы по работе с необработанными курсорами в действии?Должен ли я делать из них объекты или работать с курсором как есть?Я конечно чувствую, что они должны быть в AsynTask при выполнении запроса, но после этого я могу использовать их где-нибудь?

Answer 1

Хорошо, я пришел к решению, и оно работает надежно.

1) Есть ли предпочтительный способ избежать проблемы с работой против Коллекция основана на ContentProvider

Я решил, что выбранный мной подход был правильным; В моей ситуации предпочтительнее создать кеш, чем поддерживать курсор (управляемый или нет) для ContentProvider; это позволяет мне повторно использовать методы и уменьшить объем кода, который требует тестирования. Слушатели NotifyChange важны до тех пор, пока не будут работать на 3.0+, и это означает, что я должен гарантировать, что NotifyChange вызывается - еще один аргумент для централизации всего этого кода, так что он действительно вызывает изменения, когда ожидается.

2) Есть ли у вас какие-либо советы по работе с сырые курсоры в деятельности? Нужно ли мне делать из них предметы или работа с курсором как есть? я конечно чувствую, что они должны быть в AsyncTask при выполнении запроса, но после этого я могу использовать их где-нибудь?

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