Flutter e Dart: do básico à produção on Ivaldo de Oliveira Batista Júnior

Fundamentos do Flutter para desenvolvedores .NET

Mon, 01 Jan 0001 00:00:00 +0000

O que você vai construir

Você não precisa saber criar uma página Flutter antes de começar. A página será construída neste módulo, uma parte de cada vez. Ao final, você terá um projeto chamado developer_profile com:

uma aplicação configurada com MaterialApp e ThemeData;
uma página DeveloperProfilePage em arquivo próprio;
nome, especialidade, localização e botão de contato;
layout que continua utilizável em uma janela estreita;
feedback visual ao clicar no botão;
um teste automatizado e um README com instruções de execução.

Não cole todo o código final de uma vez. Execute o aplicativo em cada checkpoint. Assim, se algo falhar, você saberá em qual pequena mudança procurar o erro.

Dart moderno para desenvolvedores C#

Mon, 01 Jan 0001 00:00:00 +0000

Dart não é C# com outra sintaxe

A familiaridade com classes, interfaces e async/await ajuda, mas Dart tem decisões próprias. Código idiomático usa imutabilidade, parâmetros nomeados, construtores concisos e tipos anuláveis explícitos.

final class Product {
 const Product({
 required this.id,
 required this.name,
 required this.price,
 });

 final String id;
 final String name;
 final double price;
}

final impede uma nova atribuição à variável após a inicialização. const cria valores de tempo de compilação quando toda a expressão também é constante. Prefira imutabilidade por padrão; ela reduz estados intermediários e torna widgets mais previsíveis.

Arquitetura Flutter para projetos profissionais

Mon, 01 Jan 0001 00:00:00 +0000

O problema que a arquitetura resolve

Um aplicativo pequeno tolera acesso à API, validação e atualização visual no mesmo widget. Em um produto real, isso cria uma cadeia difícil de testar: interface conhece transporte, transporte conhece persistência e qualquer mudança atravessa o sistema.

Arquitetura não é uma coleção de pastas. É uma direção de dependência:

presentation -> domain <- data
 ^
 external

O domínio fica no centro e não importa Flutter, Dio, Firebase ou banco local. Camadas externas conhecem contratos internos e podem ser substituídas.

Interfaces profissionais com Material 3

Mon, 01 Jan 0001 00:00:00 +0000

Interface profissional é um sistema

Uma tela isolada pode parecer correta e ainda falhar quando o produto cresce. Interfaces profissionais dependem de regras compartilhadas para espaçamento, tipografia, cores, estados e comportamento responsivo.

Material 3 oferece fundamentos e componentes, mas não substitui decisões do produto. Use o tema como fonte de verdade:

ThemeData buildTheme(ColorScheme colors) => ThemeData(
 useMaterial3: true,
 colorScheme: colors,
 textTheme: const TextTheme(
 headlineMedium: TextStyle(fontWeight: FontWeight.w700),
 bodyLarge: TextStyle(fontSize: 16, height: 1.5),
 ),
 inputDecorationTheme: const InputDecorationTheme(
 border: OutlineInputBorder(),
 ),
);

Evite cores e tamanhos arbitrários dentro de widgets. O tema permite coerência, dark mode e mudanças de marca com menor risco.

Gerenciamento de estado com Provider e Riverpod

Mon, 01 Jan 0001 00:00:00 +0000

Estado é informação ao longo do tempo

Campos de formulário, sessão autenticada, filtros, dados remotos e mensagens de erro têm ciclos de vida diferentes. Antes de escolher uma biblioteca, responda:

Quem é dono deste estado?
Quem precisa observá-lo?
Ele sobrevive à navegação?
É dado de origem ou pode ser derivado?
Como loading, empty e failure serão representados?

setState é adequado para estado local e curto. O problema começa quando widgets distantes dependem do mesmo dado ou quando efeitos assíncronos ficam misturados ao método build.

APIs REST com Dio e arquitetura corporativa

Mon, 01 Jan 0001 00:00:00 +0000

Integração é uma fronteira

Uma API externa não deve ditar o formato do domínio nem vazar detalhes de transporte para a interface. Organize o fluxo:

Widget -> Controller -> Use case -> Repository -> Data source -> HTTP

O caminho de volta converte JSON em DTO, DTO em entidade e exceções em falhas conhecidas.

Cliente Dio centralizado

Dio buildDio(AppEnvironment environment) {
 return Dio(
 BaseOptions(
 baseUrl: environment.apiUrl,
 connectTimeout: const Duration(seconds: 10),
 receiveTimeout: const Duration(seconds: 20),
 sendTimeout: const Duration(seconds: 20),
 headers: const {'Accept': 'application/json'},
 ),
 );
}

Não crie um Dio por requisição. A instância central permite interceptores, cancelamento, métricas e políticas consistentes.

Persistência local com SharedPreferences, Hive e Drift

Mon, 01 Jan 0001 00:00:00 +0000

Persistência é parte do comportamento

Preferências, tokens, catálogos e pedidos offline têm requisitos diferentes. A escolha correta começa com perguntas sobre volume, sensibilidade, consulta, consistência e ciclo de vida.

Necessidade	Opção típica
Tema, idioma, flag simples	SharedPreferences
Objetos e cache chave-valor	Hive
Relações, filtros e transações	Drift/SQLite
Segredo pequeno	Armazenamento seguro da plataforma

Não armazene token sensível em preferências comuns. Não use cache como única fonte de verdade sem uma política de validade.

Firebase para aplicações corporativas

Mon, 01 Jan 0001 00:00:00 +0000

Backend as a Service não elimina arquitetura

Firebase acelera autenticação, dados em tempo real, arquivos e push. O risco é espalhar SDKs por widgets e confundir login com autorização. Trate Firebase como detalhe externo:

presentation -> use cases -> repositories -> Firebase adapters

Crie projetos separados para desenvolvimento, homologação e produção. Arquivos de configuração identificam o projeto, mas regras e credenciais administrativas continuam exigindo proteção.

Authentication e sessão

abstract interface class AuthRepository {
 Stream<AppUser?> authStateChanges();
 Future<AppUser> signInWithEmail(String email, String password);
 Future<void> signOut();
}

A implementação converte FirebaseAuthException em falhas do aplicativo. Mensagens de login não devem revelar se um e-mail está cadastrado quando isso criar risco de enumeração.

Testes, qualidade e observabilidade

Mon, 01 Jan 0001 00:00:00 +0000

Qualidade é feedback em camadas

Testes não provam ausência de defeitos; eles reduzem incerteza sobre comportamentos importantes. Uma estratégia equilibrada usa muitos testes rápidos de domínio, testes de widget para comportamento visual e poucos fluxos integrados de alto valor.

Testes unitários

test('aplica desconto de dez por cento', () {
 const calculator = DiscountCalculator();

 final result = calculator.apply(total: 100, percentage: 10);

 expect(result, 90);
});

Estruture em Arrange, Act e Assert e nomeie pelo comportamento. Um teste deve falhar por uma razão clara.

Publicação, CI/CD e distribuição

Mon, 01 Jan 0001 00:00:00 +0000

Entrega é parte do produto

O aplicativo não termina quando compila na máquina de desenvolvimento. Uma release profissional precisa ser reproduzível, identificável, assinada, validada e monitorada.

Versionamento e artefatos

Em pubspec.yaml:

version: 1.2.0+42

A parte antes de + comunica a versão ao usuário; o build number identifica uma entrega nas lojas. Gere artefatos com a mesma revisão testada:

flutter build appbundle --release
flutter build ipa --release
flutter build web --release

Artefato flutter build <target> --release

build produz um artefato para o alvo solicitado; --release seleciona otimizações e remove ferramentas de desenvolvimento incompatíveis com distribuição. O comando não publica nem comprova que o aplicativo funciona em produção.

Projeto final: Sales Management

Mon, 01 Jan 0001 00:00:00 +0000

O desafio

Construa o Sales Management, uma aplicação corporativa para gestão de produtos, clientes e pedidos. O objetivo não é reproduzir uma tela específica, mas demonstrar que você consegue transformar requisitos em uma solução coesa, segura e operável.

Use a base criada ao longo dos módulos. Faça commits pequenos e mantenha a aplicação executável em cada marco.

Escopo funcional

Autenticação e usuários

Login por e-mail e um provedor social no ambiente de laboratório.
Logout e restauração segura de sessão.
Perfis admin, supervisor e seller.
Rotas e ações protegidas também no backend/regras.

Dashboard

Receita total, quantidade de pedidos, clientes ativos e produtos cadastrados.
Estados loading, empty, success e failure.
Layout adaptado a telefone, tablet e desktop/web.

Produtos e clientes

Listagem, pesquisa, criação, edição e validação.
Imagem de produto com progresso e tratamento de falha.
Paginação ou carregamento incremental.
Registro de atualização para sincronização.

Pedidos

Seleção de cliente e produtos.
Quantidade, valor unitário e total calculado pelo domínio.
Validação contra pedido vazio ou quantidade inválida.
Estado de pedido e atualização de estoque em operação consistente.

Continuidade e notificações

Cache local das consultas importantes.
Indicação clara de dado desatualizado ou operação pendente.
Estratégia documentada para conflito e reconexão.
Notificação de evento de negócio sem payload sensível.

Arquitetura esperada

lib/
 core/
 environment/
 error/
 network/
 observability/
 features/
 auth/
 dashboard/
 products/
 customers/
 orders/
 main.dart

Cada feature deve separar domain, data e presentation quando a complexidade justificar. Não crie camadas vazias apenas para obedecer ao desenho; registre decisões e exceções no README.

Referência de comandos e conceitos Flutter/Dart

Mon, 01 Jan 0001 00:00:00 +0000

Esta página é uma referência de apoio, não um substituto para as aulas. Volte aqui quando precisar interpretar um diagnóstico, escolher um comando ou recordar um conceito. Os exemplos consideram um terminal aberto na raiz do projeto, onde está o pubspec.yaml.

Nesta referência: como ler comandos · diagnóstico Flutter · criação e execução · dependências · qualidade e testes · build · ferramentas Dart · glossário Dart · glossário Flutter · roteiro de diagnóstico.

Como ler um comando

Em uma sintaxe como flutter run -d <deviceId> --debug: