Mini-Projecto · Uma app móvel no-code de raiz
Contexto
A associação de estudantes quer uma app móvel simples para o dia a dia da escola — algo que os alunos usem mesmo. Foste tu o/a escolhido/a para a conceber e desenvolver em no-code (Thunkable ou MIT App Inventor), de raiz.
Trabalhas individualmente ou a pares e entregas a app a funcionar (no emulador ou telemóvel) mais um pequeno dossiê (fluxos, wireframes e testes). Escolhe uma ideia útil, por exemplo: lista de tarefas/estudo, registo de presenças, mural de eventos, ou consulta do horário.
Requisitos
Funcionais
- Pelo menos 2 ecrãs com navegação entre eles.
- Um formulário/entrada de dados (caixa de texto + botão).
- Uma lista que mostra dados e cresce com o uso.
- Guardar os dados (base de dados local ou nuvem) — persistem ao fechar.
- Pelo menos uma condição (
se/então) na lógica. - Uso de um sensor OU integração de uma API externa.
Não-funcionais
- Interface simples e legível (UX/UI), responsiva.
- Tratamento de casos vazios/inválidos (não deixar adicionar em branco).
- App testada no emulador; erros corrigidos.
- Só as permissões necessárias; nota RGPD se recolher dados.
Fases
Fase 1 · Ideia e planeamento (2h) Escolher a app, desenhar o fluxo e os wireframes dos ecrãs.
Fase 2 · Interface (Designer) (3h) Montar os ecrãs com os componentes (caixas, botões, lista, imagem).
Fase 3 · Lógica (Blocks) (4h) Programar os eventos: navegação, adicionar à lista, condições, variáveis.
Fase 4 · Dados + sensor/API (2h) Guardar/ler da base de dados e usar um sensor (ex.: câmara/GPS) ou uma API.
Fase 5 · Testes e melhoria (2h) Testar no emulador (fluxos, casos vazios, tamanhos de ecrã), corrigir e melhorar a UX.
Fase 6 · Apresentação (1h) Demonstrar a app e explicar as decisões do dossiê.
Critérios de avaliação
| Critério | Peso |
|---|---|
| Planeamento (fluxos + wireframes) | 15% |
| Interface (UX/UI, responsiva) | 20% |
| Lógica (eventos, condição, variáveis, lista) | 25% |
| Dados + sensor/API | 20% |
| Testes, correções e tratamento de erros | 10% |
| Dossiê e apresentação | 10% |
Erros comuns
- Construir os ecrãs sem planear os fluxos.
- Não guardar os dados — a app esquece tudo ao reabrir.
- Deixar adicionar em branco (sem a condição
se). - Testar só num ecrã e ignorar a responsividade.
- Pedir permissões que a app não usa.
Reflexão
No dossiê, responde: que decisão de UX tomaste para a app ser fácil de usar? E qual foi o erro mais difícil de encontrar no debugging, e como o resolveste?