En nuestra jornada en busca de verdaderamente hacer el cambio a Swift, vamos a usar como ejemplo algo muy común pero que conlleva una serie de sorprendentes dificultades. Por eso mismo es un excelente ejemplo.
Vamos a descargar un cutre json y lo vamos a transformar (siempre y cuando sea posible) en una serie de objetos de Swift.
El JSON de Satanás
El json que vamos a usar es una versión de uno que se utiliza en el Startup Engineering Bootcamp de Keepcoding (en el track mobile) para crear un lector de libros en PDF.
Aquí tenéis a esta joya: jsonFromHell.
Como podéis ver, se trata de un array de diccionarios json que representan a un libro. Aquí podéis ver un ejemplo:
{
"authors" : "Jeff Heard, Anand Rajaraman, Stefane Laborde",
"image_url" : "http://hackershelf.com/media/cache/06/df/06df282659657e529d8111e08aa79274.jpg",
"pdf_url" : "http://infolab.stanford.edu/~ullman/mmds/book.pdf",
"tags" : "data mining, text processing",
"title" : "Mining of Massive Datasets"
}Lo primero que vemos es la estructura del libro. Todo libro tendrá los siguientes componentes (que tendremos que replicar en nuestra clase Swift):
- autores
- url de la imagen
- url del pdf en sí
- tags o etiquetas
- título
Para que un libro sea correcto, ha de tener estos 5 elementos y todos ellos han de ser correctos a su vez.
¿Qué tiene de malo este JSON?
Muchas cosas. Empecemos por lo evidente y que tendría que haber sido resuelto por quien haya perpetrado el API que nos devuelve ese boñigo:
- ? namber guán: authors debería de ser un array de cadenas. En vez de eso, van y nos dan una cadenas separada por comas. Gracias, chato.
- ? namber chú: a tags le pasa más de lo mismo. ¿Por qué porras no es un array?
Podríamos ir al cubículo del desarrollador del backend y darle un ultimatum. Sin embargo, eso no siempre es una opción. Tal vez el API no lo hace tu empresa, lo hacen en otra ciudad o al susodicho simplemente le tiene sin cuidado. Moraleja, tendremos que “limpiar” ese input a nuestro programa.
Estos son los problemas que se podrían haber arreglado, pero ¿se te ocurren otros que no se pueden evitar en json?
Lo que no tiene arreglo
El primer problema con que nos vamos a encontrar es que JSON no tiene una estructura fija frente a la cual se pueda validar. No hay nada que defina un “libro correcto”, y nos podría llegar cualquier cosa.
Por ejemplo,
- nada impide que nos llegue un libro faltándole alguna propiedad
- podría llegarnos un libro con alguna de las propiedades vacías
- las urls podrán no serlo o ser incorrectas
- Podría llegarnos un diccionario vacío.
El problema está en que todo esto a json le tiene sin cuidado, mientras que a Swift estas cosas le sientan muy mal.
Es un poco como la clásica película de Walther Matthau y Jack Lemmon: La Extraña Pareja. Dos divorciados deciden compartir piso, sin embargo, mientras Jack Lemmon es un neurótico del orden y la puntualidad, Walther Matthau es un guarro, desordenado y chapucero. Las chispas no tardan en salir.
Si no tenemos control sobre el json que nos llega, solo nos queda aplicar el principio de máxima desconfianza y validar todos los datos que nos llegan de fuera.
Piensa mal y te quedarás corto
— Antiguo proverbio gallego
Es decir, antes de que llegue a Swift, tendremos que validar las chapuzas de json, para que a Swift no le dé un síncope.
También es cierto que podríamos haber usado otra cosa en vez de JSON, como puede ser Captain Proto, pero eso lo dejamos para otro artículo.
Manos a la obra: procesar JSON en Swift
En el próximo artículo haremos nuestro primer intento de procesar este JSON y crear objetos Swift a partir de él.
Lo más probable es que vayamos a crear un tipo Book que representa un libro. Posiblemente, también tendremos un tipo Library que represente a un conjunto de libros.
Piensa en cómo harías para procesar el JSON y donde lo harías. Podríamos tener un init en Library que acepta el array de diccionarios JSON y que para cada uno que se encuentra, llama al init de Book para ir creando libros individuales.
¿Es esta una buena opción? ¡Lo veremos en nuestro próximo y emocionante capítulo! 😉
Si tienes algo que deseas compartir o quieres formar parte de KeepCoding, escríbenos a [email protected].
