Etiqueta: flutter

Una guía con versiones fijadas para mover una app Flutter 2.x heredada a una versión actual de Flutter 3.x, con la migración a sound null safety como la barrera dura: por qué necesitas una ruta de dos saltos a través de Dart 2.19, qué hace dart migrate y qué se rompe en el camino.

Una migracion paso a paso del paquete provider a Riverpod 3.x en una app de Flutter real: de ChangeNotifierProvider a Notifier, de MultiProvider a ProviderScope, de context.watch a ref.watch, de ProxyProvider a composicion con ref.watch, mas los detalles de igualdad y ciclo de vida que muerden. Probado en Flutter 3.27.1, Dart 3.11, provider 6.1.5, flutter_riverpod 3.3.1.

Usa FutureBuilder o StreamBuilder para un widget asincrono autocontenido y desechable. Recurre a AsyncValue de Riverpod cuando el resultado se comparte, se cachea o se muta. Aqui esta la decision, los puntos delicados y codigo ejecutable para ambos. Probado en Flutter 3.44 y flutter_riverpod 3.3.1.

Este fallo significa que se usó un WidgetRef después de que su widget abandonó el árbol, normalmente en una callback asíncrona. Lee lo que necesites antes del await y protege con una comprobación de mounted.

Este fallo significa que llamaste a context.of() después de que el widget salió del árbol, normalmente en un callback asíncrono o en dispose(). Captura el valor antes del await o en didChangeDependencies().

FutureBuilder vuelve a ejecutar tu trabajo asincrono cada vez que el padre se reconstruye porque creaste el Future dentro de build. Muevelo a State.initState (o memoizalo) y FutureBuilder reutilizara el mismo Future. Aqui esta el porque, el caso reproducible y cada variante que muerde.

Dart 3.12 agrega una sintaxis experimental de constructores primarios que declara los campos y un constructor en el encabezado de la clase, reduciendo la clásica clase de datos de tres líneas a una sola.

Elige Riverpod para la mayoría de apps nuevas de Flutter en 2026. Opta por Bloc si tu equipo grande quiere una estructura basada en eventos, y conserva Provider solo para código heredado.

RenderBox was not laid out casi siempre es un error secundario. Busca la primera aserción de layout encima, normalmente un scrollable con restricciones no acotadas, y corrige eso.

Este fallo significa que el código usó un controller después de ejecutar dispose(). Protege las callbacks asíncronas con una comprobación de mounted y nunca liberes un controller que no es tuyo.