Papuguinho: como Flutter viabiliza um app de CAA código aberto

Quando vi a notícia no Br-linux.org sobre o Papuguinho, um sistema de Comunicação Aumentativa e Alternativa (CAA) desenvolvido por estudantes do IFSP Jacareí, minha primeira reação foi técnica, não emocional: “Finalmente alguém pensou na arquitetura antes de pintar o botão”. A maioria dos apps de acessibilidade que vejo por aí falha exatamente nisso — interfaces bonitas, mas sem a engenharia por trás que sustenta crianças com TEA no dia a dia. Vou destrinchar o projeto do ponto de vista de quem programa.

O que é o Papuguinho e por que ele importa para devs

O Papuguinho é um sistema CAA gratuito, atualmente disponível para Android e Windows, pensado para crianças neurodivergentes, pessoas com TEA e qualquer indivíduo com dificuldades de fala. Segundo o Br-linux.org, o app usa pranchas visuais — ícones coloridos que, ao serem tocados, formam frases faladas. Parece simples, mas quem já tentou implementar TTS (text-to-speech) decente em mobile sabe que “simples” é a palavra mais perigosa do vocabulário de um engenheiro.

O ponto que me chamou atenção não foi o produto final, e sim a metodologia: toda escolha visual foi precedida por pesquisa. Azul e verde foram escolhidos após estudos sobre preferência cromática. O nome remete ao papagaio — ave que reproduz sons — criando uma metáfora cognitiva acessível. Isso é UX research aplicado de verdade, não aquele workshop de “personas” que fica no PowerPoint.

Arquitetura técnica: de FlutterFlow para Flutter puro

A decisão que mais me interessou foi a migração do FlutterFlow para Flutter tradicional, mantendo o Firebase como backend. Na minha experiência, esse movimento é mais comum do que deveria — e mais inteligente do que parece.

Por que FlutterFlow deixa de escalar

FlutterFlow brilha em MVPs e protótipos. Quando o projeto precisa de:

• Lógica condicional complexa (como adaptar pranchas a perfis individuais)
• Integração nativa com TTS de cada plataforma (SAPI no Windows, AVSpeechSynthesizer no iOS, Android TTS)
• Performance consistente em devices antigos — comuns no público-alvo
• Customização profunda do ciclo de vida do widget

…o ambiente low-code vira gargalo. O time do Papuguinho percebeu isso e migrou para Flutter puro, o que dá acesso a flutter_tts, speech_to_text, e pacotes de acessibilidade como semantics de forma granular.

Firebase como backend: escolha pragmática

Firebase faz sentido aqui por três razões práticas:

1. Realtime Database ou Firestore permitem sincronizar pranchas customizadas entre dispositivos sem servidor customizado
2. Authentication com Anonymous Auth resolve o problema de famílias que não querem criar conta para a criança usar
3. Remote Config viabiliza A/B testing de layouts de pranchas sem rebuild do app

Cuidado, porém: Firestore em projetos de acessibilidade precisa de offline persistence ativado desde o primeiro commit. Crianças em ambiente escolar ou clínico nem sempre têm Wi-Fi estável.

Engenharia da acessibilidade: o que a maioria erra

Quando construo qualquer coisa para usuários neurodivergentes, tenho uma regra: a aplicação deve funcionar sem instrução verbal. Isso significa que affordances visuais, áudio feedback e previsibilidade de layout são obrigatórios, não opcionais.

O Papuguinho acertou ao pensar em “temas customizáveis” para as pranchas. Isso resolve um problema real: crianças com TEA frequentemente têm hiperfoco em padrões visuais específicos, e forçar um único tema gera rejeição. A customização via Firebase + Flutter permite que terapeutas configurem perfis remotos.

Na Prática: implementando uma prancha acessível em Flutter

Vou mostrar um esboço de como eu estruturaria o widget central do Papuguinho. O segredo é separar estado, modelo e feedback sensorial.

import 'package:flutter/material.dart';
import 'package:flutter/semantics.dart';
import 'package:flutter_tts/flutter_tts.dart';

class CommunicationBoard extends StatefulWidget {
  final List symbols;
  final FlutterTts tts;
  
  const CommunicationBoard({
    Key? key,
    required this.symbols,
    required this.tts,
  }) : super(key: key);

  @override
  State<CommunicationBoard> createState() => _CommunicationBoardState();
}

class _CommunicationBoardState extends State<CommunicationBoard> {
  final List<String> _sentence = [];

  void _onSymbolTap(BoardSymbol symbol) async {
    setState(() => _sentence.add(symbol.label));
    // Feedback háptico + sonoro imediato
    HapticFeedback.lightImpact();
    await widget.tts.speak(symbol.label);
  }

  void _speakSentence() async {
    final phrase = _sentence.join(' ');
    await widget.tts.setSpeechRate(0.45); // velocidade reduzida
    await widget.tts.speak(phrase);
    setState(() => _sentence.clear());
  }

  @override
  Widget build(BuildContext context) {
    return Semantics(
      container: true,
      label: 'Prancha de comunicação com ${widget.symbols.length} símbolos',
      child: GridView.builder(
        gridDelegate: const SliverGridDelegateWithFixedCrossAxes(
          crossAxisCount: 3,
          childAspectRatio: 1.0,
          mainAxisSpacing: 8,
          crossAxisSpacing: 8,
        ),
        itemCount: widget.symbols.length,
        itemBuilder: (ctx, i) {
          final s = widget.symbols[i];
          return _SymbolTile(
            symbol: s,
            onTap: () => _onSymbolTap(s),
          );
        },
      ),
    );
  }
}

class _SymbolTile extends StatelessWidget {
  final BoardSymbol symbol;
  final VoidCallback onTap;
  
  const _SymbolTile({required this.symbol, required this.onTap});

  @override
  Widget build(BuildContext context) {
    return Semantics(
      button: true,
      label: symbol.label,
      child: Material(
        color: symbol.bgColor,
        borderRadius: BorderRadius.circular(16),
        child: InkWell(
          onTap: onTap,
          child: Column(
            mainAxisAlignment: MainAxisAlignment.center,
            children: [
              Icon(symbol.icon, size: 48, color: symbol.fgColor),
              const SizedBox(height: 8),
              Text(symbol.label, style: TextStyle(color: symbol.fgColor)),
            ],
          ),
        ),
      ),
    );
  }
}

class BoardSymbol {
  final String label;
  final IconData icon;
  final Color bgColor;
  final Color fgColor;
  BoardSymbol({required this.label, required this.icon, 
    required this.bgColor, required this.fgColor});
}

Note três decisões que costumo repetir em projetos de acessibilidade:

• Taxa de fala em 0.45: default do TTS é rápido demais para crianças processarem
• HapticFeedback.lightImpact(): reforça a ação para usuários com baixa visão
• Semantics em todos os níveis: leitores de tela precisam navegar o grid de forma lógica

Erros comuns que devs cometem em apps de CAA

Ao longo da minha carreira, vi os mesmos deslizes se repetirem. Anote os que mais aparecem em revisões de código:

Comparação com alternativas existentes

O mercado de CAA é dominado por soluções proprietárias caras: Proloquo2Go, TouchChat, Pictello. Cada uma custa entre R$ 200 e R$ 600, fora o tablet dedicado. O Papuguinho entra nesse mercado com uma proposta agressiva: gratuito, multiplataforma e com código aberto no roadmap.

Quando comparo tecnicamente, vejo que o diferencial do Papuguinho não é tecnologia superior — é modelo de distribuição. Um app open source escrito em Flutter pode ser compilado em casa por qualquer família, rodando offline, sem assinatura. Isso muda completamente o acesso em comunidades de baixa renda, onde o público TEA é desproporcionalmente desatendido.

Roadmap e implicações para a comunidade

O anúncio no Br-linux.org menciona versões planejadas para macOS, iOS e Linux, além da publicação no GitHub. Para nós, devs, isso abre três frentes interessantes:

1. Contribuição direta: o repositório (quando aberto) deve seguir Conventional Commits para facilitar releases automatizados
2. Localização colaborativa: Libras, Braille digital e variantes regionais de português podem entrar via PRs
3. Plugins comunitários: integrações com ARASAAC (banco de símbolos pictográficos) seriam naturais

Na minha experiência, projetos open source de impacto social precisam de documentação de onboarding sólida desde o dia um. Espero que o time já esteja preparando um CONTRIBUTING.md decente.

FAQ — Perguntas que devs realmente fazem

Por que Flutter e não React Native ou Kotlin nativo?

Flutter compila para Windows, macOS, Linux e mobile a partir de uma única base de código. Para um projeto acadêmico com recursos limitados, isso reduz custo de manutenção drasticamente. React Native ainda sofre com suporte desktop fragmentado.

Qual o custo real de manter Firebase para esse tipo de app?

Para a escala atual (provavelmente algumas centenas de famílias), o plano Spark é suficiente. O custo começa a importar quando há milhares de usuários ativos simultâneos com sincronização pesada de pranchas customizadas.

O Papuguinho pode substituir um terapeuta?

Não, e nem deve. CAA é uma ferramenta辅助 à mediação profissional. O bom design reconhece isso: o app precisa gerar relatórios de uso que o terapeuta possa interpretar.

Como testar acessibilidade em Flutter?

Use o SemanticsDebugger ativando-o no MaterialApp, simule VoiceOver/TalkBack, e teste com usuários reais em sessões curtas. Nada substitui observação em campo.

O código aberto não traz risco de forks abandonados?

Traz, mas o tradeoff vale a pena. Projetos como o KDE e o próprio Linux mostram que forks múltiplos podem ser benéficos quando há governança clara (CLA, RFC process).

Gostou? Me segue no GitHub e deixa um comentário se tiver dúvida ou quiser aprofundar algum ponto. Se você trabalha com Flutter ou acessibilidade, vale acompanhar de perto — projetos como esse mostram que código bem escrito pode mudar vidas concretas.