Mostrar más resultados
28106

Desarrollo de aplicaciones móviles: trabajar con datos

Desarrollo de aplicaciones móviles: trabajar con datos

Escrito por Albert Miró

Si queremos construir una aplicación que esté relacionada con la interacción del usuario, para guardar fechas o actividad suya, definitivamente debemos entender las formas de usar los datos que tenemos a nuestra disposición. Existen dos tipos, que debemos saber cuando usarlos en función de nuestros objetivos. Estos dos tipos son cuando los datos vienen alimentados por la propia aplicación, o datos locales, y los que vienen desde el servidor, o datos remotos. Vamos a ver en qué se diferencian y qué tecnologías se suele usar en cada momento.

El papel de los datos en el desarrollo de aplicaciones móviles

Como he comentado en la entradilla, tenemos dos posibles maneras de tratar los datos: de manera local o de manera remota. Antes de entrar en sus diferencias me gustaría observar las similitudes. Debéis tener en cuenta que en ambos casos dependemos de una base de datos. Eso significa que, mirando la estructura, lo que aprendamos en un lado lo podremos aprovechar en el otro. Esto es gracias a que, por lo general, el lenguaje usado es SQL, un estándar dedicado a servir bases de datos. Pese a que existen las bases de datos NoSQL, no voy a hablar de ellas hoy. Lo que si sabemos es que existe SQLite, la versión reducida y de peso ligero (lite) de SQL. Su objetivo es poder otorgar la potencia de su hermano mayor a los sistemas operativos móviles sin ganar peso, pero sin cambiar el idioma de las instrucciones, porqué, si, esto no es Microsoft Acces, por lo que se han acabado el arrastrar tablas y nombres de un lado a otro en una interfaz gráfica. Somos programadores, ¿verdad? Sabiendo esto no es un disparate pensar que merece la pena aprender a realizar instrucciones sencillas en SQL, de hecho es uno de los aspectos que enseño en el curos de Appcelerator, al final del tema 7, y parte del temario del proyecto final. Es decir, es importante. Pero no estoy hablando de un trabajo pesado y duro de base de datos, recordemos que se supone que debe ser todo muy ligero para que la app no crezca en tamaño y hayan problemas con las instalaciones en terminales ajustados de memoria. En todo el tiempo que llevo en el desarrollo de aplicaciones, que no es poco, nunca he tenido que hacer tareas muy serias con consultas, y eso que en mi formación académica se pusieron muy duros con ello. De modo que no le tengáis miedo.

Pero, ¿y las diferencias?

Aquí entra lo “divertido”. Para poder recuperar datos del servidor, o mandarlos y que se guarden, primero debemos entender que es GET y POST, dos metodologías de tratar los datos que existen en el lenguaje PHP. No me alargaré especialmente, pero resumiendo, si cogemos las palabras del inglés, GET nos sirve para poder recuperar datos mediante la url, mandando ciertos valores que nosotros necesitemos, y POST es el usado para escribir en la base de datos. Esto se usa haciendo una conexión HTTP, que es el protocolo web usado para mandar y recibir peticiones de un servidor, en la cual, a nivel de programación, nosotros determinaremos cómo y qué datos deseamos recibir. Pero pese a eso, el modo de recuperarlos es gracias a una cadena de texto, codificada en un estándar Javascript, llamado JSON, o JavaScript Object Notation. JSON es, básicamente, vuestro gran aliado a la hora de mandar y recibir datos en un teléfono, ya que, como he comentado, es una cadena de texto por lo que su peso es tan ligero que no afecta ni siquiera al consumo de datos móviles contratados con vuestra compañía. Tal es la cosa que un día tuve recuperando la misma cadena durante horas usando mis datos de Yoigo, y al final de la jornada únicamente había gastado 100k. Eso es una cantidad ridícula, tanto por consumo, almacenaje, uso, etc. La virtud de JSON es que se comporta como un vector de datos (Array), un concepto de programación que si no conocéis os animo a investigar sobre él porqué son increíblemente útiles, por lo que acceder a cada sección es sencillo. Gracias a esto nosotros podemos determinar de antemano cómo vienen estructurados dichos datos para posteriormente ejecutar las consultas de base de datos y guardarlo en local. ¿Por qué en local si lo tenemos disponible en remoto? Buena pregunta: la idea es que nosotros sólo accedemos al servidor para asegurarnos de que no hay ningún cambio en los datos que debamos atender, y una vez asegurarnos de tal cosa, lo guardamos en local y ya no necesitamos descargarlo de nuevo. Con esto ganamos tiempo de ejecución, reducimos el consumo y optimizamos la aplicación para que su fluidez no se vea afectada.

Y esto ha sido un resumen muy breve de las dos maneras más comunes de aceptar datos en una aplicación móvil. Más adelante intentaremos profundizar en ello ya que es un tema muy extenso y se puede poner realmente complejo.

Curso relacionado: Curso de Desarrollo de Aplicaciones para Móviles