¡No te asustes!, en este post no te pretendo hablar de lenguajes de programación. Tan sólo quiero que sepas los conceptos básicos con los que te vas a encontrar si por fin te has decidido a probar suerte en el mundo de las APPs.
Sé que es complicado enseñarte algo nuevo a tí, que te separas de tu móvil sólo cuando tu tablet está cerca y es que cada día la sociedad es más tecnóloga. Hace apenas unos años palabras como “streaming” tan sólo estaban al alcance de especímenes raros, forofos de alguna saga o estudiantes de ingenierías recluidos en algún sótano. Hoy día no sólo conocemos qué significa “streaming” sino que dominamos conceptos como “a tiempo real”, “SEO”, “Interfaz de usuario”, …

No obstante, si estás pensando en contratar el desarrollo de una APP móvil ya sea como complemento de tu empresa o como una nueva idea de negocio te encontrarás con nuevos vocablos y conceptos que hasta ahora seguramente desconocías y que te vendrá muy bien conocer sobre todo porque muchos de ellos afectan a la envergadura, modelo de negocio y tiempos de desarrollo de tu futura APP.

Obviamente no es mi intención ver todos los conceptos con los que te encontrarás en este post, pero si los más relevantes en cuanto a estructura general de tu APP, de tecnología mobile y referentes a markets.

Estructura

Comenzamos por el principio, si nos adentramos en la contratación de una APP debemos plantearnos su estructura al menos en rasgos generales. Al fin y al cabo, es esta la que en gran medida va a determinar cuán compleja de implementar será nuestra APP.

• APPs Nativas, Híbridas o WebAPPs: Este concepto tiene amplia literatura en internet e incluso lo puedes ver en la sección mobile de la web de intelligenia. Es importante que al menos conozcas las diferencias puesto que afecta directamente al presupuesto, tiempo de implementación y acabado de la APP. A modo de resumen y sin querer extenderme en este concepto más de lo debido:

• App Nativa: Se crea con los lenguajes de programación propios de cada plataforma, en iOS es objetiveC o swift, en Android de momento es java. Tu APP será más fluida y versátil, sin embargo, requiere 2 desarrollos diferentes (con su presupuesto y tiempo) si quieres salir en el App Store de Apple y en Google Play de Android.
• App Híbrida: Se crea con lenguajes webs tales como HTML5, javascript, CSS3 y emulan de una manera muy cercana el comportamiento de APPs nativas. Tan sólo requiere un desarrollo común.
• WebApps: Podríamos decir que es una APP que se abre desde el navegador, por lo que no es una APP como tal (no puede subirse a ningún market) aunque si se comporta como estas.

Insisto, si queréis profundizar en las ventajas e inconvenientes de las 2 primeras os animo a ver el análisis más detallado que hicimos hace unos meses en la propia sección mobile la web de intelligenia.

• Conexión con servidor: La mayoría de las APPs no tienen toda la información autocontenida en el mismo dispositivo, sino que necesitan actualizar su información de manera continua. Esta información generalmente vendrá de un sitio web o de una intranet que la aloje y la actualice. Por ejemplo, si tu app es un periódico digital se conectará a la web de tu periódico y de ahí extraerá todas las noticias, de esta manera tus redactores sólo editarán las noticias en un único lugar o si tu app es chat entonces necesitará tanto obtener mensajes como emitirlos quedando todos ellos registrados en un servidor principal. Por tanto, cuando hablamos de conexión con backend hablamos de que la APP necesita conectarse a un servidor del que obtener o alojar datos. Existen muchos tipos de comunicaciones entre APPs y servidores dependiendo de las necesidades:

• Servicio existente: Si tu APP complementa algún producto o servicio de tu empresa, lo más seguro es que quieras que la información salga de tu propia web. Para ello necesitarás una API de comunicación ¿Y qué es eso? Sin duda otro bonito concepto, que define la comunicación entre ambos módulos. Que un servicio tenga una API implica que existe un protocolo de llamadas que respetándolo será posible comunicarse.
• Servicios de terceros: Puede darse que la conexión sea con servicios ya creados. Un ejemplo claro es facebook o twitter que contemplan una API para poder conectarse de una manera sencilla y extraer los datos necesarios.
• Panel de gestión completo: Imaginemos que quieres hacer una APP con catálogo de productos. Obviamente, tu catálogo cambiará cada cierto tiempo por lo que tendrás que tener un panel web donde actualizar precios, fotos, … Y obviamente ese catálogo no podrá ser administrado por todo el mundo por lo que necesitarás una web con login, intranet, para gestionar tu catálogo.
• Sólo base de datos:  En este caso no es necesario que exista una web ni pública ni privada para gestionar los datos, con almacenarlos es suficiente. A modo de ejemplo, imaginemos que nuestra APP es un recetario. Obviamente no es necesario que exista una versión web del conjunto de recetas ni que exista un administrador para gestionar las recetas que sube cada usuario, sin embargo, es necesario que exista un servidor para registrar todas las recetas, datos de usuario, etc. Esta opción es más simple que la anterior puesto que la lógica reside fundamentalmente en la APP y el servidor tan sólo almacena información. Además existen multitud de opciones en el mercado que abstraen al desarrollador de la contratación y configuración de hosting como son firebase, heroku, mongolab y el ya casi desaparecido parse.

• Persistencia: La persistencia no es más que el almacenamiento de datos en el propio dispositivo. De forma simple, si tu aplicación puede seguir funcionando aún sin conexión internet, entonces tiene persistencia de datos. Por ejemplo, Whatsapp guarda todas tu conversaciones en el dispositivo, de forma que si estás offline podrás seguir viendo tus mensajes e imágenes aunque, eso sí, no recibirás nuevas.

Tecnologías Mobile

Obviamente no basta con saber las líneas generales de nuestro proyecto. También debemos tener en cuenta qué tipos de tecnologías de esta nueva era va a usar nuestra APP. Cada día surgen más conceptos y más tipos de tecnologías, si quieres profundizar en las más comunes puedes visitar la sección mobile de nuestra web, donde se detallan. A continuación te explicaremos las más relevantes.

• Push Notification: Es sin duda la característica más demandada en la creación de aplicaciones. No son más que las alertas tipo Whatsapp que puedes recibir en tu móvil y que mejoran sobremanera la interacción con tu aplicación, sin embargo, son un arma de doble filo, si envías más push de la cuenta corres el riesgo de resultar intrusivo y que directamente desinslaten tu APP.

• Material Design: Más que concepto Material Design es una filosofía. Creado e impulsado por Google, se fijó como estándar del diseño de APPs hace ya más de un año. Sin duda muchas de las aplicaciones que abres a lo largo del día si usas Android usan Material Design. 

• Wearables: Son dispositivos electrónicos que se llevan como parte de nuestro vestuario haciendo las veces de alguna prenda como puede ser reloj o gafas o como parte de otras. Seguramente lo conozcas más por los smartwatches tan de moda estas navidades que no sino otro wearable más. También existen pulseras, gafas o incluso camisetas que analizan todas tus constantes vitales mientras haces deporte para tener todo el control posible de tu actividad física. Muestra de ello es The PoloTech Shirt de Ralph Lauren.

De contexto

Una vez conocemos los conceptos que conforman tanto la estructura como los componentes de nuestra APP tan sólo nos quedan por saber 2 más, que surgirán a lo largo del desarrollo.

• Políticas de revisión de Apple: Cuando ya está todo el desarrollo completo, vemos nuestra APP funcionar correctamente en los dispositivos de pruebas y creemos que falta muy poquito para subirla al APP Store y lanzarla por fin, nos chocamos con la cruda realidad de Apple: Revisan todas y cada una de las APPs que se suben manualmente, si, has leído bien, manualmente, con lo que nuestra APP se puede retrasar 2 semanas o incluso más si algo no les cuadra. ¿Pero por qué semejante gasto en personal y tiempo? En mi opinión no es algo raro para Apple puesto que siempre ha controlado todos los aspectos de sus productos, tanto hardware como software, no es de extrañar que también quiera controlar lo máximo posible el software de desarrolladores. Por contra, Google sube las Apps en apenas unas horas y deja la revisión al gran público. Esta estrategia hace que Google Play tenga mucha más variedad de aplicaciones, buenas y malas, pero gran variedad.

En resumen, Google enamora a sus desarrolladores a costa de sus usuarios y Apple enamora a sus usuarios a costa de sus desarrolladores. 

• Pago por descarga o In-APP Purchase: Estos dos conceptos aluden directamente al modelo de negocio. Obviamente, no es mi objetivo adentrarme en algo tan amplio por lo que me voy a limitar a comentar que generalmente existen 2 tipos de monetización en los diferentes markets: O bien pago directo por la descarga de la aplicación, que se establece de forma única y del cual tanto Apple como Google Play se llevan el 30% de comisión o bien Pago In-APP que sucede dentro de la misma y del cual también se establece el 30% de comisión a no ser que la transacción sea por un servicio o producto real.

Espero que tengas las cosas algo más claras, sin duda te encontrarás muchas más palabras y conceptos en el desarrollo de hacia la APP de tu empresa.

¡Si quieres que te echemos una mano, tan sólo tienes que pedirlo!