Aula 36 · Semana 15 · Segunda, 14 de dezembro de 2026 · 16:00 às 18:00

Apresentações e defesas (I)

Primeiro dia de defesas do projeto Tempo Açores. Cada grupo tem 10 minutos de apresentação com demonstração no telemóvel, 5 minutos de perguntas dirigidas a cada membro e 2 minutos de feedback. A ordem é a do sorteio da aula anterior.

Ordem: sorteio de 09/12

No fim desta aula consegues

Apresentar o projeto do teu grupo em 10 minutos, com demo no telemóvel e decisões técnicas justificadas.
Responder, individualmente, a perguntas sobre o código que assinaste.
Ouvir e usar feedback imediato sobre a apresentação e o produto.
Avaliar, como espectador, o que funciona e o que não funciona nas defesas dos outros grupos.

Ordem e tempos

Hora	O quê	Notas
16:00 a 16:05	Abertura	Regras da sala, confirmação de presenças, primeiro grupo liga o telemóvel ao projetor.
16:05 a 17:00	Grupos 1 a 3	17 minutos por grupo: 10 de apresentação, 5 de perguntas, 2 de feedback. 1 minuto de troca.
17:00 a 17:10	Pausa	O grupo 4 prepara a projeção durante a pausa.
17:10 a 18:00	Grupos 4 a 6	Mesmo formato. Os restantes grupos defendem quarta, 16/12, às 08:30.

Os números correspondem à ordem sorteada, publicada no Moodle a 09/12.
Aos 10 minutos a apresentação é cortada onde estiver; aos 15 terminam as perguntas. O cronómetro está visível para todos.
Um grupo que não esteja pronto quando é chamado passa para o fim do dia; se não houver tempo, para quarta, com penalização no critério de processo.

Regras da sala

Todos presentes o tempo todo. Não se entra nem sai durante uma defesa; quem precisa de sair, sai na troca entre grupos.
Silêncio e telemóveis em silêncio na plateia. O único telemóvel com som é o que está no projetor.
Cada grupo entrega ao docente, antes de começar: o link do repositório com a tag v1.0.0, o link do release no App Distribution e o vídeo de reserva numa pen.
A demo é em release, no telemóvel, projetado. Se a projeção falhar, o grupo tem 20 segundos para passar ao vídeo. O relógio não pára.
As perguntas são dirigidas a uma pessoa pelo nome. Só essa pessoa responde. Um colega pode acrescentar depois, se o docente permitir.
A plateia preenche a grelha de feedback da aula 35 para cada grupo e entrega-a no fim. Conta para o critério de processo de quem a preenche.

O que a rubrica valoriza hoje

Critério da rubrica	O que o júri procura na defesa
Funcionalidade (35 %)	Os mínimos a funcionar na demo: localidades, previsão, avisos, favoritos sincronizados, offline. Extras mostrados, não só anunciados.
Qualidade e arquitetura (25 %)	Decisões técnicas com o porquê; saber onde vive cada coisa no código; CI verde na tag.
Experiência de utilização (15 %)	Estados de loading, erro e vazio mostrados sem pedir; modo avião com dados antigos marcados; app coerente e legível projetada.
Processo (15 %)	Já está avaliado pelo histórico; hoje confirma-se: cada membro responde pelos seus PRs.
Distribuição e apresentação (10 %)	Build assinado distribuído a testers; 10 minutos bem usados; demo fluida; perguntas respondidas com clareza.

A nota individual ajusta a do grupo com base nas perguntas de hoje e nos PRs. Detalhes em Avaliação.

Perguntas típicas: o que cada membro deve esperar

Sobre o teu PR: "Explica-me esta função" ou "porque escolheste fazer assim?", com o GitHub aberto no teu código. Uma por membro, garantida.
Sobre resiliência: o que acontece sem rede, com 429, com 500, com JSON que não é o esperado. A resposta certa aponta para o sealed class de estados e para o retry.
Sobre segurança: onde está o token, o que aconteceria se estivesse em shared_preferences, o que há no repositório que não devia estar.
Sobre testes e CI: quantos testes, o que testam, o que o CI corre em cada PR, o que não está testado e porquê.
Sobre a matéria do teste 2 aplicada ao projeto: permissões de localização, WorkManager, deep links, versionamento, o que a Play Console ia exigir para publicar.
Sobre o que falta: "o que fariam com mais uma sprint?", com uma resposta concreta e ordenada.

Responder curto, concreto e com o ficheiro à mão. "Não sei, mas ia ver em X" uma vez; inventar, nunca.

Feedback imediato: dois minutos por grupo

Do docente, 90 segundos: uma coisa que correu bem e que devem repetir na próxima apresentação que fizerem na vida; uma coisa concreta que faltou ou correu mal, e o que teria evitado.
Da plateia, 30 segundos: um colega de outro grupo lê a frase livre da sua grelha. Sem debate, sem resposta do grupo.
O feedback é sobre a apresentação e o produto, não sobre a nota. As notas do projeto saem depois de quarta, com todas as defesas feitas.
Os grupos de quarta ouvem tudo hoje. Podem, e devem, ajustar a apresentação com base no que virem. Não é injusto: é o que qualquer equipa faz quando vê a concorrência apresentar primeiro.
As grelhas da plateia são entregues ao docente no fim e chegam ao grupo por e-mail até quarta.

Até à próxima aula

Para fazer

Grupos de quarta: ajustar a apresentação com o que viram hoje; ensaiar a demo mais uma vez com o cronómetro; confirmar o vídeo de reserva.
Grupos de hoje: nada de código. Só o README, se o feedback apontou algo que lá falta.
Todos: quarta às 08:30, presença obrigatória até ao encerramento às 10:30.

Para ler

Flutter app architecture: para comparar as vossas decisões com a recomendação oficial antes das perguntas.
Android app quality: a checklist de qualidade da Google, que é o que a rubrica resume.
Human Interface Guidelines: para a pergunta "porque é que este ecrã é assim?".
Testing Flutter apps (docs.flutter.dev): os tipos de teste e o que cada um cobre, para responder com precisão à pergunta sobre testes e CI.
Set up an open, closed, or internal test (Play Console): os tracks e o teste fechado obrigatório para contas novas, para a pergunta "o que a Play Console ia exigir para publicar?".