Estado: do setState às arquiteturas

No fim desta aula consegues

• Distinguir estado efémero de estado de aplicação e dizer onde cada um deve viver.
• Comparar setState, Provider, BLoC e Riverpod e escolher com critério.
• Explicar o fluxo de dados unidirecional e porque o estado deve ser imutável.
• Transformar um widget em StatefulWidget e usar initState, setState e dispose corretamente.
• Filtrar uma lista enquanto o utilizador escreve e validar um formulário.

Estado efémero vs estado de aplicação

1 2 3 4 5

1. 1
   ForecastScreen o ecrã inteiro, pai de todos os outros.
   guarda a unidade °C/°F
2. 2
   CurrentConditions a temperatura de agora.
   lê a unidade
3. 3
   DaysRow → DayChip os cinco dias.
   lê a unidade
4. 4
   DetailCard mínima, máxima, vento e chuva.
   efémero: _expandedlê a unidade
5. 5
   IslandsGrid a pesquisa e a grelha das ilhas.
   efémero: _search
6. AlertsForm mais abaixo, fora do ecrã.
   efémero: o que está escrito

Para os testes: estado efémero fica no widget com setState; estado de aplicação fica fora da árvore e é partilhado.

O problema de passar por parâmetro

1 2 3 4

1. 1
   ForecastScreen guarda _fahrenheit e muda-o com setState quando tocas em °F.
   
2. 2
   CurrentConditions recebe fahrenheit no construtor e mostra 73 °F.
   feito no passo 2
3. 3
   DaysRow para o DayChip mostrar °F, a DaysRow tinha de receber fahrenheit só para o passar adiante.
   só passa adiante
4. 4
   DetailCard ainda em °C: mais um construtor a mudar.
   

• No nosso ecrã, a unidade °C/°F vai ser escolhida na AppBar do ForecastScreen e usada em CurrentConditions, no DetailCard e no DayChip, que está dentro da DaysRow.
• Com setState só, a variável tem de viver no antepassado comum (ForecastScreen) e descer por parâmetro, construtor a construtor. A DaysRow passa a receber a unidade só para a entregar ao DayChip. Numa app maior são cinco ou seis níveis: chama-se prop drilling.
• Cada widget intermédio passa a depender de algo que não é seu. Acrescentar um campo novo obriga a mexer em todos os construtores do caminho.
• E quando a unidade muda, setState no ForecastScreen reconstrói o ecrã inteiro, não só os textos com temperaturas.

A resposta a este problema é a razão de existirem as bibliotecas de gestão de estado. Todas resolvem a mesma coisa: pôr o estado num sítio acessível e reconstruir só quem o lê.

setState: quando chega e quando deixa de chegar

rebuild: só o DetailCard

setState no DetailCard (passo 1): só o cartão volta a correr o build.

rebuild: o ecrã todo

setState no ForecastScreen (passo 2): o ecrã inteiro volta a correr o build, até a grelha e o formulário.

• Chega quando o estado é de um ecrã ou de um widget e ninguém mais precisa dele: um contador, um formulário, um cartão que abre e fecha, um filtro de pesquisa local.
• Chega para protótipos e para ecrãs isolados. Não é "má prática"; é a ferramenta mais simples e o Flutter foi desenhado para ela.
• Deixa de chegar quando dois ecrãs sem parentesco precisam do mesmo dado, quando o estado tem de sobreviver à navegação, ou quando queres testar a lógica sem construir widgets.
• Deixa de chegar quando o build reconstrói uma árvore grande por causa de um booleano.

Para os testes: setState marca o widget como sujo e agenda um rebuild do seu subtree no próximo frame. Não reconstrói a app inteira, mas reconstrói tudo abaixo.

ChangeNotifier, Provider e InheritedWidget

class UnitSettings extends ChangeNotifier {
  bool fahrenheit = false;

  void toggle() {
    fahrenheit = !fahrenheit;
    notifyListeners(); // avisa todos os widgets que fazem watch
  }
}

// num widget que mostra temperaturas: reconstrói quando a unidade muda
final fahrenheit = context.watch<UnitSettings>().fahrenheit;

// no botão °C/°F: só chama, não precisa de reconstruir
onSelectionChanged: (_) => context.read<UnitSettings>().toggle(),

• InheritedWidget é o mecanismo do próprio Flutter para pôr um valor na árvore e deixar qualquer descendente lê-lo com context. O Theme.of(context) que usamos em todos os build é isto.
• ChangeNotifier é uma classe com notifyListeners(). O teu estado estende-a e chama notifyListeners() sempre que muda, como o UnitSettings do bloco de cima.
• Provider junta os dois: põe o notifier na árvore e context.watch<UnitSettings>() reconstrói só o widget que o chamou quando há notifyListeners.
• Resolve o problema de passar por parâmetro: o DayChip lê a unidade diretamente; a DaysRow nem sabe que existe.
• É recomendado pela equipa do Flutter para começar e é o que vamos usar no projeto.

Para os testes: Provider é um InheritedWidget com açúcar; ChangeNotifier avisa os ouvintes; watch reconstrói, read não.

BLoC, Cubit e Riverpod

Todas fazem a mesma coisa por baixo: um objeto que guarda estado e avisa quem o observa. A diferença está na cerimónia e nas garantias.

Fluxo unidirecional e imutabilidade

1Ação

O utilizador toca em °F.

→

2Estado

_fahrenheitfalse → true

Muda num só sítio: o State do ForecastScreen, com setState.

→

3UI

O build corre outra vez e desenha 73 °F.

// 1. ação: o toque chama o callback, que pede a mudança
onSelectionChanged: (s) => setState(() => _fahrenheit = s.first),

// 2. estado: o valor existe num só sítio, no State do ForecastScreen
bool _fahrenheit = false; // the state lives in the State, not in the widget

// 3. UI: o build volta a correr e o valor novo desce por parâmetro
child: CurrentConditions(fahrenheit: _fahrenheit),

• Os dados descem, os eventos sobem. O CurrentConditions recebe fahrenheit e só o mostra: não tem forma de o mudar. Quem muda é quem guarda.
• Uma só fonte de verdade. Se a unidade estivesse guardada em dois widgets, mais cedo ou mais tarde um mostrava °C e o outro °F.
• O ecrã é uma função do estado. Com o mesmo _fahrenheit vês sempre o mesmo ecrã. É o que torna os erros fáceis de reproduzir.
• Imutável: em vez de alterar um objeto, crias um novo (copyWith). Os campos final do DayForecast em lib/data.dart já são assim. BLoC e Riverpod levam isto até ao fim.

Para os testes: fluxo unidirecional é ação → estado → UI; imutabilidade significa criar cópias com copyWith em vez de alterar objetos.

Critério para escolher, e o que vamos usar

• Quantos ecrãs partilham o estado? Um: setState. Vários: Provider ou acima.
• Precisas de testar a lógica sem widgets? Então a lógica tem de viver fora dos widgets: Provider, BLoC ou Riverpod.
• Tamanho da equipa e do projeto. Três pessoas e 10 ecrãs: Provider. Vinte pessoas e 200 ecrãs: BLoC ou Riverpod pelas regras que impõem.
• O que a equipa já sabe pesa mais do que o que está na moda.
• No projeto usamos setState para estado efémero e Provider com ChangeNotifier para o resto: é simples, é o recomendado no guia de arquitetura do Flutter, e dá para chegar a BLoC mais tarde sem reescrever tudo.

Começar: o repositório de hoje

git clone https://github.com/Tiago-Rocha/pdm-aula-08.git
cd pdm-aula-08
flutter pub get

1. Abre a pasta pdm-aula-08 no VS Code. É a app do fim da aula 7, mais um formulário de avisos no fundo do ecrã. Trabalhas em lib/forecast_screen.dart e lib/alerts_form.dart, nos comentários TODO 1 a TODO 4.
2. Ctrl+Shift+P → Flutter: Select Device → o teu Android ou, se ainda não corre no teu portátil, o Chrome. Depois F5.
3. Confirma o que vês: o ecrã de previsão da última aula, com o cartão de detalhe com as quatro linhas e, no fundo, o cartão "Receber avisos".

O Android não arranca? Quase sempre é o Java que o Gradle está a usar: vê os problemas frequentes do guia de instalação e chama o docente. Entretanto segue a aula no Chrome: todos os passos de hoje funcionam igual no browser.

1. StatelessWidget vs StatefulWidget

class DetailCard extends StatefulWidget {
  const DetailCard({super.key});

  @override
  State<DetailCard> createState() => _DetailCardState();
}

class _DetailCardState extends State<DetailCard> {
  bool _expanded = false;

  @override
  Widget build(BuildContext context) {
    // ... o build de antes, que agora pode ler e mudar _expanded
  }
}

• O widget continua imutável. O que muda é o objeto State, que o Flutter cria uma vez e mantém vivo entre rebuilds. É por isso que o hot reload não perde o que está no ecrã.
• setState(() { ... }) faz duas coisas: executa a alteração e marca o widget para reconstruir no próximo frame. Alterar a variável sem setState muda o valor, mas o ecrã não acompanha.
• Só o subtree deste widget é reconstruído. Quanto mais abaixo estiver o StatefulWidget, menos trabalho.

Passo 1: o cartão que abre e fecha

// Pista: Ctrl+. em cima de "DetailCard" → Convert to StatefulWidget
bool _expanded = false;

return Card(
  clipBehavior: Clip.antiAlias, // keeps the ripple inside the corners
  child: InkWell(
    onTap: () => setState(() => _expanded = !_expanded),
    child: Padding(
      padding: const EdgeInsets.all(16),
      child: Column(
        children: [
          // Mínima e Máxima, como estão
          if (_expanded) ...[
            // Vento e Chuva, cada um com o SizedBox antes
          ],
          Icon(_expanded ? Icons.expand_less : Icons.expand_more),
        ],
      ),
    ),
  ),
);

Na app: o cartão começa só com a mínima e a máxima e uma seta para baixo; um toque mostra o vento e a chuva e a seta vira para cima; outro toque fecha.

2. Subir o estado: a unidade °C/°F

• A unidade não é só de um widget: o CurrentConditions mostra temperaturas, mas o botão para a escolher fica na AppBar, que é do ForecastScreen.
• Regra do setState: o estado vive no antepassado comum mais próximo de quem o muda e de quem o mostra. Aqui é o ForecastScreen, que passa a StatefulWidget.
• Quem só mostra recebe o valor por parâmetro, num campo final, como o DayChip recebe o forecast. Não guarda nada.
• O SegmentedButton é um controlled widget: mostra o que está em selected e avisa em onSelectionChanged. O Switch, a Checkbox e o Slider funcionam da mesma maneira.

Passo 2: o botão °C/°F

git stash -u
git checkout passo-1
flutter pub get

// Pista: Ctrl+. em cima de "ForecastScreen" → Convert to StatefulWidget
bool _fahrenheit = false; // the state lives in the State, not in the widget

appBar: AppBar(
  title: const Text('Tempo Açores'),
  actions: [
    SegmentedButton<bool>(
      segments: const [
        ButtonSegment(value: false, label: Text('°C')),
        ButtonSegment(value: true, label: Text('°F')),
      ],
      selected: {_fahrenheit},
      showSelectedIcon: false,
      onSelectionChanged: (s) => setState(() => _fahrenheit = s.first),
    ),
    const SizedBox(width: 8),
  ],
),

const CurrentConditions({super.key, required this.fahrenheit});

final bool fahrenheit; // chosen in ForecastScreen, received here

String temp(double c) =>
    fahrenheit ? '...' : '${c.round()} °C';

// e no ListView do ForecastScreen:
child: CurrentConditions(fahrenheit: _fahrenheit),

Na app: carregas em °F e o 23 °C grande passa a 73 °F, a mínima a 63 °F e a máxima a 73 °F. A fila dos dias continua em °C.

3. Ciclo de vida do State

late final TextEditingController _search;

@override
void initState() {
  super.initState(); // once, before the first build
  _search = TextEditingController();
}

@override
void dispose() {
  _search.dispose(); // what initState creates, dispose frees
  super.dispose();
}

Para os testes: tudo o que crias em initState libertas em dispose; build pode correr muitas vezes e não deve ter efeitos secundários.

3. TextField e pesquisa: o que interessa

• O TextEditingController guarda o texto da caixa. Precisas dele para ler o texto noutro sítio, limpá-lo (botão X) ou pôr um valor inicial. E aí, dispose.
• onChanged corre a cada tecla. Como o texto já está no controller, só precisas de pedir um rebuild: setState(() {}).
• A lista filtrada é um getter calculado a partir do estado. Não guardes a lista filtrada como estado: são dois valores que podem ficar dessincronizados.
• Filtrar nove ilhas a cada tecla é instantâneo. Filtrar 100 000, ou pedir à API, exige esperar que o utilizador pare de escrever (debounce, com um Timer).
• InputDecoration controla o aspeto: prefixIcon, suffixIcon, hintText, labelText, borda e texto de erro.

Passo 3: pesquisar ilhas

git stash -u
git checkout passo-2
flutter pub get

// Pista: Convert to StatefulWidget, e o controller do slide anterior
List<Island> get _filtered => islands
    .where((i) => '...')
    .toList();

// no build: uma Column com o TextField em cima e o GridView em baixo
child: TextField(
  controller: _search,
  decoration: InputDecoration(
    prefixIcon: const Icon(Icons.search),
    hintText: 'Pesquisar ilha',
    border: const OutlineInputBorder(),
    // suffixIcon: null sem texto; com texto, um IconButton que limpa
  ),
  onChanged: (_) => setState(() {}), // the text is in _search
),

// e o GridView mostra só as filtradas:
children: [for (final i in filtered) IslandCard(island: i)],

Na app: escreves "ter" e só fica a Terceira; aparece um X que limpa e volta a mostrar as nove; "xyz" mostra "Nenhuma ilha encontrada".

4. Form, TextFormField e validação

final _formKey = GlobalKey<FormState>(); // a field, never inside build
final _email = TextEditingController();

void _submit() {
  // validate() runs every validator and shows the errors
  if (_formKey.currentState!.validate()) {
    ScaffoldMessenger.of(context).showSnackBar(
      SnackBar(content: Text('Avisos enviados para ${_email.text}')),
    );
  }
}

child: Form(
  key: _formKey,

• Form agrupa campos; a GlobalKey<FormState> dá acesso ao formulário a partir do botão. É dos poucos usos legítimos de GlobalKey.
• Cada TextFormField tem um validator que devolve a mensagem de erro, ou null se o valor estiver bem. validate() corre todos, mostra os erros por baixo dos campos e devolve true se nenhum falhar.
• autovalidateMode: AutovalidateMode.onUserInteraction valida cada campo enquanto o utilizador escreve nele. Sem isto, só valida ao submeter.
• keyboardType: TextInputType.emailAddress e textInputAction: TextInputAction.next mudam o teclado do telemóvel. Em mobile, isto é UX.

Para os testes: um validator devolve null quando o valor é válido e uma String com o erro quando não é.

Passo 4: validar o formulário de avisos

git stash -u
git checkout passo-3
flutter pub get

// no Form, por baixo da key:
autovalidateMode: AutovalidateMode.onUserInteraction,

// no campo Nome:
validator: (v) {
  if (v == null || v.trim().isEmpty) return 'Obrigatório';
  // e com menos de 3 letras: 'Pelo menos 3 letras'
  return null; // null means valid
},

// no campo E-mail:
keyboardType: TextInputType.emailAddress,
// e um validator: 'Obrigatório', e 'E-mail inválido' sem @ ou sem ponto

Na app: "Subscrever" com os campos vazios mostra "Obrigatório" por baixo dos dois e não mostra o SnackBar; "Ana" e "ana@uac.pt" mostram "Avisos enviados para ana@uac.pt". No telemóvel, o campo do e-mail abre o teclado com @.

Onde ficámos

1. DetailCard: StatefulWidget com _expanded, que abre e fecha ao toque (passo 1).
2. ForecastScreen: guarda a unidade em _fahrenheit e passa-a por parâmetro ao CurrentConditions (passo 2). A fila dos dias ainda está em °C: é o custo de passar por parâmetro.
3. IslandsGrid: pesquisa com controller criado em initState e libertado em dispose, lista filtrada calculada num getter (passo 3).
4. AlertsForm: Form com GlobalKey, um validator por campo e autovalidateMode (passo 4).

Tudo isto é estado efémero, e setState chega. O branch passo-4 é o estado final: compara o teu código com ele.

Até amanhã