Bloco 1 · No-code

O que é o no-code

Criar apps sem escrever código de texto — arrastando componentes e ligando blocos de lógica visual.

• Rápido: um protótipo funcional em horas.
• A lógica (condicionais, ciclos, variáveis) continua a existir — só é visual.
• Ideal para MVPs, apps internas, projetos escolares.

Plataformas: Thunkable, MIT App Inventor, Glide, Adalo, AppSheet.
Usamos as de blocos (Thunkable / App Inventor): componentes + blocos + emulador.

Anatomia de uma app móvel

Componentes principais (referencial):

• Screens (ecrãs) — as "páginas" da app.
• Design e acessibilidade — layout, cores, contraste.
• Multimédia — imagens, som, vídeo.
• Autenticação e acesso — login.
• Conteúdos, navegação e ligações entre ecrãs.
• Sensores — GPS, câmara, acelerómetro.

Cada componente tem propriedades (o que é) e eventos/ações (o que faz).

Bloco 2 · Planear

Estrutura lógica e fluxos

Antes de construir, define-se o que a app faz e como se navega:

• Fluxo de interação — o caminho do utilizador (abrir → login → lista → detalhe).
• Estrutura lógica — que ecrãs existem e como se ligam.

[Login] → [Lista] → [Detalhe]
             │
          [Adicionar]

Planear os fluxos evita ecrãs "sem saída" e lógica confusa.

UX/UI — experiência e interface

• UX (experiência) — a app é fácil, rápida e faz sentido de usar?
• UI (interface) — o aspeto: layout, cores, tipografia, botões.

Princípios: simplicidade, consistência, feedback (o utilizador sabe o que aconteceu), toques grandes o suficiente, e acessibilidade (contraste, tamanho de letra).

Boa UX = o utilizador atinge o objetivo sem pensar.

Wireframing

Esboço dos ecrãs antes de os construir: onde ficam títulos, listas, botões — sem cores nem conteúdo real.

• Faz-se em Figma, diagrams.net ou papel.
• Organiza o tipo de conteúdos e as ligações entre ecrãs.
• Valida a ideia com o "cliente" antes de programar.

Um protótipo = wireframes ligados, para simular a navegação.

Bloco 3 · Programar por blocos

As plataformas

• Thunkable / MIT App Inventor — arrastar componentes para o ecrã (botão, lista, imagem, mapa) e programar as ações com blocos encaixáveis.
• Designer (o ecrã) + Blocks (a lógica).
• Testa-se em tempo real num telemóvel ou emulador.

Não é "brincar": é a mesma lógica de qualquer linguagem, com peças visuais.

Elementos da programação por blocos

Os blocos organizam-se por categorias (referencial):

Eventos, condições e ciclos

Tudo reage a eventos: "Quando Botão.Clicado → fazer …".

Quando Botão_Enviar.Clicado
  se Caixa.Texto ≠ "" então
    adicionar Caixa.Texto à Lista_tarefas
    limpar Caixa.Texto

As três estruturas de sempre: sequência, decisão (se/então) e repetição (para cada / enquanto).

Variáveis e listas

• Variável — guarda um valor (contador, nome do utilizador).
• Lista — guarda vários itens (tarefas, produtos).

inicializar contador = 0
quando Botão.Clicado → contador = contador + 1
mostrar contador em Label

As listas ligam-se a componentes visuais (ListViewer) para mostrar dados dinâmicos.

Bloco 4 · Dados e integrações

Guardar dados

Uma app precisa de memória:

• Local — TinyDB / armazenamento do dispositivo (guarda entre sessões).
• Nuvem — Firebase, Google Sheets, Airtable (partilhado entre utilizadores).

Configura-se a base de dados e usam-se blocos para guardar e recuperar informação (ex.: gravar a lista de tarefas para não se perder ao fechar).

Integrar APIs e automatizar

• API — um serviço externo que a app consulta (meteorologia, mapas, pagamentos). Liga-se por blocos: pedido → resposta → mostrar.
• Automatização de fluxos — encadear serviços e tarefas repetitivas (ex.: ao submeter um formulário, guardar + enviar email).

Ferramentas: blocos "Web/API" da plataforma, ou serviços como Make/Zapier.

Sensores e multimédia

• Sensores — GPS (localização), câmara (foto/QR), acelerómetro (movimento). A app reage aos dados do dispositivo.
• Multimédia — imagens, som e vídeo nos ecrãs; editar/otimizar imagens antes de as usar.

São estes que tornam uma app móvel diferente de um site.

Bloco 5 · Testar e publicar

Emulador e testes

• Emulador — simula um telemóvel no computador para testar sem dispositivo físico.
• Testar em vários sistemas operativos (Android/iOS) e tamanhos de ecrã (responsividade).
• Verificar botões, fluxos e ações: cada caminho funciona? Nada rebenta?

Testar cedo e muitas vezes — os erros mais baratos são os apanhados a tempo.

Debugging

Encontrar e corrigir falhas:

• Ler as mensagens de erro da plataforma.
• Isolar o ecrã/bloco com problema.
• Usar Labels temporários para mostrar valores (o "print" do no-code).
• Corrigir e voltar a testar.

Melhorar também a experiência do utilizador com base no que se observa nos testes.

Publicar e legislação

• Exportar o APK (Android) ou publicar nas lojas (Play Store / App Store).
• Ícone, nome, permissões pedidas ao utilizador.
• Legislação: pedir só as permissões necessárias, ter política de privacidade (RGPD) se recolher dados, e respeitar direitos de autor dos elementos usados.