Sebenta · Conceber e desenvolver aplicações móveis no-code (UC03815)

Introdução

Esta sebenta ensina a criar aplicações móveis sem escrever código de texto — usando plataformas no-code de programação por blocos, como o Thunkable ou o MIT App Inventor. "Sem código" não significa "sem lógica": vais usar exatamente os mesmos conceitos de qualquer linguagem — variáveis, condições, ciclos, listas — só que sob a forma de peças visuais que se encaixam.

O percurso é o de quem constrói uma app a sério: planear a estrutura e os fluxos, desenhar a interface (UX/UI e wireframes), programar as ações com blocos, integrar dados e serviços, e testar em emulador antes de publicar. No fim, deves conseguir levar uma ideia de app do papel a um .apk a funcionar.

Objetivos (referencial): planear a estrutura lógica da app e os fluxos de interação; desenvolver o design da interface; integrar dados e programar a funcionalidade; e testar a app.

1. O que é o no-code

No-code é criar software arrastando componentes e ligando blocos de lógica visual, em vez de escrever texto numa linguagem. As vantagens: rapidez (um protótipo funcional em horas), acessibilidade (não é preciso dominar a sintaxe de uma linguagem) e foco na lógica e na experiência, não na escrita de código.

Mas atenção: a lógica de programação — condicionais, ciclos, variáveis, estruturação de processos e tomada de decisão — continua a ser necessária. O no-code muda a forma (blocos em vez de texto), não o raciocínio. Plataformas comuns: Thunkable e MIT App Inventor (blocos, ideais para escola), e Glide, Adalo ou AppSheet (mais orientadas a dados).

2. Anatomia de uma app móvel

Uma app organiza-se em ecrãs (screens), e cada ecrã tem componentes. Os principais (referencial):

• Design e acessibilidade — layout, cores, contraste, tamanhos de toque.
• Multimédia — imagens, som, vídeo.
• Autenticação e acesso — login/registo.
• Conteúdos, navegação e ligações — o que se mostra e como se salta entre ecrãs.
• Sensores — GPS, câmara, acelerómetro.

Cada componente tem propriedades (o que é: texto, cor, tamanho) e eventos/ações (o que faz: "quando clicado, fazer…"). Programar a app é, essencialmente, reagir a eventos.

3. Planear: estrutura lógica e fluxos

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

• O fluxo de interação — o caminho do utilizador: por exemplo, Login → Lista → Detalhe, com um desvio para Adicionar.
• A estrutura lógica — que ecrãs existem e como se ligam.

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

Planear os fluxos evita ecrãs "sem saída", botões que não levam a lado nenhum e lógica confusa. É a fase mais barata para corrigir a app.

4. UX/UI e wireframing

UX (experiência do utilizador) responde a "é fácil e faz sentido usar?"; UI (interface) é o aspeto visual. Princípios de boa UX/UI:

• Simplicidade — um ecrã, um objetivo.
• Consistência — os mesmos elementos comportam-se igual em toda a app.
• Feedback — o utilizador percebe que a ação aconteceu.
• Acessibilidade — contraste suficiente, letras e botões grandes o suficiente para o toque.

O wireframe é o esboço de cada ecrã (posição de títulos, listas, botões) sem cores nem conteúdo real. Um protótipo liga os wireframes para simular a navegação. Fazem-se em Figma, diagrams.net ou papel, e validam a ideia antes de programar.

5. Programação por blocos

Nas plataformas de blocos há dois espaços:

• O Designer — arrasta-se os componentes para o ecrã (botão, caixa de texto, lista, imagem, mapa).
• Os Blocks — programa-se a lógica: o que cada componente faz.

Tudo reage a eventos: "Quando Botão.Clicado, fazer…". Exemplo — adicionar uma tarefa a uma lista:

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

Os blocos organizam-se por categorias: controlo (se/então, repetir, esperar), lógica (e, ou, não), matemática, texto, listas, variáveis, procedimentos (funções reutilizáveis), tempo e cores. E, como em qualquer linguagem, existem as três estruturas de controlo: sequência, decisão e repetição.

Variáveis e listas

Uma variável guarda um valor (um contador, o nome do utilizador); uma lista guarda vários itens (as tarefas, os produtos).

inicializar contador = 0
Quando Botão.Clicado → contador = contador + 1; mostrar contador

As listas ligam-se a componentes visuais (por exemplo, um ListViewer) para mostrar dados que mudam.

6. Dados e bases de dados

Uma app útil precisa de memória — guardar dados entre sessões:

• Local — TinyDB / armazenamento do dispositivo: guarda no telemóvel, entre aberturas.
• Nuvem — Firebase, Google Sheets ou Airtable: dados partilhados entre utilizadores e dispositivos.

Configura-se a base de dados e usam-se blocos para guardar e recuperar informação. Por exemplo, gravar a lista de tarefas para que não desapareça quando a app fecha, e voltar a lê-la quando abre.

7. Integrar APIs e automatizar

• Uma API é um serviço externo que a app consulta — meteorologia, mapas, câmbios, pagamentos. Liga-se por blocos: a app faz um pedido, recebe a resposta e mostra-a. Integram-se serviços tanto por API como pelas ferramentas de programação por blocos da plataforma.
• A automatização de fluxos encadeia serviços e trata tarefas repetitivas — por exemplo, ao submeter um formulário, guardar o registo e enviar um email de confirmação. Ferramentas como Make ou Zapier ajudam.

8. Sensores e multimédia

O que distingue uma app móvel de um site são os sensores do dispositivo: GPS (localização), câmara (fotos, leitura de QR codes) e acelerómetro (movimento). A app reage aos dados destes sensores.

A multimédia (imagens, som, vídeo) enriquece os ecrãs — mas deve ser otimizada (imagens comprimidas) para a app não ficar pesada.

9. Emulador, testes e debugging

O emulador simula um telemóvel no computador, permitindo testar sem dispositivo físico. Testa-se:

• Em vários sistemas operativos (Android/iOS) e tamanhos de ecrã — a interface é responsiva?
• Botões, fluxos e ações — cada caminho funciona? Nada rebenta?

O debugging é encontrar e corrigir falhas: ler as mensagens de erro, isolar o ecrã/bloco problemático, usar Labels temporários para mostrar valores (o "print" do no-code), corrigir e voltar a testar. Os testes também servem para melhorar a experiência: se os utilizadores se perdem num ecrã, ajusta-se.

10. Publicar e legislação

Terminada e testada, a app exporta-se como APK (Android) ou publica-se nas lojas (Play Store / App Store), com ícone, nome e as permissões que pede ao utilizador. Do ponto de vista legal: pedir só as permissões necessárias, ter política de privacidade (RGPD) se recolher dados pessoais, e respeitar os direitos de autor dos elementos multimédia usados.

Erros comuns

• Começar a arrastar componentes sem planear os fluxos e wireframes.
• Achar que no-code dispensa a lógica — não dispensa.
• Não guardar dados — a app esquece tudo ao fechar.
• Imagens enormes → app lenta.
• Testar só num ecrã/telemóvel e esquecer a responsividade.
• Pedir permissões a mais e esquecer a política de privacidade.

Glossário

• No-code — criar software sem escrever código de texto.
• Componente — elemento de um ecrã (botão, lista, imagem).
• Bloco — peça visual de lógica que se encaixa.
• Evento — algo que dispara uma ação (ex.: clique).
• Screen (ecrã) — uma "página" da app.
• Variável / lista — guarda um valor / vários itens.
• UX / UI — experiência de utilização / interface visual.
• Wireframe / protótipo — esboço de ecrã / esboços ligados navegáveis.
• API — serviço externo que a app consulta.
• TinyDB / Firebase — base de dados local / na nuvem.
• Sensor — GPS, câmara, acelerómetro.
• Emulador — telemóvel simulado no computador.
• APK — ficheiro de instalação de uma app Android.

Síntese

Fazer uma app no-code segue o mesmo método de qualquer software: planear (fluxos, wireframes) → desenhar a interface (UX/UI) → programar com blocos (eventos, condições, variáveis, listas) → integrar dados, APIs e sensores → testar no emulador e corrigir → publicar. A ferramenta é visual; o raciocínio é o de sempre. Quem domina a lógica adapta-se a qualquer plataforma no-code.

Exercícios resolvidos

1. Verdadeiro ou falso: "no-code não usa lógica de programação". Justifica.

Resolução: Falso. O no-code usa a mesma lógica (condições, ciclos, variáveis, listas) — apenas sob a forma de blocos visuais em vez de texto.

2. Desenha o fluxo de uma app de lista de compras: abrir → ver lista → adicionar item → item aparece na lista.

Resolução: [Lista] → [Adicionar item] → (volta a) [Lista]. O ecrã principal é a Lista; o botão "+" abre Adicionar; ao confirmar, o item é acrescentado à lista e volta-se ao ecrã Lista.

3. Escreve, em pseudo-blocos, a ação "quando se clica em Adicionar, se a caixa não estiver vazia, junta o texto à lista e limpa a caixa".

Resolução: Quando Botão_Adicionar.Clicado se Caixa.Texto ≠ "" então adicionar Caixa.Texto à lista_compras Caixa.Texto = ""

4. Que componente/sensor usarias para uma app que mostra "lojas perto de mim"? E que serviço externo?

Resolução: o sensor GPS (localização) + um mapa, e uma API de mapas (ex.: Google Maps) para mostrar as lojas próximas.

5. A app funciona no teu telemóvel mas num ecrã pequeno os botões saem do sítio. Que problema é e como o resolves?

Resolução: falta de responsividade. Resolve-se usando layouts que se adaptam (percentagens/proporções em vez de posições fixas) e testando em vários tamanhos de ecrã no emulador.