tutorial studio example espaƱol development developer blog android rest io android-contentprovider

studio - development android



Android ContentProvider y Google IO Rest Talk (2)

En mi experiencia, implementar un proveedor de contenido puede ser mucho más trabajo que simplemente trabajar directamente con una base de datos. 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.

Debido a que es una charla de DESCANSO, otra razón podría ser porque Google está empezando a centrarse en muchas ideas de almacenamiento en la nube. Si puede implementar un proveedor de contenido, puede cambiar su funcionalidad de recuperación de datos mientras conserva gran parte de su código existente. Un proveedor de contenido generalmente separa la funcionalidad de recuperación de datos de los datos reales, lo que lo hace mucho más flexible. Si quisiera cambiar sus datos a la nube, sería mucho más fácil implementar un proveedor de contenido dentro de su aplicación.

Sin embargo, en mi opinión, la mayoría de las aplicaciones no necesitan consultar las grandes cantidades de datos que hacen que el almacenamiento en la nube sea deseable. Depende de la aplicación, pero creo que estará bien si evita a un proveedor de contenido si sus datos se deben mantener en casa.

A todos,

Si observa la sesión de Google IO en la creación de aplicaciones REST de Android, están sugiriendo en los tres patrones de diseño que utilicen los Proveedores de contenido, independientemente de si necesita compartir datos o no.

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

Mi aplicación NO necesita compartir ningún dato con otras aplicaciones, ¿por lo tanto, es un uso excesivo del proveedor de Contenido? Y si es así, ¿por qué el video IO REST de Google implica que debe usarse en todos los escenarios?

- = Actualizar = -

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


No hay una respuesta correcta o incorrecta real a esta pregunta, pero estoy fuertemente en el uso de un campamento de proveedores de contenido por las razones a continuación.

Obtiene una interfaz CRUD fácil de usar y bien definida para sus datos. Una vez que haya escrito un Contrato y sus métodos de Proveedor, solo es un par de líneas para comenzar a recuperar datos. Cuando vengas a trabajar en el proyecto más tarde, o contrates a otro desarrollador, estarás al día en minutos.

Muchas clases en el marco de Android están diseñadas para trabajar con proveedores de contenido. En particular, los CursorLoaders son brillantes, 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 tomará un tiempo .

¿Actualizando o insertando filas a menudo? Es bastante fácil notificar los cambios a ListViews y a otros consumidores de Cursor a través del 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 un filtro potente a un ListView? Nuevamente, es simple si está usando Cursores y Proveedores de contenido, y una gran cantidad de trabajo si no lo está.

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.

Podría (y puede) expandir más esta publicación, pero espero que tengas la idea. Google usa proveedores en aplicaciones geniales como iosched por una razón.