Google Flutter

Artículo

Destripando Google Flutter

El framework del gigante tecnológico quiere ser el MVP dentro de los entornos de trabajo de desarrollo multiplataforma

Como nuevo jugador en la cancha, el framework de Google intenta posicionarse como un elemento diferenciador entre sus competidores. ¡Analizamos todos sus entresijos!

Hace unos días os traíamos un artículo en el que hablábamos de Flutter, el nuevo framework de Google para crear aplicaciones. Concretamente nos centramos en las características principales del framework y en sus competidores.

Ahora queremos desgranar con detalle el funcionamiento de Flutter, un framework que quiere liderar el mercado en un futuro no muy lejano. Analizamos su estructura, cómo está siendo adoptado en el mercado y los PROs y CONs que hemos detectado.

En conversaciones con amigos que no están relacionados con el sector, muchas veces nos encontramos con frases de este estilo:

- "No entiendo por qué la aplicación XXX es diferente en Android y en iOS".

- "Toda mi vida con un iPhone y ahora que tengo un Android no me adapto a las aplicaciones".

- "Hace meses que la aplicación XXX se actualizó en iOS proporcionando una nueva funcionalidad, pero en Android aun no".

Todas ellas tienen el mismo origen: distintas plataformas, distintos equipos de desarrollo, distintos plazos de puesta en producción, distintos problemas que resolver, etc. Como bálsamo a esta situación, aparece el concepto de desarrollo multiplataforma que pretende minimizar todos estos problemas, entre otros.

Google Flutter

Visión general de estructura de Flutter

En definitiva, todo en Flutter es un "widget". Para Google un widget de Flutter es "el componente básico de una aplicación. Cada widget es una declaración inmutable de parte de la interfaz de usuario. A diferencia de otros frameworks que separan vistas, controladores de vista, diseños y otras propiedades, Flutter tiene un modelo de objeto unificado y consistente: el widget".

Los widgets forman una jerarquía basada en la composición. Cada widget se anida dentro y hereda las propiedades de su padre.

Puede responder a eventos, como la interacción del usuario, indicando al framework que reemplace un widget en la jerarquía con otro widget. Luego, el framework compara los widgets nuevos y antiguos y actualiza de manera eficiente la interfaz de usuario.

Los widgets pueden ser de dos tipos diferentes (cada uno de ellos hereda de un "padre" diferente):

  • Stateful: durante la vida del widget, la información que contiene (o muestra), las interacciones que permite (o genera) hacen que una "fotografía" en el tiempo muestre conjuntos de información y capacidades diferentes del widget. Cada una de esas "fotografías" son un estado del widget. Ejemplos de widgets stateful (más a allá de que nuestra aplicación sea un "widget") podrían ser un checkbox, un slider, etc.
  • Stateless: estos widgets no cambian su estado en el tiempo. La información que necesiten para su operación se les proporciona en su inicialización y, durante su vida, no van a mutar. Esto no significa que no se pueda interactuar con él. Un ejemplo de widget stateless podría ser un botón que siempre opere del mismo modo, un menú o un icono.

El framework de Flutter se organiza en capas y cada una de esas capas se
construye sobre la capa anterior:


Deloitte

Hay que tener en cuenta que las capas superiores del framework son las más usadas. Lo natural es usar un componente de la capa Material o Cupertino (y ya cada componente se basa en lo que necesite para proporcionar una funcionalidad completa).

Aunque el framework provee un conjunto muy nutrido de componentes, también es posible crear componentes custom que logren cumplir los requisitos deseados.

Para favorecer el uso de Flutter, Google ha preparado el framework para que genere aplicaciones completas o módulos que puedan ser incluidos dentro de aplicaciones nativas. Expliquemos esto último: Imaginemos que tenemos una aplicación bastante completa y compleja. Esta situación de base condicionará de manera negativa el decantarse por frameworks de desarrollo nuevos. Siempre se buscará un framework consolidado y con casos de éxito conocidos. Google, conocedores de esta situación, han capacitado el framework para generar módulos que puedan ser invocados desde aplicaciones nativas. Esto es, supongamos que tenemos una aplicación que tiene múltiples funcionalidades implementadas en Android y queremos ampliar dichas funcionalidades ofreciendo una nueva. Esta nueva funcionalidad puede ser implementada en Flutter e invocada desde la aplicación nativa Android.

De este modo, podemos ir incorporando nuevas funcionalidades a nuestras aplicaciones nativas sin tener que embarcarnos en un macro proyecto, disminuyendo el riesgo y aprovechándonos de todo el potencial de este nuevo framework.

Para favorecer la integración, el framework de Flutter también ofrece la posibilidad de consumir librerías generadas en Kotlin y Swift. La reutilización de código está asegurada con esta posibilidad que ofrece el framework.

Flutter

Referencias de uso

Aunque la primera versión oficial de Flutter sólo lleva liberada cuatro meses, ya hay
compañías que se han lanzado generando productos basados en Flutter:


Google Ads
imagen Flutter 1
Hamilton: El musical
imagen Flutter 2
Hooker
imagen Flutter 3
Grey Music Player
imagen Flutter 4
Alibaba
imagen Flutter 5

Flutter: pros y contras

PROs VS CONs

No todo va a ser color de rosa. Flutter tiene sus pros y sus contras que
comentamos a continuación:

PROs

CONs

Hot Reload (aunque no todos los cambios son soportados).

Salió de fase beta el 04/12/2018.

Realmente un código, en 2(n?) plataformas.

Componentes nativos puros no utilizables desde Flutter.

Misma UI incluso en versiones antiguas del SO (sobre todo en Android).

Soporte&Librerías: mucho pero, ¿todo el necesario?

Perfecta para los MVP (Minimum Viable Product).

No se pueden crear widgets de sistema (home widgets)

Integración con Kotlin y Swift.

Sin soporte para wearables, TVs, Cars, … (aun…).

Conclusiones

Hasta aquí este artículo que pretende dar a conocer Google Flutter y que nos servirá de toma de contacto para poner "toda la carne en el asador" y ver detalles técnicos específicos, así como realizar alguna pequeña PoC que, de algún modo, ponga en valor todo lo que hemos analizado.

No podemos perder de vista a este flamante nuevo framework que promete convertirse en el framework multiplataforma por excelencia.

Aun así, conocemos a Google: por el camino ha ido escondiendo en su alcoba a muchas de sus creaciones (Google+, Wave, Picasa, Project Tango, Panoramio, etc.). Por este motivo, estamos en una situación que nos hace preguntarnos: Flutter: ¿Hype o panacea del desarrollo multiplataforma?

Antonio Jesús Ocaña

Antonio es Jefe de Equipo del Departamento de Consultoría de DXD. Está especializado en gestión de proyectos (Certificación CAPM) multidisciplinarios y de múltiples tecnologías (JAVA, Angular, JSF). También ha trabajado en nuevos desarrollos, mantenimiento evolutivo de la banca (proyectos de intranet, internet, procesos de contratación, riesgos, prepagos, tarjetas, transferencias, etc.), y en proyectos para la administración pública (Junta de Andalucía y Ministerio de Innovación y Ciencia).

Did you find this useful?