He realizado la programación de la base de datos SQLite para Android, pero no sé nada sobre Content-Provider excepto esto: "Como me he referido a la página de desarrollador de Android, Android SDK explicó sobre" Content-provider "como se usa para almacenar y recuperar datos".

Pero entonces,

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

Cualquier ejemplo o ayuda !!

Encontré una gran diferencia, como sigue:

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

Entonces, 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 proporcionada.

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

ContentProvideres una fachada: una API que puede implementar y que expone las bases de datos a otros procesos. Se puede ser implementado de una manera en que los datos se almacenan en una base de datos SQLite, pero no tiene que ser.

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

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

He creado muchas buenas aplicaciones con miles de usuarios que las utilizan y que simplemente utilizan métodos SQLite. Pero eso fue hace un tiempo y tuve que escribir manualmente una gran cantidad de código que ahora puede ser manejado fácilmente por ContentProvider. En ese entonces no estaba a favor de usar proveedores de contenido porque parecía que solo agregaba complejidad al código.

Sin embargo, durante los últimos años, a medida que Android ha evolucionado, me he mudado a ContentProvider, ya que ahorra tiempo y te permite hacer más. Ahora lo uso mucho. Una vez que haya escrito una clase de proveedor de contenido, su vida se vuelve mucho más fácil. Con ContentProvider puedo lidiar fácilmente con Cursor Loaders, Loader Callbacks y Bulk Inserts para los que tuve que escribir todo manualmente en el pasado y aún así no funcionó 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 pérdidas de memoria. Todo eso lo maneja el proveedor de contenido. El único problema al que me enfrento de vez en cuando es que no se pueden realizar consultas complejas en ContentProviders. En este caso, aún puede usar consultas sin procesar y usar la interacción manual antigua con sqlite.

Si ha escrito previamente su propio DbAdapter, Helper y Observer, puede llevarlos de forma segura a sus nuevas aplicaciones sin perder tiempo para convertir todo a ContentProvider. Pero según mi experiencia, recomendaría encarecidamente pasar a ContentProvider. Llevará algún tiempo acostumbrarse a él, pero una vez que tenga experiencia con él, se quedará con él.

ACTUALIZACIÓN 2017 Ahora me cambié a Realm , una forma mucho mejor de usar bases de datos en cualquier plataforma. Dedique unas horas a aprenderlo y ahorre innumerables horas en su carrera de desarrollo de aplicaciones.

1. Los proveedores de contenido no son seguros para subprocesos

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

De esta manera, solo un hilo a la vez puede acceder a estos métodos.

2. Juega bien al escribir muchas cosas

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

Genere un nuevo hilo para realizar la importación de modo que otros hilos no se vean afectados negativamente, en particular el hilo encargado de actualizar la interfaz de usuario; y Pause brevemente al final de cada importación para dar más oportunidades a otros subprocesos que necesitan usar los métodos sincronizados.

3. Los proveedores de contenido te obligan a pensar de forma lateral a veces

La forma en que funcionan los proveedores de contenido en Android 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, por lo que yo sé, de que los proveedores de contenido pueden acceder a datos desde lugares distintos a las bases de datos.

Esto significa que no puede ejecutar consultas SQL sin procesar en la base de datos subyacente y debe 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 un proveedor de contenido maneja SQL, tiene dos opciones:

Piense lateralmente en la consulta, tal vez pueda obtener los datos que necesita mediante consultas alternativas y accediendo a los resultados desde el cursor; y Use un URI para acceder a los datos normalmente y un URI especial que coincida 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 use algunos datos, puede implementar un proveedor de contenido que exponga los datos.

La principal diferencia es: cuando su aplicación necesita compartir información con otras aplicaciones, utilice Content-Provider. SQLite solo almacena datos 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 un nivel adicional de abstracción sobre sus datos para facilitar los cambios internos. ¿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.

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

Piense en sistemas de gestión de contenido avanzados. 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 haya almacenado en su aplicación. También puede crear objetos personalizados para compartir, como contactos de negocios, notas editables, etc. Y especifique la seguridad y la aplicación predeterminada para tratar con ese objeto cuando los abra desde cualquier otra aplicación.

Una diferencia es que los proveedores de contenido tienen soporte de plataforma para los observadores de contenido. Necesitará implementar su propio patrón observable para una base de datos SQLite.

Cómo volver a consultar automáticamente con LoaderManager

ContentObserver para SQLite?