Eligiendo dependencias (packages) en Flutter

Cropped photo by Kadarius Seegars on Unsplash

En el desarrollo de software siempre se busca que el producto alcanzado sea estable y de fácil mantenimiento. Hoy en día hay mucho conocimiento en formato de metodologías, herramientas y recursos en general para llegar en un buen producto final.
En el caso de Flutter y seguramente de la mayoría de las tecnologías de desarrollo de software, un punto importante para obtener una aplicación estable y fácil de mantener, es la elección de las dependencias en las que el software se sostiene.

En este artículo hablaré que son esas dependencias, porque se le debe prestar atención a la elección de las mismas y cómo elegir teniendo en cuenta el contexto de la aplicación, la aplicabilidad y las características de las dependencias.

Definiendo una dependencia de software

Una dependencia es un código externo al software, necesario para que este funcione.

En el contexto de Flutter, las dependencias se llaman packages. Estos packages tienen características como:

• Privacidad del código: De código abierto o cerrado (privado). La mayoría de packages a las que se tienen acceso para Flutter y Dart, corresponden a la primera opción. La segunda normalmente son dependencias que no están disponibles públicamente y/o se tiene que pagar para tener acceso.
• Tipo: Dart/Flutter packages y plugins. Los packages en Dart se pueden utilizar en aplicaciones que usen el lenguaje Dart pero no necesariamente que usen Flutter, por ejemplo aplicación de línea de comando. Los packages de Flutter son aquellos que tienen una dependencia con este framework y por tanto solo se pueden usar con este, por ejemplo el package provider. Por otro lado los plugins, son packages hechos con Dart y que se juntan con implementaciones específicas para una o mas plataformas, como Android, iOS, web, etc. Un ejemplo de plugin es el url_launcher.
• Contexto: General o solamente para desarrollo. Un package general, siempre será necesario para que la aplicación funcione. Ya en el contexto de desarrollo, solamente será necesario en cuanto se escriba el código o se ejecuten los tests y no se compilará en el archivo de la aplicación de producción.
  En el archivo de dependencias (pubspec.yaml) se diferencias con las palabras llaves dependencies y dev_dependencies.
• Uso*: Funcionalidad, herramienta o diseño. Los packages para funcionalidades añaden una utilidad a la aplicación, en cuanto los destinados a herramientas ayudan al desarrollo (generalmente dev_dependencies) y por último los de uso para design tienen como objetivo incorporar un componente personalizado (Custom Widget).
• Pueden existir otras categorías de uso que no tenga en cuenta. Si quieres puedes sugerir otra en los comentarios.

Por qué elegir correctamente los packages

Actualmente en pub.dev se pueden encontrar muchos packages que combinan las diferentes características que se han comentado anteriormente. A veces las opciones son tantas que debemos prestar atención en qué package elegir para evitar algunos de los siguientes problemas:

• Incompatibilidad con algunos dispositivos o plataformas;
• Bugs recurrentes;
• Poca o nada mantenimiento y adición de nuevas funcionalidades;
• Falta de documentación;
• Discontinuidad del package;
• Otros factores que pueden causar falta de estabilidad.

Cuando suceden uno o más de estos problemas, afectan directamente al desarrollo de la aplicación, pudiendo hasta bloquear la continuación del desarrollo, obligando a buscar rápidamente alternativas y dando dolores de cabeza.

Cómo eligir packages

Está claro que a nadie le gustaría tener los problemas presentados anteriormente, pero para cada proyecto se pude admitir diferentes niveles de riesgo. Por ejemplo, no es lo mismo elegir un package para un producto con miles de usuarios activos y de una empresa, que elegir un package para una aplicación que desarrollas en tu tiempo libre y la usan 60 personas.

Expandiendo este concepto para una idea con mas detalles, se puede decir que lo importante para elegir un package se divide en tres ámbitos: contexto donde se usará el package, dónde será aplicado en el software y las características del package.

Contexto

Esto hace referencia a: dónde se usará la aplicación, para qué público, el nivel de complejidad de esta aplicación, entre otras cosas. Para conocer mejor el contexto podemos responder preguntas como las siguientes:

• ¿Cuántos usuarios pueden ser afectados al añadir o cambiar un package?
• ¿Es un proyecto para estudio, uso personal o un producto de una empresa?
• ¿Cuál será la durabilidad de este package? ¿Un cambio temporal o para medio o largo plazo?
• ¿La aplicación es o será usada en qué plataformas? Android, iOS, Web, Windows, etc.

Aplicabilidad

La aplicabilidad es cómo y dónde será usado el package dentro del software que se está desarrollando. Esto se puede definir mejor con las siguientes preguntas:

• ¿El package será una funcionalidad principal, secundaria, una herramienta o parte del diseño?
• En el caso que se precise cambiar el package en un futuro ¿será difícil hacerlo?
• ¿Cuál es el nivel de acoplamiento del package en la aplicación? ¿Se puede alcanzar un bajo nivel de acoplamiento usando una interfaz (abstract class)?
• ¿Podríamos crear o mantener el package por nuestra cuenta en el caso que fuese desscontinuado?
• ¿Pueden existir conflictos cuando el package se combine con otras dependencias del proyecto?
• El tipo de licencia del package. Dependiendo de las condiciones, un package puede no permitir en su licencia que sea usado en una aplicación comercial o que sea necesario pagar para comprar la licencia de uso.

Características

Por último tenemos las características del propio package, que constan de más parámetros cuantificables en comparación a los dos ámbitos anteriores y tal vez sea el más importante. A continuación se indica una lista de parámetros que deben ser vistos:

• El sello de Flutter Favorite. Esto es un distintivo del programa con el mismo nombre creado por el equipo de Flutter, que ayuda a identificar los packages que primero se deben considerar para construir una aplicación. Lo bueno de este programa, es que tiene en cuenta varias métricas del package y también tiene un comité de personas expertas en el desarrollo de aplicaciones con Flutter (entre ellos Diego Velasquez), que deciden cuando un package debe recibir el sello Flutter Favorite;
• La cantidad de packages que tengan la misma funcionalidad, lo que ayudará en caso de que sea necesario cambiar el package o a comparar opciones para encontrar la que mejor se adapte al proyecto;
• El soporte a Null Safety, algo esencial para trabajar con las versiones actuales de Dart y Flutter;
• En caso que sea un plugin, el soporte para diferentes plataformas;
• Si es publicado por una persona o empresa verificada (Verified publisher), lo que transmite un poco mas de confianza de la persona o empresa que desarrolla el package;
• La cantidad de likes y el índice de popularidad. El objetivo de esto es muy simple, intentar tener una noción de cuanta gente usa el package y le gusta;
• Los pub points, un índice que pretende analizar la calidad del código y del propio package. Este índice analiza si el package tiene soporte a múltiples plataformas, buena documentación, soporte a null safety, dependencias actualizadas y análisis estática exitosa;
• La documentación en general. De cómo se usa, cuál es la estructura, ejemplos, resoluciones de problemas, etc;
• La cantidad de dependencias del propio package. Al usar un package con muchas dependencias, es probable que este deba recibir actualizaciones más constantes. Por otro lado, se pueden generar conflictos entre las dependencias;
• Si el package está en un repositorio abierto, se pueden ver la frecuencia de actualizaciones, número de issues, la cobertura de tests y el propio código del package;
• Otras características referentes a Dart, Flutter o, en el caso de plugins, a las propias plataformas, como por ejemplo el uso de AndroidX, el formato tipo federated plugins, el uso de las nuevas lenguajes como Swift en vez de Objective-C, entre otras cosas.

Conclusión

Sabiendo el tipo de dependencias de las aplicaciones hechas con Flutter y como pueden afectar al desarrollo, se percibe la importancia de elegir packages con el debido cuidado.

A partir de esto y teniendo en cuenta los tres ámbitos que se deben observar para elegir una dependencia, será más fácil elegir uno o más packages estables y que no representen altos riesgos para el desarrollo de una aplicación.

Soy Matias de Andrea, desarrollador mobile con Flutter y una persona muy interesada por las diferentes cosas que existen en el mundo; desde tecnología, naturaleza, sociedad y muchas más. En el área de desarrollo, a parte de hacer proyectos de código abierto, me gusta contribuir a la comunidad con artículos como este o algún video.

También soy el creador del podcast en portugués Universo Flutter donde hablo y comparto enlaces sobre noticias, consejos, fuentes de conocimiento y otras cosas sobre Flutter.