Android ContentProvider и Google IO Rest Talk

Все,

Если вы наблюдаете за сеансом 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 .

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

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

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

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

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

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

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

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

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

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