oreo - android pie
Diferencia exacta entre "Content-Provider" y "SQLite Database" (9)
¿Cuál es la diferencia exacta entre "Content-Provider" y "SQLite Database"?
ContentProvider es una fachada, una API que puede implementar y que expone las bases de datos a otros procesos. Se puede implementar de forma que los datos se almacenen en una base de datos SQLite, pero no tiene que ser así.
¿Cuál es mejor para almacenar datos? ¿Cuándo?
Eso es imposible de responder en abstracto. En términos generales, a menos que algo requiera el uso de un ContentProvider , simplemente use una base de datos.
He hecho programación de bases de datos SQLite para Android, pero no sé nada sobre Content-Provider excepto esto: "Como he referido la página de Android Developer , Android SDK explicó sobre" Content-provider ", ya que se usa para almacenar y recuperar datos".
Pero entonces,
- ¿Cuál es la diferencia exacta entre "Content-Provider" y "SQLite Database"?
- ¿Cuál es mejor para almacenar datos? ¿Cuándo?
Cualquier ejemplo o ayuda !!
1. Los proveedores de contenido no son seguros con subprocesos
Por defecto, los proveedores de contenido no son seguros para subprocesos. Si tiene varios hilos usando 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 forma, solo un hilo a la vez puede acceder a estos métodos.
2. Juega bien cuando haces 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. Para hacer esto y jugar bien con el resto de la aplicación, es mejor:
Genera un nuevo hilo para llevar a cabo la importación para que otros hilos no se vean afectados negativamente, en particular el hilo que se encarga de actualizar la interfaz de usuario; y Pausa brevemente al final de cada importación para dar más oportunidad a otros hilos que necesitan utilizar los métodos sincronizados.
3. Los proveedores de contenido te obligan a pensar lateralmente a veces
La forma en que trabajan 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, que yo sepa, de que los proveedores de contenido pueden acceder a los datos desde 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 las variables pasadas a los distintos métodos, como el método de consulta. Si tiene una tarea que no se ajusta a la forma en que un proveedor de contenido maneja SQL, tiene dos opciones:
Piense lateralmente sobre la consulta, tal vez pueda obtener los datos que necesita mediante consultas alternativas y acceder a los resultados del 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.
Encontré una gran diferencia, de la siguiente manera:
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 solo son visible para la aplicación que las creó. Es decir, una base de datos SQLite creada en Android por una aplicación solo puede ser utilizada 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 link
Muy buena información proporcionada.
He creado muchas aplicaciones buenas con miles de usuarios que las usan y que simplemente usan métodos SQLite. Pero eso fue hace un tiempo y tuve que escribir manualmente un montón de código que ahora se puede encargar fácilmente por ContentProvider. En aquel entonces no estaba a favor de usar proveedores de contenido porque parecía agregar complejidad al código.
Sin embargo, en los últimos años, a medida que Android evolucionó, me he mudado a ContentProvider, ya que ahorra tiempo y le permite hacer más. Ahora lo uso ampliamente. Una vez que tenga una clase de Proveedor de contenido escrita, su vida será mucho más fácil. Con ContentProvider puedo tratar fácilmente con cargadores de cursor, rellamadas de cargador e inserciones masivas para las cuales 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 las pérdidas de memoria. Todo esto lo maneja el proveedor de contenido. El único problema que de vez en cuando me enfrento es que no puedes hacer algunas consultas complejas en ContentProviders. En este caso, puede seguir utilizando consultas sin formato y utilizar la interacción manual pasada de moda con sqlite.
Si ya ha escrito su propio DbAdapter, Helper y Observer, puede llevarlos con seguridad a sus nuevas aplicaciones sin perder tiempo para convertir todo en ContentProvider. Pero según mi experiencia, recomendaría encarecidamente moverme a ContentProvider. Le llevará un tiempo acostumbrarse, pero una vez que tenga experiencia con él, se quedará con él.
ACTUALIZACIÓN 2017 Ahora he cambiado a Realm , una forma mucho mejor de usar bases de datos en cualquier plataforma. Dedíquese unas horas a aprenderlo y ahorre incontables horas en su carrera de desarrollo de aplicaciones.
La principal diferencia es: cuando su aplicación necesita compartir información con otras aplicaciones, use el Proveedor de contenido. SQLite solo datos de almacenamiento 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 extra de abstracción sobre sus datos para facilitar el cambio interno. ¿Qué sucede 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 si no usa 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 el código con acceso de bajo nivel a la base de datos.
Entonces, usar un proveedor de contenido sería una buena idea.
Los proveedores de contenido se utilizan cuando desea compartir sus datos entre las aplicaciones.
Si tiene una base de datos adjunta con una aplicación y desea que otra use algunos datos, puede implementar un proveedor de contenido que exponga los datos.
Piensa en sistemas avanzados de administració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 lo hacen para Android. Ahora puede compartir archivos o imágenes que pueda haber almacenado en su aplicación. También puede crear objetos personalizables personalizados, como contactos de negocios, notas editables, etc. Y especifique seguridad y la aplicación predeterminada para tratar con dicho 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.