No hay como recibir un JSON bonito para hacer las cosas fáciles al momento de usarlo, si usamos una API pública no hay mucho que hacer, pero si tienes poder para decidir cómo quieres que te lleguen los datos (O enviarlos si tu eres de backend), te recomiendo estos consejos que les ahorrarán dolores de cabeza a ti y a tu equipo.
- Usa siempre un JSON object como padre, aunque los datos sean una lista de objetos. Esto es porque con librerías como Volley o Retrofit que se usan en Android se complica más si recibes JSONArray en comparación con recibir JSONObject. Por ejemplo, supongamos que vas a recibir una lista de películas, en vez de recibir esto:
[
{
// Película 1
},
{
// Película 2
},
...
]
Te recomiendo hacer esto:
{
movie_list: [
{
// Película 1
},
{
// Película 2
},
...
]
}
2. Maneja un estándar al nombrar las variables del JSON: En lo personal prefiero snake_case pero en realidad no importa si usas camelCase o lo que sea mientras sea así siempre. Ejemplo:
No recomendable:
{
"first_name": "Ted", // Esta llave es snake_case
"lastName": "Mosby", // Esta llave es camelCase
"age": 30,
...
}
Recomendable:
{
"first_name": "Ted",
"last_name": "Mosby", // Ambas son snake_case
"age": 30,
...
}
Usa el mismo formato en TODOS los JSON que se usen en el proyecto y de preferencia en todos los proyectos de la empresa.
3. Evita los null: Los valores null son causantes del problema del millón de dólares (NullPointerException), es muy molesto, lleva mucho trabajo y es muy proclive a errores porque se tienen que estar validando todas las variables del JSON. Si es posible en vez de usar nulls para Strings usa un String vacío, para enteros o doubles puedes usar números negativos o flags booleanos como enabled.
No recomendable:
{
"first_name": null,
"lastName": "null",
"age": null,
...
}
Recomendable:
{
"first_name": "",
"last_name": "",
"age": 0,
"enabled": false,
...
}
4. Evita datos que no llegan en ciertas condiciones: Muy relacionado con el punto anterior, supongamos que tienes un dato para vehículos que es «load_capacity» pero solo se usa cuando el «vehicle_type»: «pickup», aunque este dato no se use para motocicletas debería siempre llegar una load_capacity aunque sea en 0, esto hace que el JSON sea más consistente y de nuevo evita que tengas que estar validando si el dato existe o no, en el peor de los casos muestras un dato erróneo pero la app no va a tronar (NOTA: hay algunas excepciones, por ejemplo si es una app bancaria es preferible que truene a mostrar una cantidad errónea).
No recomendable:
{
"vehicle_type": "motorcycle", // No hay load_capacity
...
}
Recomendable (Que siempre lleguen los datos aunque lleguen vacíos en vez de que a veces lleguen y a veces no):
{
"vehicle_type": "motorcycle", "load_capacity": 0,
...
}
5. Especialmente para móviles es preferible comerse una galleta grande que muchas pequeñas: Android por ejemplo enciende su antena para recibir datos cuando haces un request para traer datos de internet para ahorrar batería, una vez que el request termina la antena queda en modo de espera (Idle), es preferible traer todos los datos en un solo request aunque sea un JSON grande que estar haciendo muchas conexiones y encendiendo esta antena constantemente.
Aquí lamentablemente es cuestión de feeling, un ejemplo es una lista de restaurantes como en Uber Eats. Para ver el menú de los restaurantes la opción recomendable es que cuando entras a un restaurante descargas todo el menú del restaurante en un solo JSON (Galleta grande), así no tienes que hacer más requests. La opción que no recomiendo sería descargar cada sección del menú por separado (Galletas pequeñas) porque el usuario tiende a moverse constantemente entres secciones.
¿Estás de acuerdo con estos consejos? ¿Tienes algún otro que también hayas aprendido a golpes de la vida? Te invito a suscribirte y comentar.
Hackaprende 