niclabs / adkintunmobile-androidclient Goto Github PK

Actualmente, cuando una request falla se paraliza la cola de envíos de Volley y sólo se vuelve a reiniciar cuando se detecta un cambio en la conectividad wifi (android.net.wifi.STATE_CHANGE según el intent filter del Manifest).

Sin embargo, un envío puede fallar por razón del servidor y no por falla de conectividad wifi... Luego, lo ideal sería que se puediera reactivar la cola no sólo por cambios de wifi, sino que haga una especie de retry de activación de la cola cada cierto tiempo.

Se debe implementar el fragment y vista para la funcionalidad de "Tu estado"

agregar documentación sobre parámetros de clases para manejo de donutchart, incluyendo el uso de clases DailyConnectionTypeInformation

Evaluar el udo de Fabric.io para el reporte de bugs en la palicación durante la marcha blanca

se debe hacer una rutina que trate de lanzar los servicios de monitoreo en el MainActivity.java (o la clase que sea necesaria) para empezar la recolección de datos y regular los demás servicios que operen en background.

Se debe actualizar el mensaje de la vista acerca de para incluir términos y condiciones y una descripción del proyecto.

Por la naturaleza de estos mensajes, lo mejor sería incorporar a la api del servidor un recurso que provea dichos textos y que la app los rescate dinámicamente, de manera de mantener ésta infromación consistente siempre entre lo presentado en la versión web y la app móvil. (ping @Zeeerooo )

Esta contendrá los datos de la SIM y métodos para obtener dicha información. La idea es usarla como un singleton, que se autocomplete al ser construida, y que ante cualquier cambio se envíe nuevamente la información.

se deben implementar métodos de backup en la clase Report

Crear servicio que recolecte y almacene los distintos eventos de tráfico dados por el ConnectivityListener provisto por la librería de monitoreo.

Se debe preparar una vista de preferencias

Se debe diseñar un método simple para la generación de notificaciones que se gatillen de la app

Se deben agrupar los wrappers en un paquete separado para mantener mejor orden de las clases eprsistentes.

Se debe implementar un boton dismiss en la snackbar de aplicationTraffic al cambiar el periodo mostrado.

Se debe crear una clase que cree una alarma recurrente para gatillar un proceso de recuperación de datos según lo especificado en el issue #7

Un ejemplo simple para seguir de modelo está disponible en http://www.iteramos.com/pregunta/6142/gestor-de-alarmas-ejemplo

Se deben re estructurar los layouts de los fragments y de la main activity para hacer flexible el uso de la collapsing toolbar y de la toolbar + tabs, dependiendo del fragment en operación.

La idea es sacar de la main activity la configuración de la toolbar y dejar sólo la configuración del navigation drawer, para que cada fragment sea responsable de levantar su toolbar y formatearla según sea necesario.

Se debe implementar la base de la distribución de vistas, fragments y activities de la app en packages definidos.

La idea es que los servicios de monitoreo se inicialicen junto con el inicio del teléfono, y no haga falta iniciar la app para empezar a colectar datos.

Crear una clase para definir constantes como urls de servidor, periodicidad de rutinas, etc.

Usar Singleton Pattern para hacer más eficiente el envio, al tener una única cola de peticiones (RequestQueue) para todo el ciclo de vida de la aplicación.

Se deben documentar (sobre las mismas firmas de los métodos) el uso y descripción de parámetros de las clases bajo el package sync para el manejo de peticiones HTTP

En el método onMobileTelephonyChange de la clase TelephonyMonitor.java se debe distinguir entre el evento reportado, pues a pesar de entregar una TelephonyObservation de la librería, podría ser en realidad un GsmObservation o un CdmaObservation, pues son clases que heredan de la primera. Actualmente sólo se intenta castear a un GsmObservationWrapper pero idealmente se debe verificar si calza para ser una observación de CDMA. En caso de que se reporten observaciones CDMA se debe además implementar la clase CdmaObservationWrapper.

Implementación de la vista "Consumo por app". Se debe implementar un adapter que registre el consumo d edatos moviles por app.

Revisar si se puede reciclar de la app anterior.

Se deben incorporar recursos gráficos para mostrar información de tipo de señal, operadores, etc.

Reciclar de la app anterior.

Se debe agregar una versión invertida de las horas del reloj de 24 horas, además de agregar dimensiones para las distintas resoluciones.

Se debe implementar una clase para crear facilmente dialogs informativos que permitan incluir imagenes y textos descriptivos de ciertos elementos mostrados en la aplicacion. Ej. Explicar que es tu tipo de señal, la diferencia de tu sim con tu red, etc.

Se debe perfeccionar el método save() de la clase GsmObservationWrapper.java para hacer el almacenamiento persistente de la lista de las NeighborAntenna en caso de que dicho campo sea distinto de null.

se debe agrupar y estandarizar las dimensiones usadas en el archivo dimen

Crear servicio que recolecte y almacene los distintos eventos de tráfico dados por el TrafficListener provisto por la librería de monitoreo.

Estas están definidas en el modelo del proyecto.

Este proceso debe realizarse utilizando las funcionalidades del ORM

Las clases DailyConnectionModeInformation y DailyConnectionModeSummary poseen métodos que manejan información recopilada por los ConnectionModeSample's. Ambos métodos comparten cosas en común, lo que produce que haya duplicación de código.

se deben redefinir los nombres de los conjuntos de eventos serializados en la clase EventsReport.java para concordar con los recibidos en el servidor

Definir una clase PostRequest que reciba un map y permita crear una peticion http que se encole en la cola de volley

Implementación de la vista "Notificaciones". Se debe implementar un list adapter para llevar el registro de las notificaciones que gatille la app, y de los eventos importantes que se registren en el log del sistema

Implementación de la vista "Acerca de", con la información de la app y del proyecto

Crear las clausuras de configuración de la base de datos para Sugar (provisto por la librería de monitoreo) en el manifest de la aplicación.

Idear un mecanísmo que junte, despache, verfique el envío y elimine los eventos correspondientes almacenados en el dispositivo, entre un rango de fechas.

Implementación de la vista "Tipo de Señal". Se debe proveer una vista de resumen y la visualziacion de detalle con vistualizacion de disco o torta

Crear servicio que recolecte y almacene los distintos eventos de tráfico dados por el TelephonyListener provisto por la librería de monitoreo.

Se debe implementar un datePicker para seleccionar el rango de fechas para mostrar los datos que consumen las aplicaciones.

Analizar mejor opción para manejar los eventos en el telefono. A considerar el trabajo realizado en la vesión previa.

Se debe guardar el fragment activo en caso de cambio de orientacion

ic_01_wifi.png
ic_02_mobile.png
ic_03_nowifi.png

deben ser actualizadas según https://romannurik.github.io/AndroidAssetStudio/icons-launcher.html#foreground.type=image&foreground.space.trim=0&foreground.space.pad=0.2&foreColor=607d8b%2C0&crop=0&backgroundShape=circle&backColor=f96a51%2C100&effects=shadow

20% padding, dont trim, circle, long shadow

Actualmente el control de la librería de monitoreo se hace a través de servicios clásicos de android. Existe la posibilidad de que dichos servicios sean manipulados o interrumpidos por el sistema operativo por lo que se debe investigar si la utilización de foregroundServices de android sería útil o no.

Se deben agregar al proyecto las distintas versiones de las imagenes usadas en las distintas resoluciones disponibles

Implementación de la vista "Tiempo Conectado" en su fragment

Se debe implementar una clase para el facil manejo de las visualizaciones de disco o torta que se usaban en la version anterior de la app movil

Esta contendrá los datos del dispositivo y métodos para obtener dicha información. La idea es usarla como un singleton y que se autocomplete al ser construida.