R4. Requisitos específicos de Flutter
Para los nuevos desarrollos debe usarse Flutter, ya que es el framework que la OSAM recomienda usar en estos casos, al ser la tecnología escogida por el Ayuntamiento como herramienta de desarrollo al ser la que mejor se adapta a sus necesidades en cuanto a calidad, complejidad, velocidad y coste de desarrollo.
Además de los requisitos de esta página, para las aplicaciones en Flutter se deben tener en cuenta los requisitos generales y específicos para cada plataforma:
R4.1. Estándares de desarrollo o Calidad
- R4.1.1. La aplicación deberá adoptar el mínimo de regles para código estático recomendadas por el propio equipo de Google para todas las aplicaciones Flutter. Por esto es necesario añadir la última versión estable de la dependencia flutter_lints (https://pub.dev/packages/flutter_lints) de acuerdo a como se especifica en su documentación. Para validarlo, se puede usar el comando flluter analyze descrito en este enlace: https://docs.flutter.dev/reference/flutter-cli.
- R4.1.2. El formato del código debe seguir los estándares recomendados por Dart (https://dart.dev/effective-dart/style#formatting). Esto se ha de aplicar a los archivos de desarrollo que no son autogenerados. Para validarlo, se puede usar el comando dart format descrito en este enlace: https://dart.dev/tools/dart-format
R4.2. Herramientas de Desarrollo
-
R4.2.1. Para una separación de responsabilidades entre las diferentes partes del código, se recomienda adoptar una arquitectura limpia (Clean Architecture) y seguir los principios SOLID (https://www.freecodecamp.org/news/solid-principles-for-programming-and-software-design/). Como una base simplificada se puede considerar una buena estructura que el proyecto tenga tres capas: datos, dominio e interfaz. En resumen, la capa de datos se encarga de recoger los datos externos y tratarlos, la capa de dominio contiene la lógica de negocio de la aplicación y la capa de interfaz presenta y gestiona los estados de la parte visual.
Por parte de la OSAM, se indica una base de arquitectura que puede ayudar a crear o entender estos conceptos: https://github.com/worldline-spain/flutter_architecture_template
- R4.2.2. Para controlar los cambios de datos y estados en la parte visual de la aplicación, se recomienda usar un administrador de estados. Se recomienda escoger alguna de las opciones más populares: Bloc (https://pub.dev/packages/flutter_bloc), Riverpod (https://pub.dev/packages/flutter_riverpod) o MobX (https://pub.dev/packages/flutter_mobx). Se pueden ver más en https://docs.flutter.dev/data-and-backend/state-mgmt/options.
- R4.2.3. Para gestionar mejor los errores, se recomienda usar un paquete como Either (https://pub.dev/packages/either_dart) o fpdart (https://pub.dev/packages/fpdart). De esta manera se puede controlar cuando se envía el error a Firebase Crashlytics y el tipo de error para poder presentarlo al usuario de manera más clara y controlada.