Pode ser que eles nunca precisem de manutenção durante todo o ciclo de vida deles. Seria o sonho de todos os envolvidos no projeto, não é?

Por outro lado, também é válido conceber que bugs podem ocorrer e funcionalidades podem ser acrescentadas nesses plugins, correto?

Concorda, também, que uma simples correção em uma String tem um peso muito menor do que uma alteração na estrutura de um dos métodos públicos do plugin?

Acredite: Incontáveis times de desenvolvimento já sofreram por horas tentando encontrar a origem de um problema após simplesmente terem executado o comando flutter pub upgrade.

A dúvida é: Você, como parte de um time, sentiria-se confortável para atualizar um plugin sem nenhuma informação sobre o que mudou nele?

Se a sua resposta é não, este capítulo foi feito para você.

Por que versionar plugins importa?

Imagine o seguinte cenário:

• Você criou um plugin para lidar com reconhecimento facial.
• Seu app funciona perfeitamente com a versão inicial.
• Um tempo depois, você altera a assinatura de um método interno, publica o plugin novamente, mas esquece de atualizar a versão corretamente.

O que acontece?

• Seu app continua funcionando.
• Mas qualquer outro app que dependa desse plugin pode quebrar instantaneamente.

Esse é o tipo de problema que um bom versionamento evita.
Com versionamento semântico bem aplicado, você consegue sinalizar para qualquer desenvolvedor (ou para você mesmo, no futuro) o impacto real de cada mudança feita no plugin.

Como funciona o versionamento no Flutter/Dart

No ecossistema Flutter, cada plugin possui um arquivo pubspec.yaml.
É nele que você define o número de versão:

version: 0.0.1

Mas esse número não é arbitrário. Ele segue o padrão SemVer (Semantic Versioning), que funciona assim:

• MAJOR (X.0.0) → mudanças que quebram compatibilidade.
  Exemplo: você altera a assinatura de um método do plugin.
• MINOR (0.X.0) → novas funcionalidades adicionadas, mas compatíveis com versões anteriores.
  Exemplo: você adiciona um novo método pause() sem alterar o já existente play().
• PATCH (0.0.X) → correções de bugs ou ajustes internos que não alteram a API pública.
  Exemplo: corrigir um bug de null safety em um método.

Portanto, se o seu plugin está na versão 1.2.3, isso significa:

• 1 → já houve pelo menos uma mudança que quebrou compatibilidade.
• 2 → novas funcionalidades foram adicionadas desde o último major.
• 3 → já foram feitas três correções desde o último minor.

Como o Flutter resolve versões de plugins

No pubspec.yaml dos apps que consomem o plugin, declaramos as dependências assim:

dependencies:
  flutter_text_to_speech: ^1.2.0

O símbolo ^ (caret) significa: aceitar qualquer atualização que não altere o primeiro número (MAJOR).
Ou seja, no exemplo acima, o app pode instalar automaticamente qualquer versão entre 1.2.0 e <2.0.0.

Esse mecanismo dá flexibilidade para evoluir seu app sem precisar fixar cada versão, mas exige disciplina:

• Se você subir de 1.2.0 para 2.0.0, apps que usam ^1.2.0 não serão atualizados automaticamente (para evitar quebra).
• Se você não respeitar o SemVer e fizer mudanças quebráveis (breaking changes) em versões minor ou patch, os consumidores do plugin vão sofrer.

Boas práticas para versionar plugins

1. Sempre use SemVer corretamente

• Mudou assinatura de método? MAJOR.
• Adicionou novo método? MINOR.
• Corrigiu bug interno? PATCH.

2. Mantenha um CHANGELOG.md

• Documente de forma clara cada alteração feita.
• Isso ajuda você e ajuda times que usam seu plugin.

3. Evite publicar versões desnecessárias

• Teste antes de publicar.
• Agrupe correções menores em uma única versão sempre que possível.

4. Comunique as mudanças

• Se o plugin é público, descreva bem o impacto de cada atualização.
• Se o plugin é interno (usado em times), notifique os devs.

Exemplo prático

Suponha que você começou com:

version: 0.0.1

1. Você adicionou um novo método pause()

Novo número:

version: 0.1.0

2. Você corrigiu um bug em speak()

Novo número:

version: 0.1.1

3. Você alterou a assinatura do método speak()

Novo número:

version: 1.0.0

Percebe como cada número conta uma história?

O impacto real no dia a dia de um Dev Flutter

Em grande projetos, as versões de plugins em produção são sempre travadas para evitar que mudanças inesperadas quebrem builds. Times maduros só atualizam dependências depois de analisar cuidadosamente o changelog.

O recado aqui é simples:
👉 Um desenvolvedor Flutter júnior cria plugins.
👉 Um desenvolvedor Flutter sênior cria plugins que podem ser usados, mantidos e evoluídos com segurança por qualquer time.

E é exatamente isso que o versionamento correto proporciona.

Conclusão

Neste capítulo, você aprendeu:

• Por que versionar plugins é essencial.
• Como funciona o versionamento semântico (SemVer).
• Como o Flutter/Dart resolvem versões em pubspec.yaml.
• Quais são as boas práticas para manter plugins utilizáveis em qualquer cenário.

Com esse conhecimento, você não só cria plugins, mas garante que eles possam evoluir de forma sustentável, sem gerar dores de cabeça para você ou para outros devs.

No próximo capítulo, daremos um passo além: integração de SDKs nativos em apps Flutter.

Agora que você sabe criar e manter plugins corretamente, é hora de aprender como usar essa base para conectar apps Flutter com SDKs de terceiros — o que realmente diferencia um profissional sênior no mercado.

Eis que um wild Flutter aparece consumindo o que vê pela frente: Autenticação facial, reprodução de áudio, realidade aumentada… Todo o poder do iOS agora a um Dash de distância.

No entanto, assim como no Android, o Flutter não acessa diretamente essas bibliotecas.

Você já aprendeu nos capítulos anteriores que a ponte entre o Flutter e o código nativo é o Method Channel, e que o plugin é a solução para reaproveitar essa comunicação de forma organizada, simples e reutilizável.

No capítulo 4, você viu em detalhes como o “lado nativo Android” de um plugin responde às chamadas vindas do Flutter.
Agora é a hora de entender como isso funciona no iOS, com Swift.

Recapitulando o código Flutter do plugin

Antes de mergulhar no Swift, vale relembrar o ponto de partida.
O código abaixo representa a classe MethodChannelFlutterTextToSpeech, responsável por chamar o método speak() e enviar uma mensagem ao lado nativo via Method Channel:

import 'package:flutter/foundation.dart';
import 'package:flutter/services.dart';
import 'flutter_text_to_speech_platform_interface.dart';

class MethodChannelFlutterTextToSpeech extends FlutterTextToSpeechPlatform {
  @visibleForTesting
  final methodChannel = const MethodChannel('flutter_text_to_speech');
  @override
  Future<void> speak(String text) async {
    await methodChannel.invokeMethod('speak', text);
  }
}

Ou seja:

1. O app Flutter chama speak("Texto para falar");
2. O plugin envia uma chamada via invokeMethod;
3. Agora, cabe ao lado nativo (Android ou iOS) receber, processar e responder.

No capítulo anterior, você como isso acontece no Android com Kotlin. Agora, é hora de abrir a caixa-preta do lado Swift/iOS.

O código Swift do plugin

Aqui está a implementação da classe nativa em Swift, responsável por responder às chamadas Flutter no iOS:

import Flutter
import UIKit
import AVFoundation

public class FlutterTextToSpeechPlugin: NSObject, FlutterPlugin {
  private var synthesizer: AVSpeechSynthesizer!
  private var textToSpeechChannel: FlutterMethodChannel!

  public static func register(with registrar: FlutterPluginRegistrar) {
    let instance = FlutterTextToSpeechPlugin()
    instance.initializeTextToSpeechService()
    instance.initializeTextToSpeechChannel(binaryMessenger: registrar.messenger())
    registrar.addMethodCallDelegate(instance, channel: instance.textToSpeechChannel)
  }

  private func initializeTextToSpeechService() {
    synthesizer = AVSpeechSynthesizer()
  }

  private func initializeTextToSpeechChannel(binaryMessenger: FlutterBinaryMessenger) {
    textToSpeechChannel = FlutterMethodChannel(
      name: "flutter_text_to_speech",
      binaryMessenger: binaryMessenger
    )
  }

  public func handle(_ call: FlutterMethodCall, result: @escaping FlutterResult) {
    switch call.method {
    case "speak":
      let text = call.arguments as? String
      let isTextNotEmpty = text?.trimmingCharacters(in: .whitespacesAndNewlines).isEmpty == false
      if let validText = text, isTextNotEmpty {
        let utterance = AVSpeechUtterance(string: validText)
        utterance.voice = AVSpeechSynthesisVoice(language: "pt-BR")
        synthesizer?.speak(utterance)
        result(nil)
      } else {
        result(FlutterError(code: "INVALID_ARGUMENT", message: "O texto passado está vazio ou nulo.", details: nil))
      }
    default:
      result(FlutterMethodNotImplemented)
    }
  }
}

Explicando em detalhes

👉 Importações

• Flutter conecta o código ao ecossistema Flutter.
• UIKit fornece componentes essenciais do iOS.
• AVFoundation é a biblioteca da Apple responsável por áudio, fala e multimídia.

👉 Classe FlutterTextToSpeechPlugin

• Extende NSObject e implementa FlutterPlugin.
• Mantém dois objetos principais:
• synthesizer: motor de fala do iOS.
• textToSpeechChannel: o canal de comunicação entre Flutter e iOS.

👉 register(with:)
Esse método é chamado automaticamente quando o plugin é carregado pelo app Flutter.
Ele:

1. Cria uma instância do plugin.
2. Inicializa o serviço de fala (AVSpeechSynthesizer).
3. Cria o Method Channel com o nome "flutter_text_to_speech".
4. Registra o plugin como responsável por lidar com as chamadas feitas ao canal.

👉 initializeTextToSpeechService()
Instancia o AVSpeechSynthesizer, que é o objeto nativo do iOS responsável por transformar texto em voz.

👉 initializeTextToSpeechChannel()
Cria o canal "flutter_text_to_speech", exatamente o mesmo usado no código Flutter.
Esse “nome em comum” é o que conecta os dois mundos.

👉 handle()
É o “coração” do plugin Swift.
Ele intercepta cada chamada vinda do Flutter, verifica qual método foi chamado e responde:

• Se o método for "speak":

1. Lê o texto passado como argumento.
2. Valida se ele não é nulo nem vazio.
3. Cria um AVSpeechUtterance (objeto que representa a fala).
4. Define a voz em português brasileiro (pt-BR).
5. Pede ao synthesizer para falar.
6. Retorna nil ao Flutter (ou seja, sucesso sem valor de retorno).

• Se o método não for implementado: Retorna FlutterMethodNotImplemented.

👉 Fluxo final

1. O app Flutter chama speak("Olá mundo!").
2. O Flutter envia a chamada via MethodChannel.
3. O iOS recebe no método handle().
4. O texto é validado e transformado em fala pelo AVSpeechSynthesizer.
5. O iPhone/iPad literalmente “fala” o texto em voz alta.
6. Flutter recebe a resposta null indicando sucesso.

Conclusão

Agora você conhece dois lados nativos de um plugin Flutter:

• No Android, com Kotlin e TextToSpeech.
• No iOS, com Swift e AVSpeechSynthesizer.

Ambos trabalham em conjunto com o Flutter via Method Channel, permitindo que um simples método Dart (speak()) seja traduzido em código nativo poderoso e reutilizável.

No próximo capítulo, você iniciará sua jornada pelo mundo dos SDKs nativos. A objetivo final dessa jornada é te tornar capaz de integrar SDKs nativos com sucesso e sem receios.

Até lá! 🚀

Você, dev Flutter, mais do que ninguém, sabe que o Flutter não tem acesso direto a essas bibliotecas — ainda. Porém, você também já aprendeu que é possível acessar bibliotecas nativas em um app Flutter por meio de Method Channel, correto?

O fato é que quase nunca bibliotecas assim são utilizadas por apenas um ou dois apps, mas, sim, milhares. Nesse sentido, é unânime a opinião de que escrever o mesmo código para acessar uma biblioteca nativa milhares de vezes seria — para dizer o mínimo — improdutivo.

Eis que os plugins surgem como bastiões da reusabilidade.

No capítulo anterior, você entendeu a função de cada parte de um plugin, assim como o código Dart responsável por requisitar informações às plataformas nativas.

Neste capítulo, você entenderá o código Kotlin responsável por responder às solicitações feitas pelo código Dart e, dessa forma, possibilitar que um plugin Flutter consuma bibliotecas nativas do Android.

É hora de recapitular.

O plugin desenvolvido até o momento contempla a classe MethodChannelFlutterTextToSpeech, cuja responsabilidade é alimentar os apps-clientes do plugin através da comunicação com o nativo via Method Channel.

import 'package:flutter/foundation.dart';
import 'package:flutter/services.dart';

import 'flutter_text_to_speech_platform_interface.dart';

class MethodChannelFlutterTextToSpeech extends FlutterTextToSpeechPlatform {
  
  @visibleForTesting
  final methodChannel = const MethodChannel('flutter_text_to_speech');

  @override
  Future<void> speak(String text) async {
    await methodChannel.invokeMethod('speak', text);
  }
}

Quando o método speak() do plugin é chamado pelo app, o Method Channel envia um sinal para o lado nativo da aplicação.

O que acontece agora? Quem é responsável por receber e responder essa chamada via Method Channel quando o app roda no Android?

É isso que este capítulo irá responder, porém, para que a resposta seja satisfatória, é necessário voltar alguns passos.

Quando o app é inicializado no Android, o Flutter executa uma série de instruções para instalar o plugin.

Dentre elas, está a identificação da classe Java/Kotlin responsável por lidar com chamadas via Method Channel. No caso deste plugin, tem-se a classe FlutterTextToSpeechPlugin, localizada em android/src/main/kotlin/com/example/flutter_text_to_speech/flutter_text_to_speech_plugin.kt.

Essa classe implementa duas interfaces: FlutterPlugin e MethodCallHandler.

A primeira permite que a classe execute instruções na inicialização e finalização do app; A segunda, que a classe seja capaz de interceptar e responder chamadas via Method Channel.

package com.example.flutter_text_to_speech

import android.content.Context
import android.speech.tts.TextToSpeech
import io.flutter.embedding.engine.plugins.FlutterPlugin
import io.flutter.plugin.common.BinaryMessenger
import io.flutter.plugin.common.MethodCall
import io.flutter.plugin.common.MethodChannel
import io.flutter.plugin.common.MethodChannel.MethodCallHandler
import io.flutter.plugin.common.MethodChannel.Result
import java.util.*

class FlutterTextToSpeechPlugin: FlutterPlugin, MethodCallHandler {
  private lateinit var textToSpeechChannel : MethodChannel
  private lateinit var textToSpeechService: TextToSpeech

  override fun onAttachedToEngine(flutterPluginBinding: FlutterPlugin.FlutterPluginBinding) {
    initializeTextToSpeechChannel(flutterPluginBinding.binaryMessenger)
    initializeTextToSpeechService(flutterPluginBinding.applicationContext)
  }

  private fun initializeTextToSpeechChannel(binaryMessenger: BinaryMessenger) {
    textToSpeechChannel = MethodChannel(
      binaryMessenger, "flutter_text_to_speech"
    )
    textToSpeechChannel.setMethodCallHandler(this)
  }

  private fun initializeTextToSpeechService(context: Context) {
    textToSpeechService = TextToSpeech(context) {
      if (it == TextToSpeech.SUCCESS) {
        textToSpeechService.language = Locale.forLanguageTag("BR")
      }
    }
  }

  override fun onMethodCall(call: MethodCall, result: Result) {
    if (call.method == "speak") {
      val text = call.arguments<String>()
      if (text.isNullOrBlank()) {
        result.error(
          "INVALID_ARGUMENT",
          "O texto passado está vazio ou nulo.",
          null
        )
        return
      }
      textToSpeechService.speak(text, TextToSpeech.QUEUE_FLUSH, null, null)
      result.success(null)
    } else {
      result.notImplemented()
    }
  }

  override fun onDetachedFromEngine(binding: FlutterPlugin.FlutterPluginBinding) {
    textToSpeechService.shutdown()
    textToSpeechChannel.setMethodCallHandler(null)
  }
}

Aqui, por mais óbvio que seja, vale deixar claro: Apesar de escritas em Kotlin, as classes FlutterPlugin e MethodCallHandler são uma parte do framework Flutter que trabalha “por dentro” do código nativo (o famoso termo “embarcado”).

Essas classes servem como ponte entre o Android e o Flutter. É um mecanismo nativo do framework desenvolvido para possibilitar que os apps feitos com Flutter se relacionem com código nativo.

É uma decisão muito bem pensada de design. É quase como se o time Flutter dissesse: “Nós conscientemente queremos que os desenvolvedores consumam código nativo.”

Esclarecido esse ponto, é hora de voltar ao código do plugin.

O método responsável por conter as instruções de inicialização do plugin no Android é o onAttachedToEngine(). No caso deste plugin:

• Criação do objeto MethodChannel no código Kotlin, cuja responsabilidade é interceptar e responder solicitações originadas no app Flutter (mais especificamente, chamadas de invokeMethod).
• Criação do objeto TextToSpeech, responsável por fornecer o método que recebe uma String e solicita que o dispositivo a reproduza em áudio.

Com isso, o app está pronto para funcionar perfeitamente no Android. O fluxo que envolve o MethodChannel é praticamente o mesmo que foi explicado no capítulo 2 desta série.

Para relembrar:

1. Flutter chama o método invokeMethod;
2. Nativo intercepta;
3. Nativo responde;
4. Flutter recebe a resposta.

Existem três possibilidades de resposta: Sucesso, erro e método não implementado. Recomenda-se o uso do bloco try-catch para interceptar possíveis erros advindos do lado nativo.

No caso deste plugin, caso o usuário venha a utilizar a funcionalidade de transformar texto em fala, o fluxo bem-sucedido é:

1. O app Flutter chama o método speak('stringParaFalar') do plugin;
2. O plugin, por sua vez, chama o método invokeMethod('speak', stringParaFalar)
3. O Method Channel Android interceptará a chamada, verificará se é válida, validará a String enviada e solicitará que o objeto TextToSpeech execute o método speak().
4. O Method Channel Android envia uma resposta;
5. Flutter recebe null como resposta pois não foi necessário passar nenhum valor.

Por fim, quando o app é finalizado, o método onDetachedFromEngine() é executado para descartar os recursos não mais necessários.

No próximo capítulo, você entenderá como o plugin Flutter recebe e responde chamadas de um app Flutter instalado no iOS e, dessa forma, como utilizar bibliotecas iOS por meio de um plugin Flutter.

Você acabou de construir funcionalidades no seu app Flutter utilizando comunicação com as linguagens nativas Kotlin e Swift.

Eis que um novo app surge e precisa de funcionalidades semelhantes às do seu app. O que fazer? Escrever o mesmo código novamente?

Nesse sentido, o objetivo desta série sobre plugins é apresentar o passo a passo para transformar a comunicação nativa que o seu app necessita em um recurso independente e reutilizável. Em outras palavras, um plugin.

Nesta primeira parte, o objetivo é explicar o que são plugins, os arquivos Dart de um plugin, e como iniciar a migração de um Method Channel de um app para um plugin.

1. O que são plugins?

Imagine o seguinte cenário:

Você acabou de integrar autenticação por biometria em um app. Mais especificamente, desenvolveu widgets, regras de negócio, comunicação com nativo e testes.

O time gostou bastante do seu projeto. O gestor planeja apresentar o seu trabalho em uma reunião geral da empresa, inclusive. Você, claro, está mais do que satisfeito.

Animado com os resultados do seu app, um dos clientes da empresa também deseja a mesma autenticação por biometria no app dele. Você aceita o trabalho, mas fica em um impasse: “Devo escrever o código novamente?”.

Um plugin pode ser a solução do seu problema

Lembre-se: Em teoria, sempre que um mesmo recurso for necessário em dois contextos diferentes, deve-se tornar aquele recurso independente.

Caso contrário, imagine o tempo perdido para resolver um mesmo bug em dois códigos que poderiam ser um só. Lembre-se do princípio Don’t repeat yourself (DRY), não se repita.

Dentro do mundo Flutter, se esse recurso é um código Dart que pode ser utilizado por diferentes apps, ele é um pacote. Se esse pacote contempla comunicação com nativo, ele é um plugin.

Plug significa “conectar”; in, “em”. Em outras palavras, um plugin é um componente que se conecta ao seu app, sem se limitar a ele, e provê funcionalidades reutilizáveis.

Um plugin, por ainda ser um pacote, também contempla — ou deveria — todos os benefícios de um pacote: reusabilidade, encapsulamento, separação de responsabilidades, bem como os benefícios da correta aplicação dos princípios do SOLID.

“Ok, mas e na prática, quais os benefícios de investir tempo em um plugin?”

1. Torna desnecessário reescrever todo um mesmo código do zero em outro app;
2. Caso um bug ocorra, ele é resolvido em um só lugar;
3. Caso o plugin contemple uma nova funcionalidade, todos os apps que dependem dele têm potencial para utilizá-la;
4. Acelera o processo de depuração;
5. Facilita o teste de diferentes cenários;
6. Evita o trabalho de construir um app (muitas vezes pesado) para depurar bugs;
7. Promove um ambiente neutro, livre de efeitos colaterais de outras partes dos apps.

Existem aplicativos que chegam a contemplar mais de 40 pacotes. Pare um pouco e reflita sobre o tempo e esforço necessários para construir esse app apenas para depurar algumas linhas de código, ou um ou dois arquivos.

Apesar das semelhanças, cada projeto tem suas especificidades. Antes de implementar qualquer coisa, é essencial verificar o que é particular de cada app-cliente.

Aqui é hora de colocar os princípios do SOLID em campo.

Informações particulares (e.g. API Key, credenciais etc) devem sempre vir do app que usa o plugin, nunca devem estar fixadas no código deste. Um plugin deve ser sempre agnóstico à cliente — Princípio Aberto Fechado.

2. Criando um plugin do zero

Agora que você entendeu o que é e por que criar plugins, é hora de acompanhar o processo de exportação (ou terceirização) da comunicação nativa de um app Flutter para dentro de um plugin Flutter.

Tomar-se-á como ponto de partida o app apresentado na parte 2 desta série, cuja principal funcionalidade era transformar texto em fala (em inglês, text to speech) através do consumo de bibliotecas Kotlin/Swift via Method Channel.

A princípio, o plano é:

1. Exportar a comunicação com o nativo (neste caso, os Method Channels) para o plugin;
2. Desenvolver métodos públicos no plugin que permitam o consumo das bibliotecas nativas;
3. Consumir as bibliotecas nativas por meio do plugin, não mais diretamente via Method Channel.

3. O Hello World de um plugin Flutter

Para criar um plugin Flutter, utiliza-se um método semelhante ao da criação de um app Flutter.

Caso você utilize editores de texto robustos ou IDEs, como VSCode e Android Studio, cada um deles tem uma forma de criar plugins via interface de usuário (UI), ou seja, sem utilizar linha de comando.

Este artigo não vai cobrir todos os métodos de criação de plugins, visto que há muitas ferramentas disponíveis e, por consequência, muitas maneiras diferentes de se criar um plugin.

Contudo, o método mais recomendado de se criar um plugin, uma vez que dificilmente mudará, é através da linha de comando (e.g. Terminal, CMD, PowerShell etc).

Caso você esteja acostumado com linha de comando, dirija-se ao diretório dos seus projetos e rode o comando abaixo:

flutter create -t plugin --platforms=android,ios flutter_text_to_speech

Esse comando criará um projeto intitulado flutter_text_to_speech, com a estrutura de um plugin, especificamente para as plataformas Android e iOS.

Agora, abra o projeto no editor de texto/IDE de sua preferência. O resultado será semelhante a este:

O primeiro passo foi concluído.
O segundo passo é alterar os arquivos do projeto com os códigos necessários para transformar texto em fala.

Nesse sentido, a ideia é trabalhar em três aspectos do plugin:

1. Código Dart;
2. Código Kotlin;
3. Código Swift.

4. O código Dart inicial

Como explicado no capítulo passado, o código Dart é responsável por manter um MethodChannel e solicitar informações das partes nativas, isto é, do Kotlin e Swift.

Platform Interface

Diferentemente de um app, um plugin trabalha de uma forma um pouco diferente. Como a ideia de um plugin Flutter é “escreva uma vez, use em qualquer plataforma”, o plugin declara uma interface única que será implementada pelas plataformas que desejam servir o app.

Em outras palavras, a interface do plugin apenas define o que deve ser respondido, não o como deve ser respondido. Neste exemplo, o arquivo responsável pela interface é flutter_text_to_speech_platform_interface.dart.

import 'package:plugin_platform_interface/plugin_platform_interface.dart';

import 'flutter_text_to_speech_method_channel.dart';

abstract class FlutterTextToSpeechPlatform extends PlatformInterface {
  /// Constructs a FlutterTextToSpeechPlatform.
  FlutterTextToSpeechPlatform() : super(token: _token);

  static final Object _token = Object();

  static FlutterTextToSpeechPlatform _instance = MethodChannelFlutterTextToSpeech();

  /// The default instance of [FlutterTextToSpeechPlatform] to use.
  ///
  /// Defaults to [MethodChannelFlutterTextToSpeech].
  static FlutterTextToSpeechPlatform get instance => _instance;

  /// Platform-specific implementations should set this with their own
  /// platform-specific class that extends [FlutterTextToSpeechPlatform] when
  /// they register themselves.
  static set instance(FlutterTextToSpeechPlatform instance) {
    PlatformInterface.verifyToken(instance, _token);
    _instance = instance;
  }

  Future<String?> getPlatformVersion() {
    throw UnimplementedError('platformVersion() has not been implemented.');
  }
}

Antes de tudo, é válido dizer que não é necessário investir muito tempo observando cada linha de código, visto que a estrutura dos plugins, em geral, segue essa mesma linha.

Os itens que você precisa prestar atenção são:

A classe contida no arquivo:

• Caso o plugin necessite dar suporte a uma determinada plataforma (e.g. Linux), deverá ser criada uma classe que implemente a classe contida nesse arquivo.

Os métodos públicos:

• Eles deverão ser implementados pelas subclasses. Neste exemplo, apenas getPlatformVersion().

O método static set instance:

• Esse método é utilizado quando o valor de _instance não consegue alimentar a plataforma que o app está rodando. Ex.: Caso o plugin tenha uma implementação para o Windows, e o valor inicial de _instance funciona apenas para Android e iOS — que é o caso do Method Channel —, o plugin precisa receber um objeto que seja compatível com a plataforma Windows.
• Tal operação é feita pelas classes de implementação de plataforma (i.e. Platform Implementation).

App-Facing Class

import 'flutter_text_to_speech_platform_interface.dart';

class FlutterTextToSpeech {
  Future<String?> getPlatformVersion() {
    return FlutterTextToSpeechPlatform.instance.getPlatformVersion();
  }
}

Ao observar a classe, nota-se que o método getPlatformVersion() consome a interface ao invés de consumir uma implementação.

Isso acontece pois o plugin faz uso do Princípio da Inversão de Dependências.

Assim, o app-cliente pode consumir um único método e, ao mesmo tempo, fazer uso de diferentes implementações, tudo graças ao poder do Polimorfismo e da “injeção de dependências” promovida pelo método set instance de Platform Interface.

A princípio, instance receberá o valor adequado para a plataforma em que o app-cliente do plugin estiver rodando. Na prática, se o app estiver rodando no Windows, o plugin utilizará a implementação adequada.

Platform Implementation

Por fim, temos a implementação do contrato estabelecido pela interface.

A princípio, todas as plataformas que consomem este plugin (i.e., Android e iOS) serão alimentadas por meio de uma única classe, a qual utiliza Method Channel. Caso contrário, poderia haver um arquivo específico para cada plataforma o qual poderia conter uma solução totalmente diferente uma da outra.

Por padrão, a CLI do Flutter gera um arquivo cujo nome é composto pelo nome do plugin + Method Channel. Neste caso, flutter_text_to_speech_method_channel.dart.

import 'package:flutter/foundation.dart';
import 'package:flutter/services.dart';

import 'flutter_text_to_speech_platform_interface.dart';

/// An implementation of [FlutterTextToSpeechPlatform] that uses method channels.
class MethodChannelFlutterTextToSpeech extends FlutterTextToSpeechPlatform {
  /// The method channel used to interact with the native platform.
  @visibleForTesting
  final methodChannel = const MethodChannel('flutter_text_to_speech');

  @override
  Future<String?> getPlatformVersion() async {
    final version = await methodChannel.invokeMethod<String>('getPlatformVersion');
    return version;
  }
}

Você pode ter observado que, apesar de ser um arquivo de implementação de plataforma, ele não contém a alteração do valor de _instance como descrito no tópico de Platform Interface.

Essa ausência se deve pelo fato de que todas as plataformas que consomem este plugin são alimentadas por uma só implementação, logo, nunca é necessário “mudar a estratégia”.

Por fim, para facilitar a visualização da relação entre os arquivos, pode-se considerar a imagem abaixo:

5. Como migrar um Method Channel do app para um plugin

Agora é o momento de trazer as implementações contidas no app para o plugin.

Platform Interface

O primeiro passo é remover o método getPlatformVersion do arquivo de interface e adicionar o método speak:

Future<void> speak(String text) async {
  throw UnimplementedError('speak() has not been implemented.');
}

Após essa mudança, a ferramenta de edição de código que você utiliza deverá apontar erros no código do plugin.

Com o contrato atualizado, é hora de alterar o arquivo que consome e o arquivo que implementa a Platform Interface.

App-Facing Class

Future<void> speak(String text) {
  return FlutterTextToSpeechPlatform.instance.speak(text);
}

Platform Implementation

Future<void> speak(String text) async {
  await methodChannel.invokeMethod('speak', text);
}

Com isso, finalizamos a exploração do código Dart, entendendo a estrutura e o papel de cada arquivo dentro de um plugin Flutter. Essa compreensão é essencial para que o recurso seja bem organizado, escalável e fácil de manter.

Na próxima parte da minissérie, vamos mergulhar no lado nativo, abordando como configurar e implementar a comunicação em Kotlin e, em seguida, em Swift. Dessa forma, você terá uma visão completa de como criar um plugin que reúna o melhor dos dois mundos: a praticidade do Flutter com o poder das plataformas nativas.

Talvez não fosse necessário falar sobre a comunicação básica, visto que a documentação já cobre isso, porém… esmiuçar os fundamentos permitirá entender os próximos capítulos com mais clareza.

Nesse caso, enxergue este, em específico, como um reforço da comunicação entre Flutter e Kotlin/Swift.

Este capítulo está dividido em três partes:

1. Fundamentos da comunicação entre Flutter e nativo;
2. Código necessário para o Flutter chamar o nativo corretamente;
3. Código necessário para os nativos responderem às chamadas Flutter.

Para entender o por que utilizar, ou ainda, por que aprender a utilizar Kotlin e Swift em apps Flutter, recomenda-se a leitura do primeiro capítulo desta série. Clique aqui para ler.

Um rápido agradecimento :)

Antes de tudo, gostaria de agradecer a todos pelo engajamento.

Se você teve dificuldade para entender algo, comente abaixo. Críticas são muito bem-vindas.

A ideia é que esta série te incentive a consumir código Kotlin/Swift sem medo e resolva a maior parte das dúvidas sobre o assunto.

Sem mais delongas, vamos à primeira parte.

1 Fundamentos da comunicação entre Flutter e nativo

1. 1 A ponte entre Flutter e nativo

Para criar uma interface de usuário, o Flutter faz uso de suas próprias bibliotecas, como a material e a widgets , as quais foram escritas em Dart.

Já para usar uma biblioteca nativa (na imagem, uma Platform API), faz-se necessária uma ponte entre o Dart e o nativo. Tal ponte funciona, entre outras coisas, como um tradutor bidirecional.

Essa ponte pode ser construída a partir de objetos do tipo PlatformChannel , cujo mais conhecido tipo derivado é o MethodChannel. Sendo assim, haveria um objeto MethodChannel do lado Flutter da “ponte”, e um para cada nativo.

Nesse sentido, a comunicação funciona como transmissão rádio, que só pode ser ouvida/respondida por quem compartilha a mesma frequência; no caso do MethodChannel, do mesmo identificador único.

Essa ponte possibilita tanto o Flutter usar bibliotecas nativas, quanto o nativo executar métodos do lado Flutter.

E o melhor de tudo: Não é preciso se limitar a uma única ponte, então use e abuse do Princípio da Responsabilidade Única na hora de criar seus PlatformChannel.

1.2 A estrutura fundamental das chamadas ao nativo

Antes de continuar para o código, é válido ressaltar a estrutura fundamental de uma chamada ao nativo via MethodChannel.

Vejamos o método invokeMethod dessa classe. Ele recebe o nome do método e um argumento como parâmetros.

// Flutter chama o nativo
methodChannel.invokeMethod('nomeDoMetodo', args);

O nome do método é uma String tanto no Dart como nos nativos. O argumento, por sua vez, pode ser de qualquer tipo primitivo do Dart. Quando o método é chamado, é a vez do nativo trabalhar.

Em resumo: O trabalho do nativo é:

• Verificar o nome do método;
• Capturar, validar e usar os argumentos, caso hajam;
• Responder com sucesso ou erro.

result.success(null)
result.notImplemented()
result.error("INVALID_ARGUMENT", 
  "O texto passado está vazio ou nulo.",
  null // detalhes adicionais (pode ser um Map, por exemplo)
)

Em sua essência, a estrutura sempre será essa, independente do tamanho do método, dos detalhes da implementação e da complexidade do código.

1.3 Binary Messenger

// Inicialização de um MethodChannel no Android
override fun configureFlutterEngine(flutterEngine: FlutterEngine) {
    super.configureFlutterEngine(flutterEngine)
    val textToSpeechChannel = MethodChannel(
      flutterEngine.dartExecutor.binaryMessenger,
      "flutter_text_to_speech_channel"
    )
}

Binary Messenger é uma classe cujo papel pode passar despercebido, mas será possível notá-lo na criação dos MethodChannel nativos.

Um objeto do tipo BinaryMessenger serve para definir como as informações passadas para os objetos do tipo MethodChannel serão transmitidas adequadamente por seus respectivos destinatários.

No caso do BinaryMessenger, sua técnica é autoexplicativa: ele define que as informações serão transformadas em binário.

No Flutter, a implementação padrão dessa classe é a DefaultBinaryMessenger, porém é possível desenvolver sua própria classe, adicionar logs, ter mais rastreabilidade. É um assunto que renderia um artigo dedicado.

Por hora, lembre-se do papel do Binary Messenger na comunicação entre Flutter e nativo. Isso é mais do que o suficiente para seguir os estudos com segurança.

2 Como o Flutter faz uma chamada ao nativo

2.1 Criação do MethodChannel

Para realizar uma chamada ao nativo do lado Flutter, precisamos criar um MethodChannel antes de tudo.

A princípio, o construtor dele apenas uma String, que representa seu identificador único. Diferente dos nativos, não é necessário passar um BinaryMessenger como parâmetro no Flutter.

2.2 Chamada ao nativo

Para fazer uma chamada ao nativo a partir do Flutter, é necessário executar o método invokeMethod do MethodChannel. Como parâmetros, ele recebe o nome do método e argumentos, caso o método nativo precise.

Vale notar que invokeMethod retorna um objeto do tipo Future<T?>. Isso significa que:

1. O tipo de retorno pode ser definido no lado Flutter;
2. invokeMethod pode retornar null;
3. É uma operação assíncrona.

Exemplo:

//Não é possível compilar, pois channelResponse é do tipo String?
Future<String> chamaNativo(dynamic args) async {
  final channelResponse = await channel.invokeMethod<String>('nomeDoMetodo', args);
  return channelResponse;
}

Future<String> chamaNativo(dynamic args) async {
  final channelResponse = await channel.invokeMethod<String>('nomeDoMetodo', args);
  if(channelResponse == null){
    //Caso seja tratável, trata, 
    //senão, pode fazer throw
    //ou mudar o retorno do método para String?
  }
  return channelResponse;
}

2.3 Exemplo prático: App que transforma texto em fala

Para fins de facilitar o entendimento, o código a seguir foi baseado no app de Hello World do Flutter, ou seja, nenhum princípio de arquitetura foi aplicado.

import 'package:flutter/material.dart';
import 'package:flutter/services.dart';

void main() {
  runApp(const MyApp());
}

class MyApp extends StatelessWidget {
  const MyApp({super.key});

  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: 'Flutter Demo',
      theme: ThemeData(colorScheme: ColorScheme.fromSeed(seedColor: Colors.deepPurple)),
      home: const MyHomePage(title: 'Flutter Demo Home Page'),
    );
  }
}

class MyHomePage extends StatefulWidget {
  const MyHomePage({super.key, required this.title});

  final String title;

  @override
  State<MyHomePage> createState() => _MyHomePageState();
}

class _MyHomePageState extends State<MyHomePage> {
  final methodChannel = MethodChannel('flutter_text_to_speech_channel');


  Future<void> execute(Future<void> Function() func) async {
    try {
      await func();
    } on PlatformException catch (e) {
      debugPrint('Erro: ${e.code} - ${e.message}');
    } on MissingPluginException catch (e) {
      debugPrint('Erro: ${e.message}');
    }
  }

  Future<void> channelSpeakCorrectly() async {
    await methodChannel.invokeMethod('speak', 'Olá mundo');
  }

  Future<void> channelEmptyTextError() async {
    await methodChannel.invokeMethod('speak', '');
  }

  Future<void> channelNotImplementedMethodError() async {
    await methodChannel.invokeMethod('sspeak', '');
  }

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(title: Text(widget.title)),
      body: Center(
        child: Column(
          mainAxisAlignment: MainAxisAlignment.spaceAround,
          children: <Widget>[
            IconButton(onPressed: () => execute(channelSpeakCorrectly), icon: Icon(Icons.check)),
            IconButton(onPressed: () => execute(channelEmptyTextError), icon: Icon(Icons.error)),
            IconButton(onPressed: () => execute(channelNotImplementedMethodError), icon: Icon(Icons.question_mark)),
          ],
        ),
      ),
    );
  }
}

Recomenda-se, antes de tudo, investir tempo na compreensão de cada linha desse código antes de utilizá-lo.

No geral, para toda chamada ao nativo via MethodChannel, as possibilidades de resposta são: sucesso, erro e “método não implementado/inválido”.

Quando um erro ocorre, os objetos devolvidos (thrown) pelo MethodChannel contém — ou deveriam conter — informações relevantes sobre o erro, o que facilita em casos de bug ou mal funcionamento.

Sabendo disso, o código acima apresenta três métodos, um para cada tipo possível de retorno:

1. Para o caso de sucesso, o dispositivo ditará o texto passado como argumento;
2. Para o caso de erro, tem-se que o nativo sinaliza o MethodChannel e este realiza o throw de um objeto de tipo PlatformException, o qual contém informações úteis preenchidas no lado nativo;
3. Para o caso de “método não implementado”, o MethodChannel realiza o throw de um objeto de tipo MissingPluginException, semelhante ao PlatformException.

3 Como o nativo responde chamadas

3.1 Adaptações na classe nativa principal

Quando uma chamada é feita pelo Flutter, as seguintes condições precisam ser atendidas:

1. O nativo deve ser capaz de tratar as chamadas;
2. O nativo deve ser capaz de receber chamadas.

No Kotlin, para ser capaz de tratá-las, pode-se tornar a classe MainActivity uma implementação da classe MethodCallHandler, cuja função é justamente garantir que a classe que a implementa seja capaz de tratar chamadas oriundas de MethodChannel.

No Swift, não há necessidade de implementar um protocolo, basta criar um método dentro de AppDelegate. Isso será mostrado mais tarde neste tópico.

3.2 Capacitando o nativo a receber chamadas

Já para receber as chamadas, é necessário criar de fato um MethodChannel.

O construtor dele, em ambos nativos, recebe dois parâmetros:

1. String que representa seu identificador único;
2. Uma instância de BinaryMessenger — conceito explorado posteriormente.

3.3 Conectando a recepção de chamadas com o tratamento

No Kotlin, após a criação do MethodChannel, chama-se o método setMethodCallHandler passando um objeto que implementa a classe MethodCallHandler — neste caso, a própria MainActivity.

No Swift, diferente do Kotlin, o método setMethodCallHandler recebe um método, o qual fará o mesmo trabalho do método onMethodCall do Kotlin.

3.4 Tratamento das chamadas

Dada uma chamada x, existem alguns procedimentos básicos que podemos fazer, independente do nativo.

1. Verifica-se se o nome do método invocado é válido; se existe um tratamento para ele do lado nativo.
2. Verifica-se se existe algum impedimento para a chamada ser bem-sucedida — caso contrário, entra-se em um caso de exceção.
3. Executa-se o tratamento adequado e responder de acordo com o esperado (sucesso ou erro).

Vamos ver como esse conceito se aplica na prática.

3.5 Consumindo a biblioteca TextToSpeech em Kotlin

package com.example.flutter_tts_app

import android.content.Context
import android.speech.tts.TextToSpeech
import io.flutter.embedding.android.FlutterActivity
import io.flutter.embedding.engine.FlutterEngine
import io.flutter.plugin.common.BinaryMessenger
import io.flutter.plugin.common.MethodCall
import io.flutter.plugin.common.MethodChannel
import java.util.*

class MainActivity : FlutterActivity(), MethodChannel.MethodCallHandler {

    private lateinit var textToSpeechChannel: MethodChannel
    private lateinit var textToSpeechService: TextToSpeech

    override fun configureFlutterEngine(flutterEngine: FlutterEngine) {
        super.configureFlutterEngine(flutterEngine)
        initializeTextToSpeechChannel(flutterEngine.dartExecutor.binaryMessenger)
        initializeTextToSpeechService(applicationContext)
    }

    private fun initializeTextToSpeechChannel(binaryMessenger: BinaryMessenger) {
        textToSpeechChannel = MethodChannel(
            binaryMessenger, "flutter_text_to_speech_channel"
        )
        textToSpeechChannel.setMethodCallHandler(this)
    }

    private fun initializeTextToSpeechService(context: Context) {
        textToSpeechService = TextToSpeech(context) {
            if (it == TextToSpeech.SUCCESS) {
                textToSpeechService.language = Locale.forLanguageTag("BR")
            }
        }
    }

    override fun onMethodCall(call: MethodCall, result: MethodChannel.Result) {
        if (call.method == "speak") {
            val text = call.arguments<String>()
            if (text.isNullOrBlank()) {
                result.error(
                    "INVALID_ARGUMENT",
                    "O texto passado está vazio ou nulo.",
                    null // detalhes adicionais (pode ser um Map, por exemplo)
                )
                return
            }
            textToSpeechService.speak(text, TextToSpeech.QUEUE_FLUSH, null, null)
            result.success(null)
        } else {
            result.notImplemented()
        }
    }
}

O código acima permite que o Flutter solicite que um texto digitado seja reproduzido em voz com uma biblioteca nativa do Kotlin.

Observe o código atentamente e note como fundamentos discutidos são postos em prática:

• MainActivity implementa MethodCallHandler, bem como o método onMethodCall (linha 12; linhas 38 a 54);
• O MethodChannel é criado e recebe o responsável pelo tratamento de chamadas (linhas 23 a 28).
• Quando as chamadas acontecem, elas são verificadas, processadas e devidamente respondidas por onMethodCall (linhas 38 a 54);
• O método configureFlutterEngine, responsável por inicializar os serviços, é executado na inicialização do app (linhas 27 a 36).

Agora que a estrutura fundamental das chamadas foi identificada, pode-se discutir como a solução foi desenvolvida:

• Após a inicialização do objeto TextToSpeech, configura-se o idioma de fala para português do Brasil (linhas 30 a 36);
• Quando o método “speak” é invocado a partir do MethodChannel, captura-se e verifica-se se o texto enviado como argumento é nulo ou vazio. Caso seja, o nativo responde com erro. Caso contrário, chama-se o método speak do objeto TextToSpeech e passa-se o texto capturado como parâmetro (linhas 39 a 53).
• Por fim, o nativo responde ao Flutter que a chamada foi bem-sucedida (linha 50).

3.6 Consumindo uma biblioteca nativa em Swift

3.6.1 Estrutura geral da classe AppDelegate

No iOS, o ponto de entrada da aplicação é a classe AppDelegate. Quando o app é iniciado, o método application(_:didFinishLaunchingWithOptions:) é chamado. É nesse momento que se configura os canais de comunicação com o Flutter.

@main
@objc class AppDelegate: FlutterAppDelegate {
  ...
}
// FlutterAppDelegate já cuida da integração 
// básica do Flutter com o iOS, 
// então é necessário apenas adicionar a lógica específica.

3.6.2 Inicialização do serviço de TTS

private var synthesizer: AVSpeechSynthesizer?

private func initializeTextToSpeechService() {
  synthesizer = AVSpeechSynthesizer()
}

Aqui, usa-se o framework AVFoundation para criar um sintetizador de voz nativo. Ele é responsável por “falar” o texto recebido do Flutter.

3.6.3 Criação do MethodChannel

private var textToSpeechChannel: FlutterMethodChannel?

private func initializeTextToSpeechChannel() {
  guard let controller = window?.rootViewController as? FlutterViewController else {
    print("Erro: não foi possível acessar o FlutterViewController")
    return
  }

  textToSpeechChannel = FlutterMethodChannel(
    name: "flutter_text_to_speech_channel",
    binaryMessenger: controller.binaryMessenger
  )

  textToSpeechChannel?.setMethodCallHandler(handleMethodCall)
}

Sobre o código acima, vale ressaltar:

• FlutterMethodChannel é a ponte entre oFlutter e o código nativo.
• O nome do canal (flutter_text_to_speech_channel) deve ser o mesmo usado no lado Flutter.
• setMethodCallHandler define um método (callback) que será chamadao sempre que o Flutter enviar uma mensagem.

3.6.4 Manipulando os métodos recebidos do Flutter

private func handleMethodCall(call: FlutterMethodCall, result: @escaping FlutterResult) {
  if call.method == "speak" {
    ...
  } else {
    result(FlutterMethodNotImplemented)
  }
}

O método acima verifica o nome do método recebido. Se for "speak", ele tenta extrair o texto e falar usando o sintetizador.

3.6.5 Conversão de texto em fala

if let validText = text, isTextNotEmpty {
  let utterance = AVSpeechUtterance(string: validText)
  utterance.voice = AVSpeechSynthesisVoice(language: "pt-BR")
  synthesizer?.speak(utterance)
  result(nil)
} else {
  result(FlutterError(code: "INVALID_ARGUMENT", message: "O texto passado está vazio ou nulo.", details: nil))
}

No código acima:

• Cria-se um AVSpeechUtterance com o texto enviado pelo Flutter.
• Define-se a voz para o idioma português do Brasil (pt-BR).
• Usa-se o synthesizer para falar o texto.
• É retornado sucesso (nil) ou erro com FlutterError.

3.6.6 AppDelegate.swift completo

import Flutter
import UIKit
import AVFoundation

@main
@objc class AppDelegate: FlutterAppDelegate {
  private var synthesizer: AVSpeechSynthesizer?
  private var textToSpeechChannel: FlutterMethodChannel?

  override func application(
    _ application: UIApplication,
    didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?
  ) -> Bool {
    GeneratedPluginRegistrant.register(with: self)

    initializeTextToSpeechService()
    initializeTextToSpeechChannel()

    return super.application(application, didFinishLaunchingWithOptions: launchOptions)
  }

  private func initializeTextToSpeechService() {
    synthesizer = AVSpeechSynthesizer()
  }

  private func initializeTextToSpeechChannel() {
    guard let controller = window?.rootViewController as? FlutterViewController else {
      print("Erro: não foi possível acessar o FlutterViewController")
      return
    }

    textToSpeechChannel = FlutterMethodChannel(
      name: "flutter_text_to_speech_channel",
      binaryMessenger: controller.binaryMessenger
    )

    textToSpeechChannel?.setMethodCallHandler(handleMethodCall)
  }

  private func handleMethodCall(call: FlutterMethodCall, result: @escaping FlutterResult) {
    if call.method == "speak" {
      let text = call.arguments as? String
      let isTextNotEmpty = text?.trimmingCharacters(in: .whitespacesAndNewlines).isEmpty == false
      if let validText = text, isTextNotEmpty {
        let utterance = AVSpeechUtterance(string: validText)
        utterance.voice = AVSpeechSynthesisVoice(language: "pt-BR")
        synthesizer?.speak(utterance)
        result(nil)
      } else {
        result(FlutterError(code: "INVALID_ARGUMENT", message: "O texto passado está vazio ou nulo.", details: nil))
      }
    } else {
      result(FlutterMethodNotImplemented)
    }
  }
}

💡 Conclusão

Dominar o Flutter vai além de saber usar widgets e consumir APIs em Dart: envolve também entender como ele se conecta às plataformas nativas.

Neste capítulo, mergulhamos nos fundamentos da comunicação entre Flutter e os mundos Kotlin e Swift. Exploramos como o Flutter faz chamadas usando MethodChannel, como o código nativo lida com essas chamadas, e o papel de cada lado nessa ponte.

Mesmo que o Flutter abstraia muita coisa, entender o que está acontecendo nos bastidores te dá mais confiança para lidar com integrações reais, e te prepara para desafios muito comuns em projetos profissionais.

🛠️ Esse conhecimento é o alicerce para criarmos, nos próximos capítulos, plugins Flutter mais robustos, bem estruturados e prontos para produção.

Se você chegou até aqui, parabéns. Agora você tem base suficiente para dar os próximos passos com muito mais segurança.

Nos vemos no próximo capítulo! 🙂

Ao mesmo tempo, existe um tema até então pouco explorado (aqui fora, pelo menos).

Concorda comigo que um aplicativo consolidado, que gera receita, maduro, com anos de indústria, quase certamente não usa Flutter?

Para o bem ou para o mal, Flutter é uma ferramenta nova.

Antes do Flutter, e ainda hoje, apps utilizam tecnologias Android e iOS nativas, e, cá entre nós, elas estão longe de “morrer”, visto que são a porta de entrada para seus respectivos sistemas operacionais.

Além disso, assim como nós criamos e usamos pacotes, os desenvolvedores Android e iOS desses apps também fazem o mesmo. E mais: Investem muito tempo e dinheiro em testes, validações e certificações.

Nesse sentido, faz-se a seguinte reflexão: Um app consolidado, que gera receita, maduro e escalável desistiria de todo esse investimento para entrar no mundo Flutter e ter que fazer tudo do zero?

Vamos lá: isso não faz sentido nenhum.

A realidade? Muitos apps consolidados adotam, sim, o Flutter. A questão não é se, mas como:

• Como aproveitam o melhor dos dois mundos;
• Como migram paulatinamente;
• Como não jogam a água do banho com o bebê junto.

Muitos desenvolvedores Flutter focam em bibliotecas puramente Dart, mas ignoram um ponto essencial para quem trabalha com apps: o ecossistema mobile ainda gira, em grande parte, em torno de SDKs nativos.

Gostaria de resolver isso, jovem gafanhoto? Bom, então pegue um café, acomode-se e… vem comigo!👇

✅ O que é um SDK, afinal?

Um SDK (Software Development Kit) é um conjunto de ferramentas, bibliotecas e recursos que permite que desenvolvedores integrem funcionalidades específicas nos seus aplicativos.
Ele pode incluir APIs, bibliotecas nativas, documentação, exemplos e às vezes até um painel de configuração.

Por exemplo:

• Um SDK bancário que oferece autenticação biométrica;
• Um SDK de marketing que coleta eventos de analytics;
• Um SDK de vídeo que lida com gravação e transmissão.

🧭 O Flutter ainda não é o centro do universo

Embora o Flutter tenha crescido bastante, ele ainda é mais novo e menos dominante que Android (Java/Kotlin) e iOS (Swift/Obj-C).

Isso significa que a maioria dos SDKs de mercado são feitos primeiro (ou exclusivamente) para Android e iOS.

Empresas que possuem SDKs nativos e querem oferecer suporte ao Flutter não costumam reescrever tudo em Dart. A abordagem mais comum e mais rápida é reaproveitar o SDK nativo existente. Nesse cenário, entra o papel do dev Flutter que entende do mundo nativo (vai por mim, não precisa entender muito).

🤝 Como o Flutter conversa com esses SDKs?

Para integrar SDKs nativos em um app Flutter, você tem basicamente duas abordagens:

1. Criar um plugin Flutter personalizado com:

• Kotlin/Java no Android (android/src/);
• Swift/Obj-C no iOS (ios/Classes/);
• Usando Platform Channels para fazer a ponte entre o Dart e o código nativo.

2. Reutilizar um plugin existente (quando disponível), mas mesmo assim entender a arquitetura envolvida para ajustar ou depurar.

É fato que boa parte das empresas, principalmente as consolidadas, caso venham a migrar para o Flutter, o farão cautelosamente, confiando essa tarefa à desenvolvedores habilidosos.

Se você ignora esse mundo, deixa na mesa muitas oportunidades valiosas de atuar, gerar resultado e se destacar.

🧠 Por que entender SDKs é um diferencial?

• Você consegue integrar qualquer serviço de terceiros, mesmo que ele só tenha SDKs nativos;
• Você fala a língua das equipes iOS e Android, ganhando respeito técnico;
• Você evita o famoso “bloqueio Flutter”: “só posso usar se tiver plugin pronto”;
• Você pode criar seus próprios plugins e contribuir com a comunidade.

Em empresas maiores (e até mesmo em startups que usam SDKs de parceiros), isso te posiciona como um dev sênior que resolve problemas; não apenas que “usa pacotes”, mas que planeja, desenvolve e aprimora soluções.

💡 Conclusão

O Flutter é uma ponte entre mundos e, para dominá-lo de verdade, você precisa entender o que existe dos dois lados.

Saber o que é um SDK e como reutilizá-lo no seu app Flutter é um passo importante para se tornar um desenvolvedor mais completo, confiante e valorizado.

Se você está estudando para subir de nível no Flutter, meu conselho é simples: dê uma olhada nos SDKs nativos e aprenda como conectá-los ao Dart. É aí que muitos se destacam.

Se você está estudando para subir de nível no Flutter, o conselho é simples:

• Leia a documentação do Flutter sobre integração com SDKs nativos.
• Ponha a mão na massa: Escolha um SDK nativo, crie um plugin e conecte-o a um app Flutter.

Na parte 2 desta tema, vamos desenvolver um plugin Flutter do zero, desde sua concepção e arquitetura, até a integração com um app.

Até a próxima. :)

1. Exceções são comuns, acostume-se

Ao analisarmos qualquer código, a primeira coisa que devemos nos perguntar é: o que pode dar errado nele?

Tomemos como exemplo o que pode dar errado ao realizar login em uma aplicação:

• A internet pode cair;
• O servidor pode cair;
• O e-mail pode ser inválido;
• A senha pode ser incorreta.

Enfim, acesso ao GPS, Bluetooth, Câmera… tudo isso pode sofrer com exceções. O usuário pode negar permissão ao GPS, ou ao Bluetooth; a câmera pode parar de funcionar. Logo, tratar exceções é algo muito natural.

2. Como saber qual exceção ocorreu?

Vamos tomar como exemplo uma requisição a uma API Restful.

Geralmente, quando uma exceção ocorre, o client Http que você está usando joga (throws) uma exceção em forma de objeto, o qual contém informações sobre o que aconteceu, como status code e message.

O ideal é que, se, por exemplo, na operação de login, a senha for incorreta, a forma como a API define o que aconteceu seja sempre a mesma (e.g. message == 'senha_incorreta’). Em geral, a resposta para a pergunta “qual exceção ocorreu" está (ou deveria estar) dentro do objeto que representa a exceção.

Nesse caso, já que falamos de Client Http, se você utiliza o pacote Dio, a exceção é o DioError; já se você utiliza o Uno, é o UnoError, e assim por diante.

3. Como dizer o que aconteceu ao usuário?

A dica é sempre apresentar mensagens úteis, objetivas, que indiquem ao usuário exatamente o que aconteceu e, se for o caso, o que ele pode fazer para corrigir.

Desse modo, alcança-se um tratamento de exceções que não apenas agrada aos desenvolvedores, mas também, e principalmente, aos usuários.

4. Considerações finais

É válido salientar: Não adianta somente saber qual exceção ocorreu, é preciso explicar adequadamente ao usuário, afinal, ele é o centro de todo o processo de desenvolvimento.

Também não adianta um app feito apenas de mensagens bem feitas, é preciso ter regras de negócio bem construídas ou em evolução, bem como recursos (e.g. APIs e pacotes) adequados para bem servir ao seu projeto.

Quer saber mais sobre Flutter e acelerar seus estudos?
Me siga para sempre estar por dentro das novidades 🚀

🌐 Minhas redes sociais 🌐

GitHub | LinkedIn | Instagram | YouTube

Breves considerações sobre Tratamento de Exceções no Flutter was originally published in Flutterando on Medium, where people are continuing the conversation by highlighting and responding to this story.

Se quer aprender, saia da escola

Uma coisa é fato: Praticamente todos nós, brasileiros, fomos influenciados direta ou indiretamente pelo sistema educacional do país.

Segundo o último ranking do PISA, estamos em 66° lugar de 77 países, ou seja, estamos nos 15% piores países na educação.

Vejamos a forma como o estudante médio estuda: assiste à aula; usa celular; dorme. De novo e de novo. Na véspera de avaliação, estuda todos os assuntos com a “esperança” de que isso resolva. E o pior: às vezes resolve. Porém, ele esquece simplesmente TUDO logo após. No livro Aprendendo Inteligência, do professor Pierluigi Piazzi, ele dá o exemplo do fisiculturista (popularmente, “o cara que vai para a academia malhar"): seu treinador te dá mil horas para ter um físico decente dentro de três anos. O que o brasileiro médio faria? Deixaria pra lá por dois anos e, nos últimos cem dias, treinaria dez horas por dia. Precisamos comentar o resultado? ¯⁠\⁠_⁠(⁠ツ⁠)⁠_⁠/⁠¯

Nosso sistema educacional é muito ruim. Não há incentivo à qualidade, e sim à quantidade de alunos e ao rendimento temporário destes — e que se exploda o longo prazo.

Resultado: temos pessoas que não sabem estudar, e quem não sabe estudar, não aprende, logo não gosta de estudar, e, já que não vê resultado, logo não investirá tempo nisso, pois é desprazeroso, cansativo e não dá retorno. É o famoso “estudar pra quê se eu não aprendo?”.

O aprendizado começa onde a escola termina

Segundo o professor Piazzi, a verdade é que todo curso, escola, colégio, faculdade… TUDO. TUDO ISSO serve apenas para UMA COISA: te motivar a estudar sozinho.

“O bom professor não dá aula para fazer o aluno aprender. Ele dá aula para fazer o aluno entender a matéria e, principalmente, fazê-lo gostar do que está sendo apresentado.”

Isso vira o jogo: agora fica claro que o estudo autodidata é a chave do entendimento. Em outras palavras, para aprender Flutter de verdade, você precisa estudar sozinho e consultar os mais experientes.

Mas como posso estudar? Como dominar a técnica dos estudos?

Caso queira um manual completo de como estudar, recomendo muito o livro já mencionado Aprendendo Inteligência, do professor Piazzi.

Para aprender Flutter, especificamente, eu fiz um vídeo exatamente sobre isso. Assista aqui.

As dicas apresentadas no vídeo são derivadas da minha experiência, tanto como desenvolvedor quanto como mentor, do que pode funcionar. Lembre-se disso: As formas de aprender são inúmeras, então escolha um número limitado delas (três, por exemplo) e aplique. Pode ser que algo que funcione para mim, não funcione para você, e vice-versa, porém, e isso serve para todo mundo, para aprender, você precisa estudar sozinho.

Recomendações finais (ou resumo para os mais apressados)

Leia o livro “Aprendendo Inteligência";

Assista ao vídeo “Como aprender Flutter mais rápido";

E faça tudo isso agora, ou agende para hoje mais tarde

Quer saber mais sobre Flutter e acelerar seus estudos?
Me siga para sempre estar por dentro das novidades 🚀

🌐 Minhas redes sociais 🌐

GitHub | LinkedIn | Instagram | YouTube

“Não é o mais forte o que sobrevive, nem o mais inteligente, mas o que melhor se adapta às mudanças.” Leon C. Megginson.

Viabilidade significa estar adequado a algo. Nesse sentido, para o Clean Dart estar adequado às diferentes necessidades das equipes e projetos, precisamos realizar nele adaptações (conscientes e embasadas).

Nesta parte 2, discutiremos sobre uma característica bastante comentada a respeito do Clean Dart: a verbosidade.

1 A verbosidade do Clean Dart

1.1 Clean Code

O Clean Dart tradicional, visto na parte 1, implica na construção de arquivos e classes decorados com ou o nome do caso de uso ou da página a qual estão relacionados. Essa prática deriva de sugestões muito comuns na área de programação, semelhantes àquelas encontradas no livro Clean Code (2009), onde o autor sugere que as classes e arquivos dos projetos devem ser claros em suas funções.

1.2 O possível problema

Porém, quais outros resultados derivam dessa prática?

É possível observar um considerável grau de verbosidade durante a constituição da arquitetura. O quanto isso incomoda? Bem, o incômodo é totalmente relativo à equipe envolvida.

1.3 Como solucionar?

Como quase tudo na programação, existem n soluções. Dentre elas, vamos citar duas:

1. Adaptação
2. Automatização.

2 Adaptando o Clean Dart

Adaptação é o movimento de mudança para resolver um problema específico. Nesse sentido, poder-se-ia adaptar o Clean Dart de forma que ele contemplasse um grau de verbosidade menor do que o usual.

Como faremos isso?

Vamos lá.

2.1 Aproveitando-se da repetitividade

É possível notar que o Clean Dart é bastante repetitivo. Assinaturas de Usecases e Pages são os itens mais repetidos. Nesse sentido, esta abordagem pretende reduzir a verbosidade através de uma reorganização das camadas.

Como assim?

Sustentada na ideia de que casos de uso e páginas são os itens orientantes dos arquivos e classes, esta abordagem define um novo escopo para os arquivos.

Vamos a um exemplo.

Vejamos a camada Domain desta abordagem. Ela não mais contempla vários diretórios (usecases, entities, errors etc), mas sim apenas o diretório usecases.

Dentro de usecases teremos acesso a cada usecase do projeto, como antes. Porém, dentro do diretório de cada usecase, encontraremos os diretórios anteriormente encontrados na camada Domain.

Não apenas isso: os arquivos e classes dentro do diretório de cada usecase não mais terão a assinatura do caso de uso.

Por que? Porque o escopo define isso.

Resumindo: Temos uma arquitetura fortemente baseada em seu escopo.

Que benefícios podemos observar?

1. Reaproveitamento de código: Podemos rapidamente criar módulos aproveitando-nos do código de outros já construídos.
2. Tempo ganho: Os arquivos e classes agora custam menos na criação e manutenção.

Porém, quais desvantagens encontramos?

1. Menos clareza: É nítido que o nível de clareza da arquitetura está relativamente menor do que na abordagem tradicional.
2. Ausência de singularidade: Devido a repetitividade na assinatura dos arquivos, práticas como buscar arquivos pelo nome e importação são relativamente mais difíceis nesta abordagem.

Vejamos aqui um exemplo de projeto que aplica um Clean Dart menos verboso (digamos, um Clean Dart light).

3 Automatizando o Clean Dart

Automatização é sinônimo de pular etapas. Mas de qual etapa estamos falando?

Da etapa de construção do módulo.

A primeira solução teve como princípio a existência de padrões no Clean Dart. Todo padrão traz consigo certo grau de repetitividade, concorda? No passo da escrita da arquitetura, precisamos várias vezes digitar os mesmos caracteres. É exatamente aqui que a automatização toma parte.

A solução que sugiro tem como base a geração de código através de uma Command-line Interface (CLI).

Essa CLI construiria a estrutura-padrão do Clean Dart. Isso resolveria rapidamente o problema da verbosidade durante a construção do módulo.

CLIs com Clean Dart existem?

Sim. Vamos a algumas.

3.1 Slidy

O Slidy é uma CLI desenvolvida pela comunidade Flutterando. Um de seus principais mantenedores é o Jacob Moura, GDE de Flutter no Brasil.

Tal CLI é capaz de não só gerar códigos do Clean Dart, mas também widgets, repositories e até uma arquitetura feature-based.

Sugiro a todos conferirem o Slidy. Deixo esta dica: comentem nas redes da Flutterando a respeito do Slidy. Quanto mais comentários, mais suporte será dado a essa CLI (em outras palavras, encham o saco do Jacob).

Vamos para o próximo.

3.2 Mason

O Mason é uma espécie de CLI, porém eu gostaria de definí-lo como um gerador de códigos.

Esse gerador é capaz de ler um conjunto de instruções (chamados bricks) e gerar código. O objetivo dele é resolver tarefas repetitivas e permitir que os desenvolvedores foquem nas especificidades das aplicações.

3.2.1 Como o Clean Dart se encaixa no Mason?

O brick que o Mason lê não é dele: é de todos aqueles que decidirem utilizá-lo. Isso que dizer que tanto eu quanto você podemos construir bricks.

Dessa forma, podemos construir um brick para gerar a estrutura do Clean Dart.

3.2.2 Um brick do Clean Dart já existe?

Até a data deste artigo, não encontrei. A propósito, os bricks estão disponíveis no BrickHub.

No futuro, vocês podem contribuir com bricks já existentes, forkar outros bricks ou ainda criar os seus próprios bricks.

Quem sabe não teremos uma parte 3 desta série construindo um brick chamado clean_dart? 👀

Vocês gostariam? Deixem aí nos comentários.

4 Clean Dart em 2023

Clean Dart, assim como arquitetura, é um assunto que atrai vários interesses, tais como produtividade, sucesso e escala.

Para alcançarmos isso, a melhor habilidade que podemos exercer é pensar no longo prazo.

Todas as linhas de código são justificadas pelo longo prazo; pelo benefício que elas oferecem. Pouco importa se você aprendeu uma arquitetura nova. Os problemas que queremos resolver sempre se sobressairão sobre todo e qualquer aspecto da programação.

“Clean Dart é viável em 2023?”

Essa não é a pergunta certa.

A pergunta é: você está pronto para 2023?

As soluções só se adaptam quando nós nos adaptamos aos problemas.

Nossos problemas não são resolvidos pela programação. Eles são resolvidos por nós. A programação, assim como o Clean Dart, é apenas mais um meio de resolvermos esses problemas.

Adapte-se ou pereça.
A escolha é sua. 👊

Quer saber mais sobre Clean Dart e Flutter?
Me siga para sempre estar por dentro das novidades 🚀

(O seu clap me ajuda bastante 👏)

🌐 Minhas redes sociais 🌐

GitHub | LinkedIn | Instagram

Clean Dart é viável em 2023? — parte 2 was originally published in Flutterando on Medium, where people are continuing the conversation by highlighting and responding to this story.

Toda boa arquitetura evolui; isso é fato. Assim, esta série de artigos é destinada a contribuir com a evolução do Clean Dart.

Mais especificamente, esta série visa:

1. Expor e justificar a forma como eu costumo utilizar o Clean Dart em projetos Flutter;
2. Contribuir com a evolução do Clean Dart;
3. Evoluir a partir de eventuais críticas.

Em outras palavras, a parte 1 tem, como objetivo, expor a forma como eu particularmente descrevo o Clean Dart tradicional.

Sem mais delongas, vamos começar.

1 Introdução

1.1 O que é Clean Dart?

Clean Dart é uma abordagem de arquitetura limpa para a linguagem de programação Dart.

1.2 O que é Dart?

Dart é uma linguagem de programação a qual, entre várias utilidades, é a principal linguagem de programação do Flutter.

1.3 O que é Flutter?

Flutter é um UI toolkit da Google para construção de experiências multiplataforma a partir de um único código-fonte.

Um exemplo disso? Um app para Android/iOS.

2 Vamos falar de Clean Dart

2.1 Práticas

A proposta do Clean Dart sugere as seguintes práticas:

Divisão de código feature-based (module-based);
Aplicação da arquitetura por feature/módulo (não no app como um todo);

2.2 Camadas

2.2.1 Presenter

A camada Presenter é responsável pela disposição dos recursos visuais de um módulo.

Obs.: Strictu sensu, Pages são Widgets. Nesta seção, leve em consideração a diferença no uso de cada termo.

2.2.1.1 Pages

Widgets que representam telas cheias.

2.2.1.2 Widgets

Widgets que representam componentes (não telas cheias).

2.2.1.3 Controllers

Classes que concentram funções utilizadas por Pages ou Widgets.

2.2.1.4 Stores

Classe responsável pela gerência de estado de um caso de uso, ou seja, de manter o estado atual do caso de uso, bem como as funções responsáveis por alterá-lo.

2.2.1.4 States

Classe responsável por definir os possíveis estados de um caso de uso, os quais são geridos pela classe Store e consumidos pelas Pages.

2.2.2 Domain
A camada Domain é responsável pela definição dos dados específicos utilizados em seu módulo.

2.2.2.1 Repository (classe abstrata)

Classe responsável por definir como os dados serão recuperados da camada Infra.

2.2.2.2 Service

Classe responsável por definir como um serviço será fornecido pela camada Infra para um ou mais casos de uso.

2.2.2.3 Errors

Classe responsável por definir quais erros podem acontecer para um determinado caso de uso.

2.2.2.4 Parameters

Classe responsável por definir quais parâmetros são recebidos por um determinado caso de uso.

2.2.2.5 Usecase (classe abstrata)

Classe responsável por definir a forma como um caso de uso é consumido naquele módulo.

2.2.2.6 Usecase (implementação)

Classe responsável por verificar os parâmetros do caso de uso e solicitar informações a repositórios ou serviços.

2.2.2.7 Typedef

Arquivo responsável por definir os tipos de retorno dos métodos dos casos de uso, assim como de seus respectivos repositórios.

2.2.3 Camada Infra

A camada Infra é responsável pelos recursos-base do módulo.

2.2.3.1 Repository (implementação)

Classe responsável por realizar o tratamento de exceções geral da utilização dos recursos externos.

2.2.3.2 Service (implementação)

Classe responsável por realizar o tratamento de exceções geral da utilização dos recursos do dispositivo (plataforma) do app.

2.2.3.3 Datasource (classe abstrata)

Classe responsável por definir a forma como um datasource é consumido pelo repository.

2.2.3.4 Driver (classe abstrata)

Classe responsável por definir o mínimo necessário que nosso caso de uso necessita

2.2.4 Camada External

A camada External é responsável pela comunicação com recursos externos (i.e. APIs etc).

2.2.4.1 Datasource

Classe responsável pela comunicação entre o aplicativo e algum recurso externo, por exemplo, uma API.

2.2.4.2 Mapper

Classe responsável pela tradução das respostas dos recursos externos para Dart; mais especificamente, para uma entidade (ou entidades) esperadas pelo caso de uso.

2.2.4.3 Driver

Classe responsável pela comunicação entre o aplicativo e algum recurso ou funcionalidade da plataforma do aplicativo, e.g., acelerômetro, câmera etc.

2.3 Nome dos arquivos

Obs. 1: Todos os arquivos são finalizados com “.dart”.

Obs. 2: Classes implementações de contratos são decorados com “_impl”.

2.3.1 Camadas Domain, Infra e External

Nestas camadas, podemos observar que os arquivos estão em função dos casos de uso. Dito isso, vejamos alguns exemplos:

Fórmula: caso_de_uso + _função_do_arquivo

Exemplo 1: get_all_students_usecase.dart

Exemplo 2: get_all_students_usecase_impl.dart

2.3.2 Camada Presenter

2.3.2.1 Controllers, pages e widgets

Sugestão: identificação + _função_do_arquivo

Exemplo: home_page.dart

2.3.2.2 Stores

Stores são orientadas aos casos de uso, ou seja, seguem a linha apresentada na seção 2.3.1.

Fórmula: caso_de_uso + _store

Exemplo: get_all_students_store.dart

3. Insights

3.1 Clean Dart é um modelo estático?

O Clean Dart tradicional é uma estrutura dividida em quatro camadas. Sugere-se a utilização dele em um contexto de módulos independentes. Para mais informações, vejam os apps-exemplos na página dele.

Porém, é mais do que óbvio que:

1. Apps podem ter necessidades diferentes;
2. Logo, apps podem não utilizar a mesma arquitetura.

Como proceder?

É possível adaptar o Clean Dart para atender a essas necessidades. Para tal, cabe aos especialistas envolvidos discernirem o melhor modelo a seguir.

É útil para isso observarmos, sempre, o objetivo final; o por que; o motivo de fazermos o que fazemos. Definir bem os porquês é pré-requisito para definir bem os princípios e regras de toda arquitetura.

3.1.1 Uma entidade em mais de um caso de uso

Existem projetos cujo backend tem prioridade sobre o frontend. Nesses casos, é possível observar reincidência de utilização de uma mesma entidade em casos de uso diferentes.

Como proceder?

Defino uma entidade independente do caso de uso, assim mais de um caso de uso pode fazer uso dessa entidade.

3.2 Orientação das camadas

3.2.1 Presenter

Tanto na teoria quanto na prática, é possível visualizar que, na camada Presenter, as páginas têm prioridade. Por que? Porque páginas podem contemplar mais de um caso de uso.

3.2.2 Demais camadas (Domain, Infra, External)

A partir do exposto, é possível concluir que as demais camadas são orientadas pelos casos de uso. Por que? Porque elas estão diretamente ligadas ao caso de uso. Como assim? Veja que se o caso de uso for utilizado em páginas diferentes, toda sua estrutura (repository, datasource etc) também será utilizada.

3.2.3 A relação entre Store e Page

Não existe uma dependência direta entre páginas e casos de uso. Ambos lados são totalmente independentes, ou seja, as páginas podem ter os casos de uso que quiserem e os casos de uso podem ser utilizados em quaisquer páginas.

Quando essa dependência passa a existir?

Com a introdução da Store. Por que? Porque defino a gerência de estado na Store.

A partir daqui, por motivos de custo-benefício, faço a Page utilizar o mecanismo fornecido pela gerência de estado (e.g. BLoC) para atualizar os componentes interessados no estado do caso de uso da Store.

Uma nota sobre gerência de estado:

Por fins didáticos, chamo “MobX” e “BLoC” seus respectivos pacotes mais famosos utilizados, i.e., flutter_bloc e flutter_mobx. Atenção: Não confundam um pacote com um padrão. São coisas diferentes.

4 O que está além do tradicional?

Chegamos em um campo experimental. A partir da parte 2, veremos algumas abordagens adaptadas para atender necessidades usuais. O principal objetivo é expô-las a críticas e evoluir.

Até o momento, posso adiantar para vocês que:
A parte 2 trará uma abordagem menos verbosa;
A parte 3 trará uma abordagem que separa casos de uso e páginas.

Como será feito?
Justificativas?

Continua…

Tem interesse em Clean Dart e Flutter?
Siga-me aqui e nas minhas redes sociais.
Através delas, vocês saberão primeiro os novos temas de artigos.

🌐 Minhas redes sociais 🌐

GitHub | LinkedIn | Instagram

Clean Dart é viável em 2022? — parte 1 was originally published in Flutterando on Medium, where people are continuing the conversation by highlighting and responding to this story.