Tutorial Retrofit En Android: Planificación Aplicación Médica

¿Qué es Refrofit?

De forma concreta:

Una librería de Square para Android y Java que actúa como cliente HTTP.

Partiendo de ello… ¿debería interesarte leer este artículo?

Si andas buscando un mecanismo fácil para comunicar tu app Android con un servicio REST, entonces sí.

Te sorprenderás la simplificación de código que esta herramienta te proporcionará.

Para que te hagas una mejor idea, esta librería es otra alternativa de HttpUrlConnection y Volley.

Así que si vas a consumir una API REST, sigue leyendo…

Las Características De Retrofit

Si ya revisaste la web de Retrofit, habrás visto una introducción rápida de sus beneficios como cliente HTTP.

¿Qué funcionalidades nos facilita?

• Aísla el manejador de peticiones en una interfaz
• Usa anotaciones para definir los componentes de la API (verbo, parámetros, cuerpo, cabeceras, etc.)
• Nos permite enviar las peticiones de manera asíncrona
• Es capaz de integrar múltiples conversores para JSON y XML como Gson y Simple XML.

¿Genial, cierto?

¡Claro!

Ahora, fíjate a que ejemplo aplicaremos esta herramienta.

Aplicación Android SaludMock

SaludMock es una solución para las entidades promotoras de salud que desean asignar citas de medicina general a sus pacientes, dependiendo de la disponibilidad de sus médicos.

Su objetivo es reducir las largas filas de afiliados y alivianar el trabajo de las operadores del callcenter.

¿Es esta app suficiente para probar Retrofit?

¡Claro!

La idea es crear un servicio web REST con PHP, MySQL y JSON con el fin de guardar los datos para médicos, afiliados, centros médicos y las citas.

Lo que permite usar la librería como cliente HTTP.

¿Qué requerimientos tendrá?

Bien sabes que presentar un proyecto completo  es difícil.

Sin embargo intentaré cubrir con detalle todas las tareas que se asocien al uso de peticiones web al servicio.

Específicamente serán:

• Login de afiliados con No. de documento y contraseña
• Consulta de citas médicas (más filtro por estado)
• Asignación de citas un día específico (incluye la elección de los doctores )
• Radicación de PQRS (Peticiones, Quejas, Reclamos y Sugerencias)

Si lo deseas, puedes incorporar muchas más características como:

• Impresión de certificados,
• Consulta de estado de grupo familiar,
• Solicitud de aprobaciones,
• Consulta de resultados de exámenes médicos,
• Más…

¿Qué datos se guardarán?

En el estado actual que he contemplado del problema tendremos las siguientes entidades:

• Usuarios
• Afiliados/Pacientes
• Doctores/Médicos/Profesionales De Salud
• Centros Médicos
• Problema (refiriéndome a PQRS)

Las relaciones, restricciones y dominio dependen del contexto que le vayas a dar.

Por mi parte el modelo quedará establecido como muestro en el siguiente diagrama entidad-relación:

Donde:

• medical_center: Son los centros médicos para la atención
• doctor: Representan los médicos disponibles
• affiliate: Es la entidad para los afiliados
• appointment: Son las citas generadas entre pacientes y doctores
• issue: Son los PQRSs que generan los afiliados

Bocetos De La Aplicación

Entremos en la dinámica que tendrá…

Screen de Login

¿Qué puntos de interacción tenemos?

1. Dos campos de texto (no. de documento identidad y contraseña)
2. El botón de iniciar sesión

Ahora, ¿qué reacciones de UI se producen?

1. La edición de texto con mal formato muestra un error
2. Si los datos son correctos y hay conexión, se navega a la screen de citas médicas. De lo contrario se muestra un error.

Screen Citas Médicas

De allí tendremos varios puntos de interacción.

1. Spinner en la Toolbar para filtrar
2. Menú con desborde (tres puntos verticales) para mostrar la opción de Radicación de PQRS
3. Lista con las citas médicas del usuario diseñadas en cards
4. Floating Action Button para solicitar citas

El diseño de los ítems de lista vendría así

Donde:

1. Un botón de cancelar sobre las citas médicas activas.

Además tendremos los siguientes estados de UI:

La interacción del spinner en la action bar nos muestra las opciones de filtro.

Como te decía, el menú mostrará la opción de los radicados.

Habrá un empty state en caso de no existir citas aún.

Además mostraremos un Toast cuando se asigne una nueva cita.

Y el estado de carga de datos.

Screen Asignar Citas

Los puntos de interacción son:

1. Spinner para la elección de centro médico
2. Texto para el cambio de la fecha
3. Spinner para elección de la jornada del día
4. Botón para buscar los doctores disponibles con los parámetros

Al interactuar con cada punto, espero qué:

1. Se desplieguen la lista de centros médicos disponibles
2. Se abra un diálogo para cambiar elegir la fecha
3. Se despliegue un menú para elegir las jornadas (mañana, tarde)
4. Se lance la screen para selección de doctores

Screen Elige Tu Doctor

Este wireframe permite interacción así:

1. El botón Up en la Toolbar
2. Una lista de cards con la información y disponibilidad del doctor
3. Un view de selección única para elegir entre horarios
4. Un botón SOLICITAR de confirmación de solicitud del horario

Cuando el usuario interactúa con los elementos, las acciones arraigadas serán:

1. Al presionarlo, se retorna a la screen de «Asignar cita»
2. Al deslizar, hay scrolling de los doctores disponibles para el día elegido
3. Al presionar, se cambia entre horas disponibles
4. Al presionar, se confirma la asignación de cita y se retorna a la screen de «Citas Médicas»

Screen Radicar PQRS

Veamos sus puntos de interacción:

1. Botón Up
2. Spinner con categorías del PQR
3. Campo de texto para describir los sucesos
4. Imagen para la toma de fotos

Ahora, pensemos en sus reacciones:

1. Al presionar, se regresa a la screen «Citas Médicas»
2. Al presionar, se despliegan las opciones de la solicitud
3. Al editar, se cuentan los caracteres hasta 5000.
4. Al presionar, se abre la app de la Cámara para tomar foto. Al confirmar, se pone miniatura de la imagen como registro de toma.

Fuentes De Datos Y Sincronización

He aquí otro punto importante.

El cómo vamos a administrar la información.

¿En dónde piensas que se guardarán las citas médicas?

Si has pensado en un servidor, ¡es correcto!

La app SaludMock estará supeditada a una base de datos remota.

Cada lectura y operación de datos será enviada de inmediato hacia la aplicación servidor.

Lo que quiere decir, que si no hay conexión, la aplicación pierde su capacidad de registrar citas.

Es necesario que exista una conexión.

Herramientas Y Recursos

Por último…

Las soluciones para soportar nuestro desarrollo.

La siguiente es una lista de los recursos a usar:

• Hosting: Localhost. Haremos pruebas locales que nos faciliten la implementación del servicio web.
• Lenguaje: PHP para la API y Java para Android.
• Base de datos remota: MySQL
• Formato de intercambio de datos: JSON
• Carga asíncrona de imágenes: Librería Glide
• Tarjetas y listas: CardView y RecyclerView
• Peticiones HTTP: Retrofit

Habiendo estudiado todo lo anterior, ya tenemos una base clara sobre lo que trabajaremos.

Dividiré el trabajo en varias partes.

• Segunda: Login
• Tercera: Consulta citas médicas
• Cuarta: Asignación citas
• Quinta: Radicación de PQRS

Finalmente…

¿Qué te parece este planteamiento?

¿Tienes un proyecto similar?

Anímate a contarme si esta idea que vamos a desarrollar puede serte de utilidad.

Solo comenta abajo en la caja de Disquss y déjame saber qué piensas 🙂

(Si tienes una recomendación o corrección, bienvenidas sean)

Otro Ejemplo Con Retrofit En Android

Si quieres estudiar en paralelo otro tutorial donde uso Retrofit. Mira:

Hace unos días lancé un tutorial detallado para crear un servicio web REST para productos, clientes y pedidos. Donde consumo sus recursos desde una aplicación llamada App Productos. Échale un vistazo a todo lo que incluye (tutorial PDF, código completo en Android Studio, código completo PHP, script MySQL con 100 productos de ejemplo).