IMI

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:

• R1. Requisitos generales
• R2. Requisitos específicos iOS
• R3. Requisitos específicos Android

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.1.3. Se deberá incluir en el proyecto Flutter una dependencia para generar los iconos de iOS y Android de manera automática a partir de una imagen base. La dependencia es https://pub.dev/packages/icons_launcher y las imágenes de base deberán tener las especificaciones indicadas (https://osam.bcn.cat/apps/docsdsv/manual_generacio_icones.pdf) 

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.

• R4.2.4. Es de implementación obligatoria el poder pasar archivos .env en tiempo de compilación por la opción --dart-define-from-file (tutorial https://codewithandrea.com/tips/dart-define-from-file-env-json). Ejemplo: flutter build apk --dart-define-from-file=.env

  El .env deberá estar en la raíz del proyecto y deberá contener, como mínimo, las claves obligatorias del punto R1.1.6.3. También se podrán añadir otras claves propias con nombres diferentes a las obligatorias.

  • En el caso del entorno PRE, el nombre del archivo será .env.dev
  • Para poder usar las variables definidas en la parte nativa, se deben seguir las indicaciones del Manual integración continua para proveedores
• R4.2.5. Se deberán usar de manera obligatoria, los valores obtenidos a partir del punto R4.2.4. Esto quiere decir que las claves deben leerse en el código correspondiente:
  • Flutter - Dart
    • COMMON_MODULE_URL: Url de base para la API del módul común
    • MAPBOX_PUBLIC_ACCESS_TOKEN: Token de acceso público de Mapbox
• Android - Kotlin (build.gradle.kts)
  • BRANCH_HOST_URL: Url del dominio host de Branch
  • BRANCH_HOST_ALTERNATE_URL: Url alternativa del dominio host de Branch
  • BRANCH_HOST_TEST_URL: Url del dominio host en entorno TEST de Branch
  • BRANCH_HOST_TEST_ALTERNATE_URL: Url alternativa del dominio host en entorno TEST de Branch
  • BRANCH_LIVE_KEY: Clave secreta del entorno LIVE de Branch
  • BRANCH_TEST_KEY: Clave secreta del entorno TEST de Branch
• iOS
  • Info.plist
    • BRANCH_HOST_URL: Url del dominio host de Branch
    • BRANCH_HOST_ALTERNATE_URL: Url alternativa del dominio host de Branch
    • BRANCH_HOST_TEST_URL: Url del dominio host en entorno TEST de Branch
    • BRANCH_HOST_TEST_ALTERNATE_URL: Url alternativa del dominio host en entorno TEST de Branch
    • BRANCH_LIVE_KEY: Clave secreta del entorno LIVE de Branch
    • BRANCH_TEST_KEY: Clave secreta del entorno TEST de Branch
  • Runner.entitlements
    • BRANCH_HOST_URL: Url del dominio host de Branch
    • BRANCH_HOST_ALTERNATE_URL: Url alternativa del dominio host de Branch
    • BRANCH_HOST_TEST_URL: Url del dominio host en entorno TEST de Branch
    • BRANCH_HOST_TEST_ALTERNATE_URL: Url alternativa del dominio host en entorno TEST de Branch