Android ContentProvider и Google IO Rest Talk

Всем,

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

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

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

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

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

Ответ 1

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

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

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

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

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

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

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

Ответ 2

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

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

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