2010-08-30 8 views
5

Tengo una pregunta general sobre el diseño de Android en cuanto al acceso a los datos. Tengo una serie de actividades en mi aplicación que necesitan acceder a una base de datos SQLite. Para resumir toda la lógica de acceso a datos en un solo lugar, he creado una clase DatbaseHandler que se encarga de toda la lógica de acceso a datos. Esta clase se encarga de construir cláusulas where, llamar a la base de datos e interrogar al cursor resultante para recuperar los resultados de la consulta y devolverlos a la persona que llama. El objetivo de esta clase es ajustar todo el código de acceso a datos en un solo lugar para que se pueda administrar y mantener fácilmente, en lugar de tener una lógica de acceso a datos dispersa en todas las actividades. Cada actividad que necesita acceso a la base de datos crea una instancia de esta clase DatabaseHandler y le pasa una referencia de android.content.Context. La clase DatabaseHandler luego usa este objeto Context para llamar a un proveedor de contenido subyacente de la siguiente manera context_i.getContentResolver(). Query (...).Enfoque de diseño de acceso a la base de datos de Android

Mi lógica de acceso a datos (la lógica de manejo del cursor es específica) no está en la actividad y por eso no puedo administrar el ciclo de vida del cursor, por lo tanto, es probable que haya pérdidas de memoria.

Mis preguntas son las siguientes -

  1. ¿Cómo puedo (si es aún posible) administrar el ciclo de vida de los cursores desde fuera una actividad?
  2. ¿Debería cada actividad crear una instancia de esta clase de manejador de datos y pasarle una instancia de Contexto? Tal vez mi enfoque de diseño sea incorrecto y debería exponer estas funciones de acceso a los datos como métodos estáticos que toman una instancia de la actividad de llamada como parámetro. De esa forma podría realizar consultas administradas y dejar que la actividad se encargue de administrar el ciclo de vida de los cursores.

Realmente me gustaría entender el mejor enfoque. Cualquier consejo sería muy apreciado

Respuesta

2

El enfoque estándar:
Normalmente, si usted tiene un ContentProvider escrito por sí mismo y se registró correctamente en el archivo de manifest.xml, puede hacerlo solo (por ejemplo)

@Override 
public void onCreate(Bundle savedInstanceState){ 
    ... 

    if (getIntent().getData() == null) { 
     getIntent().setData(MyMetaData.CONTENT_URI); 
    } 

    Cursor cursor = managedQuery(getIntent().getData(), null, null, null, null); 

    //create an appropriate adapter and bind it to the UI 
    ... 
} 

esta llamará automáticamente al ContentProvider que es capaz de manejar el contenido URI dado, dado que se registró en el archivo manifest.xml como

<provider android:name="MyContentProvider" android:authorities="com.mycompany.contentprovider.MyContentProvider" /> 

Siempre sugiero que la gente mire el Notepad example para aprender cómo se debe implementar ContentProviders.

Alternativas:
En términos generales, si necesita acceder a sus datos sólo dentro de sus actividades que se pegaba al "enfoque estándar" utilizando ContentProviders, que por cierto. probablemente sea la solución más flexible.
Si su solución necesita para acceder a los datos también de clases que no son de Actividad donde no tiene los métodos "managedQuery", entonces podría implementar algún tipo de clases DAO (Objeto de Acceso a Datos) usted mismo. Un ejemplo podría ser

public class MyDataDao implements IMyDataDao { 
    private ContentResolver contentResolver; 

    public MyDataDao(ContentResolver contentResolver){ 
     this.contentResolver = contentResolver; 
    } 


    @Override 
    public MyDataObject readMyDataObjectById(long id){ 
     MyDataObject result = null; 

     Cursor myDataObjectCursor = contentResolver.query(...); 
     if(myDataObjectCursor != null && myDataObjectCursor.moveToFirst()){ 
     result = new MyDataObject(); 
     result.setTitle(myDataObjectCursor.get..); 
     ... 
     } 
     myDataObjectCursor.close(); 

     return result; 
    } 
} 

Eso puede funcionar también.A continuación, llame a su DAO

IMyDataDao dao = new MyDataDao(context.getContentResolver()); 
MyDataObject anObj = dao.readMyDataObjectById(10); 
... 

esperanza que apunta en la dirección correcta :)

+0

Gracias por su respuesta Juri pero creo que tal vez haya leído mal las preguntas. Ya tengo un proveedor de contenido y un objeto de acceso a datos en su lugar. (He modificado ligeramente las preguntas desde arriba para que sean un poco más claras). 1. ¿Cómo puedo (si es posible) gestionar el ciclo de vida de los cursores desde fuera de una Actividad (dentro de mi objeto de acceso a datos)? 2. ¿Debería cada actividad crear una instancia de este objeto de acceso a datos y pasarle una instancia de Contexto? ¿Quizás el DAO debería exponer los métodos estáticos para que cada actividad no necesite crear una instancia del objeto de acceso a datos? – Brian

+0

Ya proporcioné un ejemplo para manejar el cursor fuera de la actividad, es decir, en su objeto DAO. Por supuesto, deberías considerar crear instancias únicas de tus objetos dao, los estáticos generalmente son malos para las pruebas unitarias si te preocupas por eso. – Juri

Cuestiones relacionadas