Apresentações e defesas (II) e encerramento

No fim desta aula consegues

• Defender o projeto do teu grupo e responder pelo teu código, se és de um dos grupos de hoje.
• Nomear o que esta UC cobriu, o que ficou de fora, e o que precisas de aprofundar sozinho.
• Transformar o projeto num item de portefólio que um empregador consegue avaliar em dois minutos.
• Saber por onde continuar: publicar a app, comunidades, e onde aparecem as vagas de mobile.

Ordem e tempos

Os números continuam a ordem sorteada a 09/12. As regras da sala são as de segunda: todos presentes, telemóveis em silêncio, demo em release no telemóvel, perguntas dirigidas pelo nome, grelha de feedback preenchida pela plateia.

O que a rubrica valoriza, em resumo

• Funcionalidade: os mínimos a funcionar na demo, extras mostrados e não só anunciados.
• Qualidade e arquitetura: decisões com o porquê e a alternativa rejeitada; saber onde cada coisa vive no código; CI verde na tag v1.0.0.
• Experiência de utilização: loading, erro e vazio mostrados sem pedir; modo avião com dados antigos marcados.
• Processo: cada membro responde pelos seus PRs; o histórico já contou a maior parte da história.
• Distribuição e apresentação: build assinado nos telemóveis dos testers; 10 minutos bem usados; respostas curtas e concretas.

Os grupos de hoje tiveram dois dias a mais e viram seis defesas. O júri espera que isso se note.

Perguntas típicas: o que cada membro deve esperar

• Sobre o teu PR: uma pergunta com o teu código projetado. "Explica-me esta linha", "porque não usaste X?".
• Sobre resiliência: sem rede, 429, 500, JSON inesperado; o que o utilizador vê em cada caso.
• Sobre segurança: onde está o token, o que há no repositório que não devia estar, que permissões pedem e quando.
• Sobre testes e CI: o que está testado, o que não está, o que corre em cada PR.
• Sobre a matéria do teste 2: as três perguntas mais falhadas, aplicadas ao vosso código. Quem esteve na correção comentada sabe quais são.
• Sobre o que se segue: "o que faltava para pôr isto na Play Store?", com a resposta a passar pela ficha, data safety, classificação e tracks da aula 32.

Balanço: o que esta UC cobriu

• O que torna mobile diferente: ecrã pequeno, bateria, rede intermitente, ciclo de vida imposto, sandbox e permissões, lojas como controlo de publicação. Foi a aula 1 e voltou em todas as outras.
• Flutter e Dart: widgets, estado, navegação, layouts, temas, i18n, acessibilidade, testes. Uma base de código para duas plataformas, e o hot reload como forma de aprender.
• Uma app real de ponta a ponta: API com autenticação, cache offline, resiliência a falhas, localização e mapa, notificações, deep links, background, canais nativos.
• O que está à volta do código: arquitetura, git em equipa, PRs, CI, observabilidade, segurança e privacidade, build e assinatura, distribuição a testers, lojas.
• Processo: três sprints, reviews, retros, um freeze com hora, uma defesa. Foi a parte mais parecida com um emprego.

37 aulas, 81 horas, uma app instalada no telemóvel de outra pessoa.

O que ficou de fora, e o que só se aprende com prática

• Não coubemos: animações avançadas, Cupertino e apps que seguem o iOS ao milímetro, widgets de ecrã inicial e Live Activities, wearables, desktop e web com Flutter, gRPC e GraphQL na prática, testes E2E com Patrol ou Maestro, code push em produção.
• Só se aprende com tempo: manter uma app dois anos, migrar entre versões do Flutter, responder a uma review de uma estrela, uma app com 100 mil utilizadores a falhar num modelo de telemóvel que nunca viste.
• Não é Flutter: nativo Swift e Kotlin continuam a ser valiosos, e um programador mobile experiente lê os dois. O que aprenderam sobre ciclo de vida, permissões, lojas e assinatura é igual lá.
• O que muda depressa: packages, versões, a UI das consolas. O que não muda: rede falha, bateria acaba, o utilizador não lê, a loja rejeita.

Próximos passos: portefólio e publicar a app

1. O repositório é o portefólio. README com screenshots, GIF da app, arquitetura em dez linhas e o teu nome nos PRs. Torna-o público se o grupo concordar; um recrutador abre o README e decide em dois minutos.
2. Um projeto só teu, pequeno e acabado, vale mais do que três a meio. Uma app que resolve um problema teu, publicada, com 20 utilizadores reais, é uma entrevista inteira.
3. Publica. Conta Google Play (25 USD, uma vez): ficha, data safety, classificação, testers, produção. Já sabes fazer tudo isto. A App Store custa 99 USD por ano e um Mac; faz sentido quando tiveres algo que o justifique.
4. Mantém. Atualiza o Flutter quando sai uma versão, responde às reviews, olha para os vitals. Seis meses de uma app mantida ensinam mais do que qualquer curso.
5. Escreve sobre o que aprendeste: um post sobre o modo caos e o retry, ou sobre a migração para a API v2. Mostra que sabes explicar, que é metade do trabalho.

Próximos passos: comunidades e vagas

• Comunidades: a página de comunidade em flutter.dev/community lista o Discord oficial, o r/FlutterDev e os meetups. Em Portugal, os grupos Flutter Portugal e os GDG (Google Developer Groups) de Lisboa e Porto fazem encontros regulares, quase sempre com transmissão. Ir a um e fazer uma pergunta é o passo mais rentável que podes dar este ano.
• Contribuir: um bug reportado com reprodução num package do pub.dev, um PR de documentação, uma tradução. Fica no teu GitHub para sempre e ensina a ler código dos outros.
• Onde estão as vagas: LinkedIn com "Flutter" e "mobile" em Portugal e remoto; itjobs.pt e landing.jobs; as páginas de carreiras das empresas que já vos falei que usam Flutter em produção. Muitas vagas de mobile júnior pedem "Flutter ou React Native ou nativo": o que aprenderam serve para as três.
• O que as entrevistas de mobile perguntam: ciclo de vida, estado, o que acontece sem rede, onde guardas um token, como testas, como publicas. É o programa desta UC. Levem o projeto e mostrem-no no telemóvel.
• O docente continua contactável pelo e-mail institucional para dúvidas, cartas de recomendação e para saber que a app está na loja.

Encerramento