R4. Requeriments específics de Flutter

Per als nous desenvolupaments ha d'utilitzar-se Flutter, ja que és el framework que l'OSAM recomana fer servir en aquests casos, al ser la tecnologia escollida per l'Ajuntament com eina de desenvolupament al ser la que millor s'adapta a les seves necessitats en quant a qualitat, complexitat, velocitat i cost de desenvolupament.

A més dels requeriments d'aquesta pàgina, per a les aplicacions en Flutter s'han de tenir en compte els requeriments generals i específics per a cada plataforma:

R4.1. Estàndards de desenvolupament o Qualitat

R4.1.1. L'aplicació haurà d'adoptar el mínim de regles per a codi estàtic recomanades pel propi equip de Google per a totes les aplicacions Flutter. Per això és necessari afegir la darrera versió estable de la dependència flutter_lints (https://pub.dev/packages/flutter_lints) d'acord s'especifica en la seva documentació. Per a validar-ho, es pot fer servir la comanda flluter analyze descrita en aquest enllaç: https://docs.flutter.dev/reference/flutter-cli.
R4.1.2. El format del codi ha de seguir els estàndards recomanats per Dart (https://dart.dev/effective-dart/style#formatting). Això s'ha d'aplicar als fitxers de desenvolupament que no són autogenerats. Per a validar-ho, es pot fer usar la comanda dart format descrita en aquest enllaç: https://dart.dev/tools/dart-format
R4.1.3. S'haurà d'incloure en el projecte Flutter una dependència per generar les icones de iOS i Android de manera automàtica a partir d'una imatge base. La dependència és https://pub.dev/packages/icons_launcher i les imatges de base hauran de tenir les especificacions indicades (https://osam.bcn.cat/apps/docsdsv/manual_generacio_icones.pdf)

R4.2. Eines de Desenvolupament

R4.2.1. Per a una separació de responsabilitats entre les diferents parts del codi, es recomana adoptar una arquitectura neta (Clean Architecture) i seguir els principis SOLID (https://www.freecodecamp.org/news/solid-principles-for-programming-and-software-design/). Com una base simplificada es pot considerar una bona estructura que el projecte tingui tres capes: dades, domini e interfaç. En resum, la capa de dades s'encarrega de recollir les dades externes i tractar-les, la capa de domini conté la lògica de negoci de l'aplicació i la capa de interfaç presenta i gestiona els estats de la part visual.

Per part de l'OSAM, s'indica una base d'arquitectura que pot ajudar a crear o entendre aquests conceptes: https://github.com/worldline-spain/flutter_architecture_template
R4.2.2. Per controlar els canvis de dades i estats en la part visual de l'aplicació, es recomana utilitzar un administrador d'estats. Es recomana escollir alguna de les opcions més populars: Bloc (https://pub.dev/packages/flutter_bloc), Riverpod (https://pub.dev/packages/flutter_riverpod) o MobX (https://pub.dev/packages/flutter_mobx). Es poden veure més en https://docs.flutter.dev/data-and-backend/state-mgmt/options.

R4.2.3. Per gestionar millor els errors, es recomana utilitzar un paquet com Either (https://pub.dev/packages/either_dart) o fpdart (https://pub.dev/packages/fpdart). D'aquesta manera es pot controlar quan s'envia l'error a Firebase Crashlytics i el tipus d'error per a poder presentar-lo a l'usuari de manera més clara i controlada.

R4.2.4. És de implementació obligatoria el poder passar arxius .env en temps de compilació per la opció --dart-define-from-file (tutorial https://codewithandrea.com/tips/dart-define-from-file-env-json). Exemple: flutter build apk --dart-define-from-file=.env

El .env haura d'estar en l'arrel del projecte i haura de contenir, com a mínim, les claus obligatòries del punt R1.1.6.3. També es podran afegir altres claus pròpies amb noms diferents a les obligatòries.
- En el cas de l'entorn de PRE, el nom del fitxer serà .env.dev
- Per a poder utilitzar les variables definides en la part nativa, s'han d'implementar els punts X i Y del Manual integració continua per a proveïdors

R4.2.5. S'hauran d'utilitzar de forma obligatòria, els valors obtinguts a partir del punt R4.2.4. Això vol dir que les claus hauràn de llegir-se en el codi corresponent:
- Flutter - Dart
  - COMMON_MODULE_URL: Url de base per la API del mòdul comú
  - MAPBOX_PUBLIC_ACCESS_TOKEN: Token d'accès públic de Mapbox
- Android - Kotlin (build.gradle.kts)
  - BRANCH_HOST_URL: Url del domini host de Branch
  - BRANCH_HOST_ALTERNATE_URL: Url alternativa del domini host de Branch
  - BRANCH_HOST_TEST_URL: Url del domini host en entorn TEST de Branch
  - BRANCH_HOST_TEST_ALTERNATE_URL: Url alternativa del domini host en entorn TEST de Branch
  - BRANCH_LIVE_KEY: Clau secreta de l'entorn LIVE de Branch
  - BRANCH_TEST_KEY: Clau secreta de l'entorn TEST de Branch
- iOS
  - Info.plist
    - BRANCH_HOST_URL: Url del domini host de Branch
    - BRANCH_HOST_ALTERNATE_URL: Url alternativa del domini host de Branch
    - BRANCH_HOST_TEST_URL: Url del domini host en entorn TEST de Branch
    - BRANCH_HOST_TEST_ALTERNATE_URL: Url alternativa del domini host en entorn TEST de Branch
    - BRANCH_LIVE_KEY: Clau secreta de l'entorn LIVE de Branch
    - BRANCH_TEST_KEY: Clau secreta de l'entorn TEST de Branch
  - Runner.entitlements
    - BRANCH_HOST_URL: Url del domini host de Branch
    - BRANCH_HOST_ALTERNATE_URL: Url alternativa del domini host de Branch
    - BRANCH_HOST_TEST_URL: Url del domini host en entorn TEST de Branch
    - BRANCH_HOST_TEST_ALTERNATE_URL: Url alternativa del domini host en entorn TEST de Branch