Android ContentProvider и Google IO Rest Talk

Question

Для всех,

Если вы смотрите сеанс Google IO по созданию приложений Android REST, они предлагают во всех трех шаблонах проектирования использовать контент-провайдеров независимо от того, хотите ли вы обмениваться данными или нет.

Если вы посмотрите на документацию по контент-провайдеру по номеру http://developer.android.com/reference/android/content/ContentProvider.html, они говорят, что вам нужно использовать контент-провайдера, только если вы планируете делиться своими данными с другими приложениями.

Моему приложению не нужно обмениваться данными с другими приложениями, поэтому использование поставщика контента является чрезмерным? И если да, то почему видео Google IO REST подразумевает, что оно должно использоваться во всех сценариях?

- = Обновить = -

Переговоры здесь https://dl.google.com/googleio/2010/android-developing-RESTful-android-apps.pdf.

Answer 1

Нет правильного или неправильного ответа на этот вопрос, но я решительно в использую лагерь контент-провайдера по следующим причинам.

Вы получаете четко определенный, простой в использовании интерфейс CRUD для ваших данных. После того как вы написали Контракт и ваши методы Провайдера, это всего лишь пара строк, чтобы начать извлечение данных. Когда вы позже приступите к работе над проектом или наймете другого разработчика, у вас будет скорость в течение нескольких минут.

Множество классов в платформе Android предназначены для работы с контент-провайдерами. В частности, CursorLoaders великолепны, и вам придется проделать немалую работу, чтобы эмулировать их функциональность самостоятельно. Удачи в управлении жизненным циклом курсора внутри действия, в дополнение к написанию всего собственного кода для извлечения данных и асинхронных задач. Есть разные нюансы и вещи, о которых нужно позаботиться. Это займет некоторое время .

Часто обновляете или вставляете строки? Довольно просто уведомить ListViews и других потребителей Cursor об изменениях через ContentProvider. Если вы не используете ContentProvider, вам придется написать своих собственных наблюдателей и управлять ими самостоятельно.

Хотите интегрировать окно быстрого поиска или применить мощную фильтрацию к ListView? Опять же, это просто, если вы используете Cursors и ContentProviders, и весь объем работы, если вы не.

Если в будущем вы решите открыть свои данные для других приложений, вы все равно в конечном итоге будете писать ContentProvider. Помните, что вы все равно можете использовать ContentProviders, не позволяя другим приложениям изменять ваши данные.

Я мог бы (и могу) расширить этот пост, но, надеюсь, вы поняли идею. Google использует провайдеров в таких замечательных приложениях, как iosched по определенной причине.

Answer 2

По моему опыту, внедрение контент-провайдера может потребовать гораздо больше усилий, чем просто работа с базой данных напрямую.Одна из причин, по которой Google может сказать, что приложение должно использовать контент-провайдера, может заключаться в том, что они верят в расширение.Приложение, которое реализует контент-провайдера, будет легко расширять свои данные для других приложений.

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

Однако, по моему мнению, большинству приложений не нужно запрашивать большие объемы данных, которыесделать облачное хранилище желательным.Это зависит от приложения, но я думаю, что вы будете в порядке, избегая поставщика контента, если ваши данные должны храниться внутри компании.