Android ContentProvider y Google IO Resto Talk

Question

A todos,

Si ver la sesión de Google IO en la construcción de aplicaciones REST Android están sugiriendo en los tres patrones de diseño para utilizar proveedores de contenido sin tener en cuenta si necesita compartir datos o no .

Si mira el documento de clase de proveedor de contenido en http://developer.android.com/reference/android/content/ContentProvider.html, dicen que solo necesita utilizar un proveedor de contenido si planea compartir sus datos con otras aplicaciones.

Mi aplicación NO necesita compartir ningún dato con otras aplicaciones, ¿está utilizando una sobrecarga del proveedor de contenido? Y en caso afirmativo, ¿por qué el video Google IO REST implica que se debe usar en todos los escenarios?

- = = - Actualizar

Las conversaciones están aquí https://dl.google.com/googleio/2010/android-developing-RESTful-android-apps.pdf.

Answer 1

No hay una respuesta correcta o incorrecta a esta pregunta, pero estoy muy interesado en el use un proveedor de contenido camp por los siguientes motivos.

Usted obtiene una interfaz CRUD bien definida y fácil de usar para sus datos. Una vez que haya escrito un contrato y sus métodos de proveedor, son solo un par de líneas para comenzar a recuperar datos. Cuando trabajes en el proyecto más tarde o contrates a otro desarrollador, estarás actualizado en minutos.

Muchas clases en el marco de Android están diseñadas para trabajar con proveedores de contenido. En particular, los CursorLoaders son geniales, y tendrás que hacer una buena cantidad de trabajo para emular su funcionalidad por tu cuenta. Buena suerte con la gestión del ciclo de vida del cursor dentro de una actividad, además de escribir todo su propio código de recuperación de datos y tareas asíncronas. Hay varios matices y cosas para cuidar. Esto llevará mientras que.

¿Actualizar o insertar filas a menudo? Es bastante fácil notificar a ListViews y a otros consumidores de Cursor de los cambios a través de ContentProvider. Si no está utilizando un ContentProvider, tendrá que escribir sus propios observadores y administrarlo usted mismo.

¿Desea integrar el cuadro de búsqueda rápida o aplicar algún filtro poderoso a un ListView? Nuevamente, es simple si está usando Cursores y ContentProviders, y una gran cantidad de trabajo si no es así.

Si, en el futuro, decide abrir sus datos a otras aplicaciones, terminará escribiendo un ContentProvider de todos modos. Recuerde, aún puede usar ContentProviders sin permitir que otras aplicaciones modifiquen sus datos.

Pude (y puedo) ampliar esta publicación aún más, pero espero que entiendas la idea. Google usa proveedores en aplicaciones geniales como iosched por una razón.

Answer 2

En mi experiencia, implementar un proveedor de contenido puede ser mucho más trabajo que simplemente trabajar con una base de datos directamente. Una de las razones por las que Google podría decir que una aplicación debería usar un proveedor de contenido podría ser porque creen en la expansión. Una aplicación que implementa un proveedor de contenido tendría un tiempo fácil para expandir sus datos a otras aplicaciones.

Porque es una charla de REST, otra razón podría ser porque Google está empezando a enfocarse en una gran cantidad de ideas de almacenamiento en la nube. Si puede implementar un proveedor de contenido, puede cambiar su funcionalidad de recuperación de datos sin perder mucho de su código existente. Un proveedor de contenido generalmente separa la funcionalidad de recuperación de datos de los datos reales, dejándola mucho más flexible. Si desea cambiar sus datos a la nube, sería mucho más fácil haber implementado un proveedor de contenido dentro de su aplicación.

En mi opinión, sin embargo, la mayoría de las aplicaciones no necesitan consultar las grandes cantidades de datos que hacen deseable el almacenamiento en la nube. Depende de la aplicación, pero creo que estarás bien si evitas a un proveedor de contenido si tus datos están destinados a mantenerse en la empresa.