En un escenario ideal, 5000 entradas son bastante pequeñas.
Probablemente no tendrá ningún problema al analizar la cadena en tiempo de ejecución (excepto si cada fila consta de varios cientos / miles de columnas, muy poco probable, entonces podría comenzar a desarrollar problemas). Todavía no recomendaría ir por esta ruta. Cargarlo en una variable de instancia significa que tendría que volver a cargar en cada nueva instancia de su objeto. Supongo que esta es su actividad / fragmento, entonces, eso también significaría que un simple cambio de orientación podría implicar una recarga completamente nueva. Una variable local como usted ha mencionado, significaría (además de los problemas con la variable de instancia) que de hecho se volvería a cargar cada vez que se llama al método correspondiente. El problema con ese enfoque comienza a aclararse en este punto.
Piensa en la CPU, piensa en la memoria. Y para dispositivos de gama baja, ¡piense en el tiempo!
Codificar el contenido CSV ya suena como una terrible, horrible, mala idea, por lo que podemos omitir ese enfoque por completo.
- Deshabilite Google Analytics o informes de Flurry en 3G
- ¿Alguien está usando mobDB.net para backend móvil, notificaciones push y análisis?
- ¿Por qué las aplicaciones de Android se actualizan con tanta frecuencia sin ningún cambio significativo en ellas?
- ¿Qué instituto es el mejor para el entrenamiento de Android en Banglore / Hyderabad?
- ¿Qué diseño es eficiente para diseñar el XML en Android Studio, relativo o lineal?
Importar el CSV en una base de datos SQLite suena más bien, pero probablemente desee hacerlo de antemano, para que pueda empaquetar el .db con su aplicación en lugar de un CSV. SQLite ya tiene comandos incorporados para facilitar la importación de archivos CSV.
En este punto, me vienen a la mente algunas preguntas.
¿Realmente está empaquetando el CSV con su aplicación, o se descargará en tiempo de ejecución? Si se está empaquetando, entonces, como dije, sería mejor empaquetar la versión SQLite en su lugar.
Si se trata de una descarga en tiempo de ejecución, probablemente ya conozca su estructura (o de qué otra manera la manejaría si no fuera así), por lo que podría configurar una base de datos vacía y luego insertar los valores CSV una vez completada la descarga.
Ahora, ¿qué pasa si el archivo CSV está siendo modificado / reemplazado en tiempo de ejecución? Simple. Simplemente aplique la operación correspondiente en la base de datos y estará bien.
¿Cuáles son exactamente las ventajas del enfoque DB?
Los pocos que vienen a la mente:
- Al seguir la ruta de la base de datos, ya evita el uso innecesario de la CPU para cargar y volver a cargar datos CSV. Si el contenido es estático y ha incluido previamente el db con su aplicación, entonces el sistema ni siquiera necesita hacer ningún trabajo de carga / recarga. De hecho, la carga / recarga en sí misma podría incluso presentar un nuevo conjunto de problemas. Concurrencia?
- Mantener el contenido CSV en una variable no sirve de nada que acaparar innecesariamente la memoria. Probablemente solo necesite menos del 1% de todos esos datos en un momento dado.
- El sistema Android ya tiene una forma muy eficiente de administrar la base de datos por usted, por lo que lo libera de una gran cantidad de ataques innecesarios y estresantes. Simplemente haga su solicitud y procese la respuesta. Todas las demás preocupaciones de gestión subyacentes se manejan por usted. Esto debería resolver su problema de obtener datos después de una devolución de llamada de actualización de GPS.
- Tiene una estructura de consulta más robusta a su disposición.
- También puede hacer uso de cargadores asíncronos, listos para usar.
