Cuándo usar un proveedor de contenido


103

Entiendo que los proveedores de contenido están diseñados para permitir el intercambio público de datos entre aplicaciones. Sin embargo, me pregunto si alguien piensa en crear un proveedor de contenido para usar solo dentro de su propia aplicación. ¿Habría alguna ventaja al hacer esto? ¿Alguna desventaja?

En el pasado, acabo de implementar SQliteOpenHelper para acceder a los datos de mi base de datos, pero estoy considerando crear un proveedor de contenido. Siento que el enfoque de URI para solicitar datos es claro y conciso. Por otro lado, ¿usar un proveedor de contenido solo para mi aplicación será redundante (ya que dentro de él tendré una clase SQliteOpenHelper) y más trabajo del que necesito?


2
Hice una biblioteca para facilitar la escritura del proveedor de contenido. Incluso más fácil que escribir SQLiteOpenHelper simple. github.com/coocood/VContentProvider
coocood

Respuestas:


59

Si no planea compartir datos, no piense en los proveedores de contenido. Son poderosos pero difíciles de escribir y sería una tontería implementarlos si los va a usar internamente.

Sin embargo, me pregunto si alguien piensa en crear un proveedor de contenido para usar solo dentro de su propia aplicación.

Por supuesto ... por ejemplo, para una aplicación de lista de tareas pendientes que escribí, tuve que escribir un proveedor de contenido para permitir que otras aplicaciones recuperen y accedan a los estados de las tareas. Era parte de los requisitos, pero más que eso tenía sentido e hizo que la aplicación fuera más agradable.


34
Estoy de acuerdo con su justificación, pero también creo que es importante (especialmente para los principiantes) que una vez que se implemente el proveedor de contenido, obtenga muchos beneficios. Por ejemplo, puede usar el CursorLoaderpara realizar consultas asincrónicas ... tiene acceso a una instancia singleton (el ContentResolver) para realizar consultas, etc. Por supuesto, puede implementar su propio cargador para usarlo en su base de datos SQLite ... por supuesto que podría implementar el acceso a una sola instancia de base de datos en toda la aplicación ... y, por supuesto, no se requiere un ContentProvider a menos que desee compartir
Alex Lockwood

11
datos con otras aplicaciones. Dicho esto, hay muchos beneficios que vienen con la implementación de su propio proveedor de contenido, por lo que no debe dejar de considerarlo solo porque su aplicación no comparte sus datos.
Alex Lockwood

8
Sí, tienes toda la razón, pero sigo pensando que no vale la pena el esfuerzo en la mayoría de los casos. He hecho al menos 12 aplicaciones de Android diferentes (publicadas en Play Store) y nunca he necesitado un archivo ContentProvider. De hecho, la última aplicación en la que estábamos trabajando se hizo inicialmente con a ContentProvidery simplemente la eliminamos, ya que en realidad es más un dolor de cabeza de usar de lo que debería (incluso escribí una biblioteca para facilitar la implementación de ContentProviders básicos : github.com/casidiablo/persistence pero nunca lo había usado yo mismo XD).
Cristian

1
@Cristian ofrece los consejos más prácticos. Incluso el documento de Android establece que no deberíamos usarlo ContentProvidersi no es necesario: "No necesita un proveedor para usar bases de datos u otros tipos de almacenamiento persistente si el uso está completamente dentro de su propia aplicación y no necesita cualquiera de las funciones enumeradas anteriormente. En su lugar, puede utilizar uno de los sistemas de almacenamiento descritos en la página Guardar datos de la aplicación ". De lo contrario, estamos por encima de la ingeniería.
Cheok Yan Cheng

Resumen: si no planea compartir sus datos, puede evitar el proveedor de contenido, pero por otro lado, el proveedor de contenido le facilita la vida si desea cambiar la base de datos de su aplicación. por ejemplo, de SQLite a MangoDB.
Prashant

116

Yo diría que definitivamente es una buena idea usar un ContentProviderincluso si no tiene la intención de hacerlo público.

Es una buena práctica proporcionar un nivel adicional de abstracción sobre sus datos para facilitar el cambio interno. ¿Qué pasa si decide cambiar la estructura de la base de datos subyacente en un momento posterior? Si usa un ContentProvider, puede contener todos los cambios estructurales dentro de él, donde, como si no usara uno, se ve obligado a cambiar todas las áreas del código que se ven afectadas por los cambios estructurales. Además, es bueno poder reutilizar la misma API estándar para acceder a los datos en lugar de ensuciar su código con acceso de bajo nivel a la base de datos.

Además, siempre existe la posibilidad de que desee exponer sus datos en el futuro. Si no usa uno ContentProviderpor adelantado, será mucho más difícil adaptarlo en una fecha posterior.

Luego, están las otras partes de Android donde ContentProviderse requieren / recomiendan, como cuando se usa SyncAdaptersy si desea un widget de aplicación que implique acceso a datos, por ejemplo.

En resumen, hay muy poca sobrecarga involucrada en escribir un ContentProviderpor adelantado (una vez que haya aprendido la API, que es una buena idea de todos modos) por lo que tiene sentido hacerlo, incluso para datos privados.


1
No podría estar mas de acuerdo. Le obliga a abstraer su capa de datos de una manera que prácticamente garantiza que un nuevo desarrollador no podrá acoplar la interfaz de usuario con ella.
Gabriel

3
Inmediatamente después de aprender Android, comencé a pensar de la misma manera exactamente por esta razón. Incluso si no es público, siempre puede beneficiarse de la mayor abstracción y el punto único de implementación de sus decisiones arquitectónicas. Amo ContentProviders.
davidcsb

1
Puede hacer que el proveedor de contenido solo esté disponible para su propia aplicación con este atributo:android:exported="false"
Toby 1 Kenobi

4
En mi humilde opinión, puede y debe manejar sus datos de una manera completamente abstraída, sin necesidad de implementar ContentProvider.
hmartinezd

2
Mientras estaba implementando una solución de proveedor de contenido para mi base de datos sqlite interna (sin interacción con otras aplicaciones), vi el comentario en developer.android.com/guide/topics/providers/ ... que dice que no necesita un proveedor para usar una base de datos SQLite si el uso es completamente dentro de su propia aplicación.
Selçuk Cihan

7

Eche un vistazo a MOTODEV Studio para Eclipse. Es un entorno de desarrollo que amplía Eclipse. Tienen una herramienta donde puedes generar automáticamente un proveedor de contenido para una base de datos. Si un proveedor de contenido facilita el acceso a sus datos y no tiene un impacto significativo en el rendimiento, continúe y utilícelo. En la mayoría de los escenarios, este será el caso.


5

En resumen, Content Providersayuda a administrar sus datos de manera efectiva . Sugeriría usarlos por las siguientes razones.

  • Actúa como una capa de abstracción entre su interfaz de usuario y la base de datos . Puede implementar la validación de datos en ContentProviders para validar los datos ingresados ​​por el usuario. También le permite modificar la estructura de la base de datos sin tocar la interfaz de usuario y otras partes.
  • Funcionan muy bien con otras clases de framework de Android como SyncAdapter. Por ejemplo, puede actualizar automáticamente una lista, cuando un valor en una base de datos cambia usando ContentProviders junto con CursorLoader. Sin ContentProviders tienes que implementar muchas funcionalidades como estas por tu cuenta.
  • Podemos exponer de forma segura nuestros datos privados a otras aplicaciones . El uso de ContentProviders nos permitirá compartir nuestros datos de forma fácil y segura con otras aplicaciones.

Entonces, incluso si no necesita ninguna de estas funcionalidades ahora, es posible que las necesite en el futuro y es bueno hacer un esfuerzo adicional e implementarlas ahora mismo.


Gran respuesta. Descripción de una sola oración ContentProvidersy tres razones distintas por las que deberíamos usarlas. A veces, las explicaciones simples son las mejores. +1
AdamInTheOculus

4

Estoy de acuerdo con que los ContentProviders son un poco difíciles de entender, pero definitivamente son útiles, incluso si desea usarlos internamente para su propia aplicación. Lo mejor de esto es que puede personalizar los proveedores de contenido para los URI adecuados.

Aquí hay un escenario en el que puede tener 5 tablas en su base de datos, pero debe unir algunas de ellas en ciertos órdenes antes de usarlas. Y cree un URI de contenido para cada una de estas uniones. Luego, cada uno podría usar estos URI como una tabla :)

Le sugiero que siga adelante con Content Provider, se sorprenderá al ver lo poderoso que es.


2

Desde mi punto de vista, el proveedor de contenido tiene muchas ventajas, ya que solo comparte datos con otras aplicaciones. Si necesita sincronizar con el servidor usando un Adaptador de sincronización, use la mensajería en la nube de Google, actualice automáticamente la IU cuando los datos subyacentes en la base de datos cambien usando Loaders, implemente la búsqueda, use widgets ... entonces el proveedor de contenido es para usted.

Prefiero que siga las pautas porque un día es posible que deba implementar algunas de las funciones anteriores adjuntas al proveedor de contenido.

Por cierto, puede crear rápidamente su base de datos y su CP en menos de 5 minutos utilizando el generador de proveedores de contenido.


1

Como se dice en la documentación: Creación de un proveedor de contenido

No necesita un proveedor para usar una base de datos SQLite si el uso está completamente dentro de su propia aplicación.

Entonces, ¿por qué molestarse en desarrollar esta sobrecarga? Quieres un desarrollo más fácil y rápido, ¿verdad? Entonces, una capa de abstracción (descendiente de SQLiteOpenHelper) es suficiente.

Vea la navaja de Occam No cree entidades sin una muy buena razón.


0

No utilice el proveedor de contenido si no desea compartir datos con otras aplicaciones. Utilice sqlitedatabase simple para realizar operaciones de base de datos. Tenga cuidado al utilizar proveedores de contenido para almacenar datos confidenciales porque otras aplicaciones pueden acceder a su información confidencial


De forma predeterminada, los proveedores de contenido no están expuestos y es fácil administrar las restricciones de acceso a ellos. Votar en contra por difundir información errónea.
TBridges42

2
@ TBridges42 Estás (estabas) equivocado. De hecho, hasta que se expusieron los proveedores de contenido API de nivel 17 . Y al momento de la respuesta, el 25% de los dispositivos Android se vieron afectados por este comportamiento y todavía el 10% en el momento de su comentario . Entonces, es más al revés: tu comentario es peligroso, ya que dices algo para ser seguro que es / no era el hecho.
Murmel

0

El uso de un proveedor de contenido puede ayudar en un nivel adicional de abstracción: ponerlo dentro de su propia aplicación hace que agregue un tiempo de desarrollo significativo a su proyecto. Sin embargo, si lo está utilizando para compartir datos, configuraciones de aplicaciones o configuraciones en varias aplicaciones, entonces el proveedor de contenido es su elección.

Mire sus niveles de seguridad y recomendaría usar SQLcipher para cifrar los datos al restablecer (DAR) si su proveedor de contenido está escribiendo en SQLite. (He utilizado un proveedor de contenido en algunas soluciones y he ofrecido la posibilidad de realizar una "instantánea" en directo de los valores operativos para la depuración y las pruebas).

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.