Desarrollo de aplicaciones móviles multiplataforma

Desarrollo de aplicaciones móviles multiplataforma

Hoy en día muchos de nuestros clientes necesitan soluciones para distintas plataformas móviles. El desarrollo nativo es complicado, sobre todo para equipos de desarrollo pequeños o presupuestos ajustados, ya que para cada plataforma debe utilizarse un entorno, lenguaje y herramientas distintos, aumentando así el tiempo de desarrollo y, por lo tanto, el coste.

Para estos casos donde los costes en tiempo o dinero son elevados e inasumibles para el cliente o el proveedor, una opción a tener en cuenta es el desarrollo de aplicaciones móviles multiplataforma.

Ventajas y inconvenientes del desarrollo de aplicaciones móviles multiplataforma

En primer lugar trataremos las ventajas del desarrollo multiplataforma frente al desarrollo nativo para, a continuación, comentar algunos inconvenientes de éste.

Las principales ventajas son:

  • Lenguaje, entorno y herramientas únicos para todas las plataformas.
  • Reutilización del mismo código para todas las plataformas (dependiendo del framework utilizado el porcentaje será mayor o menor).
  • Menor coste económico y reducción de tiempos de desarrollo.

Por otro lado los principales inconvenientes son:

  • Menor rendimiento de las aplicaciones (variará en función del framework elegido).
  • En algunos casos no podremos acceder a las APIs nativas. De nuevo depende del framework elegido.
  • Interfaces distintas, aumentando la fricción en su uso respecto a las nativas.

Frameworks

En el mercado hay distintos frameworks para el desarrollo de aplicaciones móviles multiplataforma, vamos a diferenciarlos entre dos tipos ya que su propósito y, sobre todo, sus resultados varían bastante.

Por un lado existen los frameworks basados en tecnologías web. Éstos utilizan HTML5, JavaScript, CSS3, etc. para desarrollar las aplicaciones. Además, nos proporcionan acceso a las APIs nativas de cada plataforma ya sea de forma nativa o mediante el uso de plugins.

Este tipo de frameworks suelen ser los más rápidos a la hora de desarrollar nuestras aplicaciones para varias plataformas. Sin embargo, también son las que peor rendimiento dan ya que no ejecutan código nativo y dependen del navegador web, además tendremos una interfaz genérica para todas las plataformas que no se adaptará a las particularidades de cada una de ellas. Algunos de los frameworks de este tipo son:

  • Apache Cordova
  • PhoneGap

Conviene comentar que hay muchos frameworks web como Ionic Framework o ExtJs que, para el acceso a las APIs y la generación de las aplicaciones para los marketplaces de las distintas plataformas, utilizan estos frameworks.

Por otro lado tenemos los frameworks pseudo-nativos. Estos frameworks implementan las distintas APIs de las plataformas en un solo lenguaje y generan código nativo para las distintas plataformas al compilarse.

Con estos, el desarrollo será muy cercano al desarrollo nativo y, por lo tanto, el coste en tiempo y dinero aumentará respecto a los frameworks basados en tecnologías web. Sin embargo, el coste será menor que en el desarrollo nativo ya que el lenguaje y entorno de programación será el mismo y un porcentaje del código generado será compartido. En cuanto al rendimiento, como os podéis imaginar, será muy parecido al de una aplicación nativa. Lo mismo ocurre con la interfaz: al utilizar las propias componentes de la plataforma es difícil, por no decir imposible, diferenciar entre las aplicaciones desarrolladas con estos frameworks y las aplicaciones nativas. Os dejamos sus principales exponentes:

  • Xamarin
  • J2ObjC
  • RoboVM
  • RubyMotion
  • Titanium

Conclusiones

Como podemos ver, el desarrollo de aplicaciones móviles multiplataforma no es perfecto, sin embargo, para presupuestos ajustados o equipos pequeños, es una opción a tener en cuenta.

Si lo más importante es el coste, los frameworks basados en tecnologías web nos darán buenos resultados para aplicaciones sencillas y su tiempo de desarrollo será bajo. De hecho, en algunos casos, la migración de una web existente a una aplicación móvil podría resultar sencilla y poco costosa utilizando alguno de estos frameworks.

Por otro lado, si buscamos un desarrollo muy cercano al nativo, tanto en rendimiento como en interfaz, los frameworks pseudo-nativos parecen más adecuados ya que obtenemos resultados muy buenos y una aplicación muy difícil de diferenciar de una nativa.

Coding computer

Desarrollo In-house vs. Outsourcing

A la hora de desarrollar el software que tu empresa necesita, ¿es mejor hacerlo internamente o bien confiar este trabajo a una empresa externa? No es una cuestión con una respuesta sencilla.

Deloitte’s Global Outsourcing Survey

Para empezar a debatir sobre este tema nos ha parecido muy interesante consultar los resultados obtenidos en la Deloitte’s 2016 Global Outsourcing Survey (en verano de 2018 publicarán su nueva versión, estaremos atentos para actualizaros esta entrada o crear una nueva).

Algunos puntos especialmente destacables:

  • El 78% de los encuestados está satisfecho con su relación de outsourcing.
  • El 72% de las tareas relacionadas con TI ya se está subcontratando. Es el área con mayor ratio de outsourcing dentro de las compañías.
  • Los principales motivos para subcontratar: reducción de costes, enfocarse en el negocio en sí y en alcanzar los objetivos de la empresa, resolver problemas temporales de capacidad.
  • Los principales problemas: proveedores poco proactivos o que no innovan suficientemente.
  • En su comparativa con los datos anteriores de 2014: las compañías encuentran menos problemas con los proveedores y la subcontratación crece en todas las áreas.

Outsourcing y Cloud Computing

Nos ha llamado también la atención que en esta encuesta se haya preguntado sobre cómo está afectando Cloud Computing (aquí nuestra última entrada sobre este tema) sobre las relaciones de subcontratación. El 61% considera que están disminuyendo los costes asociados a las entregas, el 45% que acelera los cambios, el 30% las implementaciones y el 21% que potencia la innovación.

Ventajas e inconvenientes

Cada una de las dos opciones presenta sus propias ventajas e inconvenientes.

Tener a tu propio departamento de desarrollo te asegura disponer de un equipo con un mayor conocimiento sobre el negocio, alineado con los objetivos finales de la empresa, entrenado justo para lo que se necesita. Problemas, quizás el principal sea el de conseguir contratar a los perfiles necesarios y todo lo que este proceso implica: costes del anuncio, dificultades para localizar al perfil requerido (donde además consumiremos muchísimo tiempo propio) y finalmente formarlo. Otro problema bastante importante: ¿cómo reaccionamos correctamente a los cambios de carga de trabajo?

Subcontratar los desarrollos a priori acaba abaratando costes, obviamente te permite enfocarte más en tu negocio y reaccionar mucho mejor a los subidas y bajadas de trabajo (ganas en flexibilidad). Inconvenientes: la pérdida del control directo, problemas en la comunicación con el proveedor (especialmente si hay una distancia considerable entre ambos, física o culturalmente por ejemplo), resultados inesperados si los requerimientos no están suficientemente cerrados, problemas con la priorización del proveedor (si dispone de muchos clientes de tu perfil).

Conclusiones

Como adelantábamos no es una pregunta con una conclusión clara.

Entendemos que la decisión dependerá en gran medida de la visión y estrategia de la propia empresa. Deberán sopesarse los pros y contras de cada opción. La clave si subcontratamos: acertar con los proveedores seleccionados.

¿Cloud va a ayudar a mejorar y aumentar los servicios de outsourcing? Estaremos atentos.

 

AWS Summit Madrid

El pasado 17 de mayo acudimos al AWS Summit 2018 Madrid donde pudimos disfrutar de la Keynote impartida por Werner Vogels (CTO de Amazon.com), Miguel Alava (Director de AWS EMEA) o Chema Alonso (CDO de Telefónica) entre otros, además de multitud de sesiones adicionales sobre cómo iniciarse en AWS, tecnología serverless o inteligencia artificial por ejemplo.

Tras una jornada más que atractiva, salimos de allí con algunas sensaciones interesantes.

Cloud está de moda

Cloud está pegando fuerte y parece que ha llegado para quedarse (al menos para los próximos años). Aparentemente las compañías más importantes del mundo, y las españolas cada vez más, están migrando ya sus desarrollos y productos a Cloud y, las que todavía no lo han hecho, o han iniciado el camino o deberían al menos planteárselo en breve.

Según la Cloud Comparison Guide (actualizada en 2018), AWS y Azure siguen a la cabeza en Cloud, dejando a mucha distancia a Google y todavía más al resto de compañías. De este estudio nos fijamos en otro detalle interesante: Cloud Computing aparece como la segunda tendencia tecnológica más importante para los los próximos 3 años, sólo por detrás de Big Data, pero por delante del Internet of Things, la inteligencia artificial, la realidad virtual o la robótica por ejemplo.

Tecnología serverless

De entre todos los servicios que ofrece Cloud, los relacionados con tecnología serverless están experimentando un auge total. 3 de las 5 sesiones que se impartieron en el pabellón principal del Summit (con varios cientos de oyentes en cada una de ellas) trataron sobre temas relacionados con esta tecnología.

Serverless ocupó incluso los últimos minutos de la conferencia de Werner Vogels, en los que enfatizó sobre sus bondades (mejora en la productividad de los programadores, eliminación de la gestión de infraestructura, foco en la lógica de negocio…) e incluso declaró que es el futuro de la programación. Todavía no disponemos de imágenes oficiales sobre el Summit de Madrid, pero sí sobre el de Londres (impartido una semana antes) y es interesante ver estos minutos finales  con su opinión sobre la evolución natural que deberían seguir los desarrollos desde Server (Virtual Machines), a Containers para llegar finalmente a Serverless.

Serverless application architectures on AWS
Serverless application architectures on AWS

Bases de datos

Nos parecieron interesantes también los servicios que ofrece AWS relacionados con bases de datos. En especial su nuevo producto Amazon Aurora que se ha convertido en el servicio AWS que más ha crecido en menor tiempo (en toda su historia). Parece que ofrecen también un servicio (AWS Database Migration Service) para migrar tus antiguas bases de datos a cualquiera de los servicios de datos que ofrece Amazon. Un asistente migra automáticamente todo lo posible y sugiere soluciones guiadas para aquellos pasos que no se consiguen completar 100% automáticamente (básicamente los relacionados con PL/SQL). Habrá que probarlo…

¿Conclusiones?

Que cloud está en auge e irá todavía a más. Y, definitivamente, volvimos con la motivación de seguir trabajando e investigando sobre esta tecnología.

Edición 25/06/2018

Vemos que AWS ya ha publicado en su canal de Youtube los vídeos oficiales sobre el Summit. Aquí el Keynote. Hay otros vídeos interesantes del evento en su canal. Por ejemplo Mejores prácticas y patrones de arquitectura en Serverless o Primeros pasos en AWS.

imagen patrones

Patrones de diseño

A veces, en nuestro día a día, nos enfrentamos a problemas que ya han sido resueltos por otros desarrolladores, por este motivo hoy vamos a hablar un poco sobre los patrones de diseño ya que estos nos ayudarán a solucionar problemas comunes de la mejor forma posible. ¡Vamos a ello!

¿Qué son los patrones de diseño?

Un patrón de diseño es una solución general y reutilizable para problemas típicos y recurrentes en el desarrollo de software. Éstos, dado un contexto similar, nos aportan una solución ya probada y documentada.

El concepto de patrón de diseño se empezó a utilizar a finales de los 70 por el arquitecto Christopher Alexander, aún así, no fue hasta principios de los 90 cuando los patrones de diseño se popularizaron gracias al libro Design Patterns escrito por el grupo Gang of Four (GoF) compuesto por Erich Gamma, Richard Helm, Ralph Johnson y John Vlisides, en el que se recogían 23 patrones de diseño comunes.

Ahora que sabemos un poco qué son los patrones de diseño y de dónde salen vamos a lo que nos interesa, ¿por qué deberíamos utilizarlos?

¿Por qué son útiles los patrones de diseño?

Los patrones de diseño nos ayudan a desarrollar aplicaciones más robustas y mantenibles. Esto es debido a que establece un lenguaje común entre el equipo de desarrollo, los patrones de diseño están ampliamente documentados y testados y ayudarán a todo el equipo a comprender lo que has implementado, cómo y por qué. Además los patrones son reutilizables ya que se amoldan a distintos problemas (con un contexto similar).

Debido a estos motivos, los patrones nos ahorrarán tiempo al tener el código bien estructurado permitiendo a cualquier desarrollador, incluso a los nuevos desarrolladores, realizar cambios sobre nuestra implementación sin tener que romperse la cabeza en el proceso.

Como hemos dicho anteriormente, utilizar patrones también nos asegurará la validez de nuestro código (si hemos utilizado el patrón adecuado para el problema) ya que los patrones de diseño son estructuras probadas por millones de desarrolladores durante muchos años.

Tipos de patrones de diseño

En la actualidad existen muchos patrones de diseño, por este motivo suelen agruparse según su propósito: patrones creacionales, patrones estructurales y patrones de comportamiento. Vamos a ver un poco en detalle para que se utilizan cada uno de estos tipos y algunos ejemplos de cada uno (vamos a explicar algunos de ellos brevemente).

Patrones creacionales

Los patrones creacionales sirven para solucionar problemas derivados de la creación de nuevos objetos. Estos patrones nos ayudan a encapsular y abstraer dicha creación. Los patrones creacionales más conocidos son los siguientes:

  • Abstract Factory
  • Factory Method
  • Builder
  • Singleton: Garantiza la existencia de una única instancia para una clase y la creación de un mecanismo de acceso global a dicha instancia. Solo puede instanciarse la clase a un único objeto.
  • Prototype: Crea una nueva instancia clonando un objeto ya existente.
  • Lazy initialization: Instancia el objeto solo cuando vamos a utilizarlo.

Patrones estructurales

Son patrones que nos ayudan a modelar nuestra aplicación especificando la forma en la que unas clases se relacionan con otras. Algunos de los patrones estructurales son los siguientes:

  • Adapter o Wrapper: Permite a dos clases con diferentes interfaces comunicarse entre ellas utilizando un objeto intermedio.
  • Bridge: Desacopla una abstracción de su implementación.
  • Composite
  • Decorator: Permite añadir funcionalidad extra a un objeto (de forma dinámica o estática).
  • Facade: Una facade (o fachada) es un objeto que crea una interfaz simplificada para tratar con otra parte del código más compleja, de tal forma que simplifica y aísla su uso. Por ejemplo podríamos utilizar una facade para acceder a la funcionalidad de un sistema externo.
  • Flyweight
  • Proxy
  • Módulo: Agrupa varios elementos relacionados en una entidad única.

Patrones de comportamiento

Para terminar tenemos los patrones de comportamiento, estos se encargan de gestionar los algoritmos encapsulados por las clases y las relaciones y responsabilidades entre objetos. Tenemos los siguiente patrones:

  • Chain of responsibility: Establece la línea de mensajes a seguir para realizar la tarea indicada.
  • Command: Son objetos que encapsulan una acción, permitiendo ejecutar dicha operación sin necesidad de conocer el contenido de la misma.
  • Interpreter
  • Iterator: Nos permite recorrer un conjunto de forma secuencial sin necesidad de conocer su implementación.
  • Mediator: Objeto encargado de coordinar la comunicación entre objetos de distintas clases.
  • Memento: Este patrón permite volver a estados anteriores del sistema.
  • Observer: Define una relación uno a muchos entre objetos y, cuando este es modificado, notifica a todos los objetos que dependen de él para realizar una acción determinada.
  • State: Permite la modificación de su comportamiento en función de un estado interno.
  • Strategy: Dispone de varias soluciones para un problema y decide cual de ellas es mejor en tiempo de ejecución.
  • Template Method: Define el esqueleto de un algoritmo, permitiendo a las subclases definir cómo implementan algunas partes.
  • Visitor

Conclusión

Como veis existen muchos patrones (y faltan bastantes en esta lista) que nos dan solución a una serie de problemas comunes, aunque es complicado conocerlos y entenderlos todos, es útil conocer su existencia y revisarlos cuando nos enfrentamos a algún tipo de problema para ver si algún patrón de diseño existente se amolda a nuestro problema. Como podéis imaginar, la máxima dificultad radica en identificar cuándo debemos utilizar uno de ellos, algo que la práctica nos ayudará a conseguir.

Aún así vale la pena esforzarse en utilizarlos ya que las ventajas al hacerlo son muchas como ya hemos explicado anteriormente. Eso si, cuidado al utilizar patrones de forma indiscriminada, utilizar patrones donde no toca puede ser igual de malo (o incluso peor) que la falta de ellos.