base de datos Access en Android

Question

Estoy creando una aplicación para Android que es básicamente una lista de información sobre las setas. Obtengo esta información de una base de datos sqlite. Tengo un singleton global con una clase de servicios dentro de la cual uso para acceder a mi db. Casi todas las actividades acceden al db. ¿Es mejor dejar mi db abierto todo el tiempo o abrirlo y cerrarlo porque necesito los datos?

Si la mejor práctica es dejarla abierta todo el tiempo, ¿dónde debo asegurarme de cerrarla y cuál es el peor de los casos si la dejo abierta cuando se destruye la actividad?

Answer 1

Basado en mi experiencia pasada en Java, diría que es mejor cerrar la conexión, probablemente no importe en una pequeña aplicación de Android, pero si tiene 10 aplicaciones en ejecución y todas ellas acceden a la base de datos, tener 10 conexiones pendientes Comience un poco más y, tarde o temprano, otra aplicación tendrá que esperar porque el servidor SQL no puede manejar más solicitudes.

Supongo que podría considerarlo como un archivo en su computadora. Lees datos de él y luego lo cierras cuando terminas. ¿Por qué mantener un archivo abierto en su aplicación?

Ahora soy muy nuevo en la programación de Android, así que no he podido implementar las llamadas a la base de datos. Pero cuando me enfrenté al mismo problema en una aplicación Java hace unos años, implementé un objeto de base de datos, en el que tenía la conexión a la base de datos. "Todos los demás" (las clases) tuvieron que llamar al objeto de la base de datos (método único o final) para obtener datos, más o menos como los procedimientos almacenados, pero en la aplicación en su lugar.

Por esta razón, sabía cuándo se hicieron las llamadas y cuándo se detuvieron. Luego puse un tiempo de espera, así que como si nada sucediera en unos minutos, cerraría la conexión al DB. (Esto también solucionó algunas excepciones de tiempo de espera porque el tiempo de espera de la conexión nunca ocurriría). Cuando se ingresaba una nueva llamada, podía comenzar fácilmente una nueva conexión y usar la nueva conexión de db.

Básicamente abstraí las llamadas SQL al tener métodos como public Fungus[] getAllFungus() y public Fungus[] getFilteredFungus(string where).

Answer 2

Abriría la base de datos según sea necesario. De esta forma, usted sabrá con certeza que la conexión se cerrará una vez que la actividad particular que la abrió haya finalizado. Aunque Android ha incorporado controles para asegurarse de que se cierre al finalizar la aplicación, no está de más estar en el lado seguro. También creo que tenerlo abierto todo el tiempo podría causar fugas o algo así.

Answer 3

Su mejor opción aquí es refactorizar para que su aplicación acceda a la base de datos a través de ContentProvider. La implementación de ContentProvider es lo único que tiene un control para abrir la base de datos.

Esto le da varias ventajas:

• sólo una cosa tiene la base de datos abierta, por lo que su problema simplemente desaparece.
• un montón de clases de apoyo estándar para automatizar cosas por el estilo de gestión de base de datos.
• mejor integración con las vistas estándar de administración de listas de Android, que están diseñadas para funcionar automáticamente con los cursores provistos por ContentProviders.
• Todos sus datos pueden ser direccionados por URI (típicamente del formulario 'contenido: //com.fnord.mushroom/mushroom/43'), lo que significa que otras aplicaciones también pueden acceder a sus datos.

El uso de un ContentProvider, es posible pegar tres o cuatro clases estándar en conjunto para producir una interfaz de navegador a su base de datos y en realidad nunca tiene que escribir cualquier lógica real.

En el lado negativo, ContentProviders solo admite el acceso a través de una interfaz limitada --- en términos de SQL, obtiene INSERT, SELECT, UPDATE y DELETE sin cláusulas anidadas. Si está haciendo cosas complejas de SQL, puede ser un poco doloroso enviar las solicitudes desde su aplicación al ContentProvider y viceversa. Sin embargo, la mayoría de las personas no necesitan hacer esto (y si lo hace, las intenciones personalizadas son el camino a seguir).