Flutter Estructura

Sumario

1 Creación de un proyecto Flutter
- 1.1 VS Code
- 1.2 Android Studio
2 Estructura de un proyecto Flutter
3 Archivos principales de la plataforma Android
4 Trasladar un proyecto

Creación de un proyecto Flutter

VS Code

Android Studio

En Flutter disponemos la opción de crear test´s de prueba sobre aplicaciones creadas para ver si funcionan correctamente.

Más información en: https://flutter.dev/docs/cookbook/testing/unit/introduction

Como en estas secciones no vamos a realizar ninguna prueba, podemos borrar el directorio donde se crear los ficheros de prueba:

Estructura de un proyecto Flutter

A continuación indico a nivel general para qué se usa cada una de las carpetas que aparecen por defecto al crear un nuevo proyecto Flutter.

A medida que avancemos en el curso, os daréis cuenta de cuál es la función concreta de cada una de ellas.

También existen directorios que no aparecen por defecto pero que será necesario crear para hacer nuestras aplicaciones (también serán vistos en secciones posteriores).

Carpetas:

idea: Usado para que Android Studio guarde su configuración para el proyecto en curso. Podéis comprobar cómo dicho directorio no es tenido en cuenta si se sube a un repositorio git abriendo el archivo .gitignore.
android: En esta carpeta se genera todo lo necesario para crear una aplicación Android a partir del proyecto Flutter en lenguaje Java / Kotlin. Cuando se instala la aplicación en el emulador, lo que hace Android Studio es generar el código necesario en formato 'nativo' de Android dentro de esta carpeta. Normalmente no será necesario acudir a modificar nada en esta carpeta.
ios: En esta carpeta se genera todo lo necesario para crear una aplicación iOS a partir del proyecto Flutter. Normalmente no será necesario acudir a modificar nada en esta carpeta.
build: Es necesario ejecutar el proyecto para que se genere la primera vez. Carpeta donde se genera el código al compilar una aplicación Flutter. Es donde se guarda la aplicación Android APK generada. No es necesario modificar nada en esta carpeta.
lib: Donde se encuentran normalmente los archivos que conforman el código fuente de la aplicación Flutter. Se puede estructurar como si fuera un sistema de archivos y permite crear directorios y subdirectorios.
test: Carpeta donde se guardan los archivos para realizar pruebas sobre la aplicación de Flutter.

Archivos:

.metadata: Administrado por Flutter automáticamente y se usa para controlar las propiedades del proyecto Flutter, actualizaciones... Este archivo solo lo cambia Flutter y no debe ser modificado manualmente.
.gitignore: Indica todos los archivos y directorios que deben ser ignorados en caso de subir nuestro proyecto a un repositorio git.
.packages: Metadatos del proyecto Flutter. Contiene la lista de dependencias del proyecto. Es generado automáticamente por el SDK de Flutter y no debe ser modificado.
.pubspec.lock: Indica cómo se construye el archivo pubspec.yaml. No debe editarse.
.pubspec.yaml: Archivo que permite:

Establecer la configuración general del proyecto como nombre, descripción y versión del proyecto
Indicar las dependencias del proyecto (cuando hacemos uso de una nueva funcionalidad, por ejemplo)
Indicar archivos de recursos, como imágenes, audios...

Tiene en cuenta la tabulación.

Cuando se produce un cambio es necesario ejecutar el comando flutter pub get (o flutter packages get) (en casi todos los IDEs aparecerá un mensaje indicándolo y ya lo ejecutará el propio IDE). Normalmente, para que se apliquen los cambios realizados en este archivo, necesitamos hacer un full restart, parando la aplicación y volviéndola a ejecutar para que la reinstale.

nombreproyecto.iml: Este archivo siempre se nombra de acuerdo con el nombre del proyecto y contiene más configuraciones del proyecto Flutter. No debe modificarse.
README.md: Archivo en el que aparece la descripción del proyecto. Es el archivo que aparece en un alojamiento GitHub en Internet.

Archivos principales de la plataforma Android

Dentro del directorio Android se encuentra todo lo necesario para que Flutter genere el APK de dicha plataforma.

En Android existen una serie de archivos de configuración que es necesario conocer:

android/app/build.gradle (dependiendo de la versión de Flutter puede aparecer con la extensión .ktl):

La API va a determinar la versión del S.O. en la que vamos a desarrollar la aplicación.

Cada nueva versión incorpora nuevos componentes gráficos y nuevas funcionalidades, pero tenemos que mantener un equilibrio entre la versión a escoger y el mercado que queramos acaparar.

La API también va a determinar qué aplicaciones pueden ser instaladas en el dispositivo móvil, ya que una aplicación desarrollada para una versión superior no puede ser instalada en un S.O. Android con una versión inferior.

A la hora de determinar la API en un proyecto Android tendremos que escoger lo siguiente:

MIN SDK: Será la API mínima (versión del S.O. Android) en la que nuestra aplicación podrá funcionar. No se podrá instalar en una versión anterior.
TARGET SDK: Indica la versión del S.O. Android en la que está probada nuestra aplicación y sabemos que funciona correctamente. Normalmente se pone la más alta. Podría funcionar en una versión posterior o inferior (siempre que sea mayor que el minSdk). El uso de un target u otro puede influir en el aspecto de nuestra aplicación en tiempo de ejecución (por ejemplo, puede cambiar el tema o aspecto por defecto, en función del target).
BUILD SDK o Compile SDK: Indica la versión del SDK que utilizamos para compilar nuestra aplicación. Esto va a limitar los recursos que podamos emplear en el desarrollo de la aplicación, ya que si por ejemplo tenemos una nueva funcionalidad en una API, por ejemplo en la API 22, y nosotros tenemos marcado un BUILD_SDK de 19, no podremos hacer uso de ella. El build_sdk siempre tendrá que ser mayor o igual al min_sdk.

Normalmente se sigue la regla: minSdkVersion (mínima posible) <= targetSdkVersion == compileSdkVersion (más alta posible del SDK)

android/app/src/main/AndroidManifest.xml

Contiene la definición de las características más importantes de la aplicación: nombre, versión, icono, activities, servicios, instrumentación, permisos de acceso a los recursos, etc.

Fijaos en que existen otros archivos AndroidManifest.xml en los directorios /debug/ y /profile/ que se usan cuando se genera el APK en modo depuración o en modo profile.

Por ejemplo, si nuestra aplicación sale a Internet necesita añadir dicho permiso al AndroidManifest.xml del directorio /main/. Podéis comprobar cómo en modo debug el archivo ya tiene ese permiso puesto.

Trasladar un proyecto

Como los proyectos ocupan bastante y están formados por muchos archivos:

Mejor comprimir el proyecto y copiar el archivo comprimido.
Podemos copiar solamente los archivos que necesitamos (carpeta /assets, carpeta /lib, el archivo pubspec.yaml y cualquier otro archivo modificado que no está en /lib), llevarlos a un proyecto vacío y realizar los pasos anteriores.