Cuándo usar un proveedor de contenido

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?

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.

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.

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.

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.

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.

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.

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.

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

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).