> For the complete documentation index, see [llms.txt](https://ecm-pmdm-flutter.gitbook.io/1.-introduccion-a-flutter/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://ecm-pmdm-flutter.gitbook.io/1.-introduccion-a-flutter/5.-recomendaciones-para-desarrollar-apps-con-flutter-best-practices.md).
# 5. Recomendaciones para desarrollar apps con Flutter (best practices)
## **Nombrado de ficheros y directorios**
Para nombrar los **ficheros** y **directorios**, utilizaremos **siempre** **minúsculas** y como **separador,** el guión bajo **`_`** `(lowercase_underscore)`
## Organización de los directorios: estructura propuesta
* No hay una forma estandarizada para estructurar nuestra aplicación.
* Pero, a medida que un **proyecto** Flutter crezca deberemos de tener una **estructura** **clara** y **organizada** de todos sus ficheros de forma que se facilite el trabajo en equipo así como el mantenimiento de la aplicación (no debemos perder tiempo buscando un widget que ya tenemos \`programado o dudar en que directorio colocar uno nuevo).
* Todo esto repercutirá al final en un mejor rendimiento de la aplicación
```yaml
assets // recursos propios que utiliza de la aplicación
|_ images
|_ videos
|_ fonts
...
lib
|_ cloud_functions // código para obtener datos de servidores (ej: abrir URL)
|_ screens // (también podemos nombrarlas: pages o windows)
// código UI: para las pantallas de nuestra aplicación
// se puede organizar en subdirectorios: login, home, others
|_ providers // código que transforma los datos recibidos desde el exterior (network)
// en otros objetos de forma que puedan visualizarse/usarse.
// (ej: json de info meteorológica recibido se transforma
// en una lista de objetos weatherInfo)
|_ models // código para los datos que provienen de servidores, del usuario, etc.
// (ej: weatherInfo -> lat, lon, temperature, humidity,...)
|_ utilities // código que contiene la lógica de negocio (business logic)
// para toda nuestra aplicación.
|_ widgets // widgets que se van a utilizar varias veces en distintas partes
// de la aplicación.
// Ejemplo: Listview y LisTile para mostrar los datos recibidos.
```
## Import relativo vs import package
La convención y **mejores** **prácticas** en Flutter prefiere usar **imports** **relativos** al package **para** **código** **dentro** de tu **propio** **proyecto** aunque tenemos varias **alternativas**:
1. **Imports dentro de tu proyecto (lib/):**
```dart
// ✅ EL MEJOR: Usar imports relativos para archivos en lib/
import 'screens/home_screen.dart';
import 'widgets/custom_button.dart';
import 'utils/constants.dart';
```
2. **Imports de paquetes externos:**
```dart
// ✅ CORRECTO: Usar package: para dependencias externas
import 'package:flutter/material.dart';
import 'package:provider/provider.dart';
```
3. **Imports de tu propio paquete:**
```dart
// ✅ TAMBIÉN VÁLIDO: Usar package: para tu propio código
import 'package:mi_app/screens/home_screen.dart';
import 'package:mi_app/widgets/custom_button.dart';
```
### ¿Por qué se prefieren los imports relativos para código de tu proyecto?
Razones:
* Más **cortos** y **limpios**
* Más **fáciles** de **mover** archivos (**refactoring**)
* **Menor** probabilidad de **errores** al renombrar el package
* Es la **convención** **más** **común** en la comunidad Flutter
## ¿Cuándo usar `package`?
1. Siempre para importar **dependencias** **externas**
2. Cuando importas desde **test/** código de lib/
Ejemplo:
```dart
mi_proyecto/
├── lib/
│ ├── src/
│ │ └── calculator.dart
│ └── main.dart
└── test/
└── calculator_test.dart
// En calculator_test.dart DEBES usar package:
import 'package:mi_proyecto/src/calculator.dart'; // ✅ CORRECTO
// NO puedes usar:
import '../lib/src/calculator.dart'; // ⛔️ INCORRECTO
```
Esto es porque los archivos en `test/` están fuera del directorio `lib/` y necesitan referenciar el código como si fuera un paquete.
3. Cuando tienes **múltiples** **packages** en el mismo proyecto.
Ejemplo
```
mi_proyecto/
├── packages/
│ ├── feature_a/
│ │ └── lib/
│ │ └── feature_a.dart
│ └── feature_b/
│ └── lib/
│ └── feature_b.dart
└── main_app/
└── lib/
└── main.dart
// En main.dart cuando quieres usar feature_a:
import 'package:feature_a/feature_a.dart'; // ✅ CORRECTO
```
Esto es común en **proyectos** **grandes** donde divides funcionalidades en packages separados dentro del mismo proyecto.
4. Cuando estás creando un **package** para **publicar**
## Best Practices - Artículos
{% embed url="" %}
{% embed url="" %}
12 Best Practices to Simplify Flutter App Development
{% endembed %}
{% embed url="" %}
SOLID principles in Flutter
{% endembed %}
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://ecm-pmdm-flutter.gitbook.io/1.-introduccion-a-flutter/5.-recomendaciones-para-desarrollar-apps-con-flutter-best-practices.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.