IMI

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:

• R1. Requeriments generals
• R2. Requeriments específics iOS
• R3. Requeriments específics Android

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.