Diferencia exacta entre "Content-Provider" y "SQLite Database"

He hecho la programación de la base de datos de SQLite para Android, pero no sé nada acerca de Content-Provider, excepto esto: "Como me he referido página de desarrolladores de Android, Android SDK explicó acerca de" proveedor de contenido ", ya que se utiliza para almacenar y recuperar datos.

Pero entonces,

  1. ¿Cuál es la diferencia exacta entre "Content-Provider" y "SQLite Database"?
  2. ¿Cuál es el mejor para almacenar datos, cuándo?

Cualquier ejemplo o ayuda !!

Encontré una diferencia importante, como sigue:

Almacenar sus datos en una base de datos es una buena manera de persistir sus datos , pero hay una advertencia en las bases de datos Android creadas en Android que sólo son visible para la aplicación que las creó. Es decir, una base de datos SQLite creada en Android por una aplicación es utilizable sólo por esa aplicación, no por otras aplicaciones.

Por lo tanto, si need to share data between applications, you need to use the content provider model as recommended in Android. Este artículo presenta los conceptos básicos de los proveedores de contenido y cómo puede implementar uno.

Encontré este artículo en este enlace

Muy buena información.

¿Cuál es la diferencia exacta entre "Content-Provider" y "SQLite Database"?

ContentProvider es una fachada – una API que puede implementar que expone las bases de datos a otros procesos. Se puede implementar de una manera en la que los datos se almacenan en una base de datos SQLite, pero no tiene que ser.

¿Cuál es el mejor para almacenar datos, cuándo?

Eso es imposible responder en abstracto. En términos generales, a menos que algo le requiera usar un ContentProvider , simplemente use una base de datos.

He hecho muchas buenas aplicaciones con miles de usuarios que utilizan los métodos que simplemente utilizan SQLite. Pero eso fue hace un tiempo y tuve que escribir manualmente un montón de código que ahora puede ser fácilmente atendidos por ContentProvider. En ese entonces yo no estaba a favor de usar Proveedores de Contenido, porque parecía que solo agregaba complejidad en el código.

Sin embargo, durante el último par de años, como Android ha evolucionado, me he trasladado a ContentProvider, ya que ahorra tiempo y le permite hacer más. Ahora lo uso extensivamente. Una vez que haya escrito una clase de proveedor de contenido, su vida se vuelve mucho más fácil. Con ContentProvider puedo tratar mucho fácilmente con los cargadores del cursor, las devoluciones de llamada del cargador y las inserciones a granel para las cuales tuve que escribir todo manualmente en el pasado y todavía no trabajó tan eficientemente. Especialmente al actualizar la vista de lista, que ahora se actualiza automáticamente gracias a un solo método notifychange (). Esto significa que ahora no tengo que escribir mis propios oyentes y actualizar manualmente el contenido en vistas de lista y adaptadores. Además, no necesito preocuparme por abrir y cerrar bases de datos o preocuparme por fugas de memoria. Todo esto es manejado por el proveedor de contenido. El único problema que de vez en cuando me enfrento es que usted no puede hacer algunas preguntas complejas en ContentProviders. En este caso, todavía puede usar consultas sin procesar y utilizar la interacción manual antigua con sqlite.

Si ya ha escrito su propio DbAdapter, Helper y Observer, puede llevarlos a sus nuevas aplicaciones sin tener que dedicar tiempo a convertir todo a ContentProvider. Pero basado en mi experiencia, recomiendo encarecidamente pasar a ContentProvider. Tomará algún tiempo acostumbrarse, pero una vez que tenga experiencia con él, se quedará con él.

1. Proveedores de contenido no son seguros de subprocesos

De forma predeterminada, los proveedores de contenido no son seguros para los subprocesos. Si tiene varios subprocesos utilizando un proveedor de contenido, puede ver muchas excepciones diferentes que se lanzan y otras inconsistencias de datos. La forma más fácil de solucionar esto es utilizar la palabra clave sincronizada en cada uno de los métodos públicos expuestos por el proveedor de contenido.

De esta manera sólo un hilo a la vez puede acceder a estos métodos.

2. Juega bien al hacer muchas escrituras

Tengo la necesidad en la nueva aplicación Serval Maps de importar datos de archivos binarios en la base de datos utilizada internamente por la aplicación. Con el fin de hacer esto y jugar bien con el resto de la aplicación es mejor:

Generar un nuevo hilo para llevar a cabo la importación para que otros hilos no se vean afectados adversamente, en particular el hilo encargado de actualizar la interfaz de usuario; Y pausa brevemente al final de cada importación para dar otros hilos que necesitan utilizar los métodos sincronizados más de una oportunidad.

3. Los proveedores de contenido te obligan a pensar lateralmente a veces

La forma en que los proveedores de contenido en Android funcionan es proporcionar una capa de abstracción entre el resto de su código y la base de datos subyacente. Esto se debe principalmente al hecho de que, por lo que puedo decir, los proveedores de contenido pueden acceder a datos de lugares distintos de las bases de datos.

Esto significa que no puede ejecutar consultas SQL sin procesar en la base de datos subyacente y necesita especificar los diversos componentes de una consulta SQL utilizando variables pasadas a los diversos métodos como el método de consulta. Si tiene una tarea que no encaja en la forma en que SQL es manejado por un proveedor de contenido, tiene dos opciones:

Piense lateralmente sobre la consulta, tal vez usted puede obtener los datos que necesita por consultas alternativas y acceder a los resultados del cursor; Y Usar un URI para acceder a los datos normalmente y un URI especial que se corresponde con una consulta específica para aquellas tareas que no tienen alternativas.

Los proveedores de contenido se utilizan cuando desea compartir sus datos entre aplicaciones.

Si tiene una base de datos adjunta con una aplicación y desea que otra aplicación utilice algunos datos, puede implementar un proveedor de contenido que exponga los datos

Piense en sistemas avanzados de gestión de contenido. Cada objeto (página, imagen, artículo de noticias, elemento de evento, etc.) tiene un contenido, una dirección, permisos de usuario y formas de interactuar con él desde diferentes partes del sistema. Los proveedores de contenido hacen eso para Android. Ahora puede compartir archivos o imágenes que puede haber almacenado en su aplicación. También puede crear objetos compartidos personalizados, como contactos empresariales, notas editables, etc. Y especifique la seguridad y la aplicación predeterminada para tratar con dicho objeto cuando los abra desde cualquier otra aplicación.

La principal diferencia es: cuando tu aplicación necesita compartir información con otras aplicaciones, utiliza Content-Provider. Datos de almacenamiento sólo de SQLite para la aplicación que lo crea

Leí esta respuesta mientras buscaba la misma duda, así que pensé en compartirla. afirma –

Es una buena práctica proporcionar el nivel extra 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 utiliza un ContentProvider puede contener todos los cambios estructurales dentro de él, donde como si no use uno, se ven obligados a cambiar todas las áreas del código que se ven afectadas por los cambios estructurales. Además, es bueno poder volver a usar la misma API estándar para acceder a los datos en lugar de dejar basura su código con un acceso de bajo nivel a la base de datos.

Por lo tanto, usar un proveedor de contenido sería una buena idea.

Una diferencia es que los proveedores de contenido tienen soporte de plataforma para los observadores de contenido. Usted va a necesitar para implementar su propio patrón Observable para una base de datos SQLite.

Cómo volver a consultar automáticamente con LoaderManager

¿ContentObserver para SQLite?

El término "proveedor de contenido" es exclusivo para el desarrollo del sistema operativo Android. Significa un almacén de datos de valores de datos, y se encuentra principalmente en forma de bases de datos SQLite, que son parte integral del sistema operativo Android. Puede utilizar las bases de datos SQLite de proveedor de contenido que se proporcionan como parte integrada del sistema operativo Android, o puede crear sus propias bases de datos de proveedores de contenido para su aplicación si lo desea.

FlipAndroid es un fan de Google para Android, Todo sobre Android Phones, Android Wear, Android Dev y Aplicaciones para Android Aplicaciones.