Saltar al contenido →

Reporting para apps iOS y macOS

Una parte importante de las aplicaciones empresariales es el reporting. A nuestros usuarios les encantan los dashboards, poder ver gráficos de barras, de tarta, apilados…

Y para ver como podemos añadirlos de una forma (no la única) fácil y sencilla vamos a desarrollar una app que muestre el estado del servicio BiciMad, las bicis gestionadas por el Ayuntamiento de Madrid.

El código fuente está disponible en este reporitorio de GitHub.

Además tendrás que registrarte en el portal Open Data de la EMT de Madrid para obtener las credenciales con las que consumir el API. El repositorio del framework BiciKit, incluido en el proyecto, contiene instrucciones sobre como hacer todo el proceso.

¿Y cómo lo hacemos?

Una cosa que todos los ecosistemas tienen en común es poner a disposición de los desarrolladores controles visuales que permiten mostrar contenido HTML.

Así que la solución pasa por diseñar las plantillas de los informes y/o gráficos con la ayuda de librerías HTML/CSS que luego empotraremos en nuestros interfaces de usuario.

¿Qué vamos a necesitar?

Lo primero conocimientos de HTML5 y CSS3. También vamos a necesitar algún editor para escribir las plantillas html de nuestros informes, y por último necesitamos una librería de gráficos que para este ejemplo será Charts.JS

Además usaremos FlexboxGrid, un sistema de rejilla responsive que nos ayudará a que el contenido de las páginas se visualize de forma correcta en todas las plataformas.

Plantillas, no páginas

Hay que pensar en que las páginas HTML van a ser en realidad plantillas donde insertaremos de forma dinámica el conteido necesario para generar los gráficos u otro tipo de contenido.

Y como todas las plantillas necesitamos poder indicar al programa donde debe insertar los valores para componer el gráfico, que en este caso será %@

¿Por qué %@? Porque es el comodín para la sustitución de valores en un String cuando lo construimos usando el inicializador init(format:argument:)

El parámetro format es el contenido de la plantilla y arguments, de tipo CVarArg, sería lo que queremos insertar, por orden, en cada uno de los %@ que contiene la cadena. Vamos a verlo en un ejemplo

En el caso de nuestras plantillas sería exactamente igual, lo primero que necesitamos es obtener el contenido de la plantilla.

Una vez que tenemos el String que representa al archivo se lo devolvemos a la función encargada de sustituir los comodines por valores reales.

Una vez que tenemos el String con el contenido de la página HTML tenemos que empezar a sustituir los marcadores de la plantilla por valores.

Más o menos sería algo como esto…

Cuidando el detalle. Tipografías

Incorporar gráficos está muy bien, pero a veces necesitaremos acompañarlos de texto para proporcionar aclaraciones o descripciones sobre lo que estamos mostrando.

Es importante continuar con la estética de la app para que no se note que hemos metido un “pegote” para insertar el gráfico y escoger la tipográfia adecuada es primordial.

Si la app usa una fuente en concreto no tendremos problema en incluirla en nuestro archico CSS pero y si queremos usar la fuente del sistema. ¿Qué hacemos entonces?

Que no cunda en pánico, el equipo de WebKit, el motor detrás de Safari, ha pensado en ello y nos da una manera de indicarle al CSS que use la fuente del sistema, aunque no sepamos cual es y es usar -apple-system

De esta manera cuando se vaya a cargar este estilo WKWebView le pedirá al sistema que le diga cual es la tipografía que debe usar.

Si vuestra plantilla se va a ver en otros sistema podéis usar…

De esta forma os aseguráis que la web usará la fuente de Mac, Windows, Ubuntu, iOS o Android.

Ahora sí, integrando los grafico en el UIViewController

Ya sabemos como escribir nuestras propias plantillas, como cargarlas y rellenarlas con nuestros datos. Ha llegado el momento de que el usuario las pueda ver.

Todo empieza en el storyboard de la app, donde añadiremos tantos controles WKWebView como plantillas HTML tengamos que mostrar en la vista del controlador.

Vamos a tomar como ejemplo el gráfico del nivel de ocupación de las estaciones que en la imagen de arriba es el gráfico dentro del rectángulo rojo.

Una vez que hemos obtenido los datos del API hacemos una llamada a la función encargada de manejar ese gráfico en concreto

La función presentOccupation hace la llamada al gestor de informes y carga el resultado en el WKWebView

El gestor de informes, la clase ReportEngine, se encarga de cargar la plantilla realizar las sustituciones pertinentes, devolviendo una página HTML válida que podamos mostrar a nuestro usuario

¿Por qué WKWebView y no SFSafariViewController?

La documentación de Apple es clara al respecto

If your app lets users view websites from anywhere on the Internet, use the SFSafariViewController class. If your app customizes, interacts with, or controls the display of web content, use the WKWebView class.

Nosotros vamos interactuar y controlar el contenido de la página que mostraremos al usuario, así que WKWebView es la opción correcta en este caso

Consejos finales

Si vas a desarrollar tu app sin salirte de su ecosistema no es difícil encontrar librerías que te ayudan a integrar los gráficos, pero si lo que te traes entre manos es un servicio que estará disponible en entornos Apple, Android, Windows y Web no puedes dejar que cada equipo escoja una librería.

Por consistencia del propio servicio y por el experiencia de usuario, la salida debe ser lo más parecida posible en todos los entornos, respetando las guías de diseño de cada plataforma, pero lo que no debería cambiar son los gráficos.

Enlaces de interés

Librerías HTML/CSS

Paletas de colores

Artículos sobre el uso de tipografías

Open Data – Ayuntamiento de Madrid

Publicado en Diseño iOS macOS Swift