UC02210

Criar e desenvolver conteúdos, animações e aplicações multimédia para dispositivos móveis

Do contexto móvel à publicação: interfaces, interatividade, desempenho, PWA e acessibilidade

Curso profissional · 25h · Multimédia

Plano

  1. O contexto móvel
  2. Abordagens de desenvolvimento
  3. Configurar a ferramenta de desenvolvimento
  4. Usabilidade e interface móvel
  5. Viewport e desenho adaptativo
  6. Gestos e estados de toque
  7. Programar a interatividade
  8. Animação e movimento acessível
  9. Desempenho e métricas reais da web
  10. Otimização de imagens e tipos de letra
  11. PWA: manifest e service worker
  12. Acessibilidade móvel
  13. Testar e depurar
  14. Exportar e publicar

Bloco 1 · O contexto móvel

O que distingue o móvel do desktop

Desenhar para móvel não é encolher um site de computador. O contexto de uso muda por completo:

  • Entrada por toque, dedo em vez de rato, área de contacto imprecisa.
  • Ecrã pequeno, retrato ou paisagem, várias densidades.
  • Rede variável: 3G, 4G, 5G, wi-fi instável.
  • Bateria limitada e utilização com uma mão só, muitas vezes em movimento.

Cada decisão de desenho e de código desta UC responde a uma destas diferenças.

Sensores e interrupções

O telemóvel traz capacidades que o desktop não tem, e vive rodeado de interrupções:

  • Sensores: GPS, acelerómetro, câmara, microfone.
  • Interrupções: chamadas, notificações de outras aplicações.
  • Contexto de uso: em pé, a andar, com pressa, com má cobertura.

Uma boa aplicação móvel assume que o utilizador pode ser interrompido a qualquer momento e recupera o estado sem perder o trabalho feito.

Bloco 2 · Abordagens de desenvolvimento

Nativa, híbrida, web app e PWA

Quatro caminhos para chegar ao utilizador, com compromissos diferentes:

  • Nativa (Swift, Kotlin): desempenho máximo, acesso total ao hardware, um código por plataforma.
  • Híbrida (React Native, Flutter, Ionic): um código, várias plataformas, aproxima-se do nativo.
  • Web app: corre no browser, sem instalação nem loja.
  • PWA: web app instalável, funciona offline, notificações push.

Exemplo resolvido · escolher a abordagem

Uma escola de música quer uma app para os alunos consultarem horários, marcarem salas e receberem avisos, mesmo com pouca rede no bairro, com orçamento limitado.

Resolução: PWA. Não justifica duas apps nativas; o service worker resolve a rede fraca; as notificações push cobrem os avisos; instala-se direto do browser, sem loja.

Bloco 3 · Configurar a ferramenta de desenvolvimento

O ambiente de trabalho móvel

  • Editor: Visual Studio Code (gratuito) para web app e PWA.
  • IDE nativo: Android Studio (gratuito) e Xcode (gratuito, só macOS).
  • Emuladores e simuladores: AVD Manager (Android), Simulator (iOS).
  • Modo de dispositivo nas DevTools do browser, sem instalar nada.

A primeira linha de qualquer projeto de web ou PWA:

<meta name="viewport" content="width=device-width, initial-scale=1">

Exemplo resolvido · modo de dispositivo no Chrome

  1. Abrir a página, premir F12.
  2. Clicar no ícone de telemóvel (Toggle device toolbar).
  3. Escolher um dispositivo (ex.: iPhone 14, Pixel 7).
  4. Ativar "Slow 3G" no menu de rede.
  5. Recarregar e observar o layout e o tempo de carregamento.

Ferramenta gratuita, incluída em qualquer instalação do Chrome ou do Firefox.

Bloco 4 · Usabilidade e interface móvel

A zona do polegar

O ecrã divide-se em zonas de alcance para quem segura o telemóvel com uma mão:

  • Zona fácil: terço inferior, alcance sem esforço.
  • Zona média: centro do ecrã.
  • Zona difícil: topo e cantos opostos ao polegar.

Regra prática: ações frequentes na zona fácil, informação de leitura mais acima.

Área mínima de toque e navegação

  • Área mínima: 44×44pt (iOS) ou 48×48dp (Android), com espaço à volta.
  • Navegação inferior (bottom navigation) para 3 a 5 secções principais.
  • Menu de hambúrguer para opções secundárias.
  • Ícones reconhecíveis, acompanhados de texto quando ambíguos.

Um dedo não é um cursor de rato: um botão que parece bem desenhado no computador pode ser impossível de tocar no telemóvel.

Exemplo resolvido · corrigir um botão fora da área mínima

Botão "Confirmar" com 60×24px, colado a "Cancelar", sem espaço entre eles.

Resolução: min-height: 48px; min-width: 96px; padding: 12px 24px;, com gap: 16px; entre os dois botões. "Confirmar" fica na zona fácil, "Cancelar" ao lado, menos destacado.

Bloco 5 · Viewport e desenho adaptativo

Media queries e mobile-first

.cartao { flex-direction: column; }

@media (min-width: 768px) {
  .cartao { flex-direction: row; }
}

Boa prática: escrever primeiro o estilo do ecrã pequeno e acrescentar regras com min-width para ecrãs maiores, nunca o inverso.

Unidades relativas e imagens adaptativas

Unidade Relativa a
rem tamanho de letra da raiz
em tamanho de letra do pai
% dimensão do elemento pai
vw / vh largura/altura da janela 
<img src="hero-800.jpg"
     srcset="hero-400.jpg 400w, hero-800.jpg 800w, hero-1200.jpg 1200w"
     sizes="(max-width: 600px) 100vw, 50vw" alt="Capa do evento">

Exemplo resolvido · grelha com breakpoints

.grelha { display: grid; grid-template-columns: 1fr; gap: 1rem; }

@media (min-width: 600px) {
  .grelha { grid-template-columns: repeat(2, 1fr); }
}
@media (min-width: 1024px) {
  .grelha { grid-template-columns: repeat(4, 1fr); }
}

1 coluna no telemóvel, 2 no tablet, 4 no desktop, com o mesmo HTML.

Bloco 6 · Gestos e estados de toque

Gestos comuns

  • Tap: um toque, equivalente ao clique.
  • Double tap: dois toques rápidos, zoom ou "gostar".
  • Long press: menu de contexto ou seleção.
  • Swipe: navega, fecha, revela ações.
  • Pinch: aproxima ou afasta com dois dedos.
  • Drag: move ou reordena.

Estados de toque

.botao { transition: transform 0.1s, background-color 0.1s; }
.botao:active { transform: scale(0.97); }
.botao:focus-visible { outline: 3px solid var(--cor-foco); }
.botao:disabled { opacity: 0.5; pointer-events: none; }

Sem cursor a passar por cima, o feedback imediato ao toque é o que diz ao utilizador que o botão respondeu.

Bloco 7 · Programar a interatividade

Eventos de toque em JavaScript

touchstart, touchmove, touchend, e de forma mais moderna e unificada, os Pointer Events (pointerdown, pointermove, pointerup).

É aqui que o layout desenhado se torna uma aplicação viva: transformar o toque num comportamento programado.

Exemplo resolvido · carrossel com swipe

let inicioX = 0;
carrossel.addEventListener('touchstart', (e) => {
  inicioX = e.touches[0].clientX;
});
carrossel.addEventListener('touchend', (e) => {
  const distancia = e.changedTouches[0].clientX - inicioX;
  if (Math.abs(distancia) > 50) {
    distancia < 0 ? avancarImagem() : recuarImagem();
  }
});

O limiar de 50 pixels evita que um tremor do dedo dispare o gesto sem querer.

Bloco 8 · Animação e movimento acessível

Animar sem engasgar

Animar só transform e opacity, propriedades aceleradas pela GPU, sem forçar o browser a recalcular o layout:

.cartao-entrada {
  transform: translateY(20px);
  opacity: 0;
  transition: transform 0.3s ease-out, opacity 0.3s ease-out;
}
.cartao-entrada.visivel { transform: translateY(0); opacity: 1; }

Evitar animar width, height, top ou left.

Respeitar prefers-reduced-motion

@media (prefers-reduced-motion: reduce) {
  .cartao-entrada { transition: none; transform: none; opacity: 1; }
}

Algumas pessoas têm perturbações vestibulares a quem o movimento causa tonturas reais. Esta media query lê a definição de acessibilidade do sistema operativo.

Bloco 9 · Desempenho e métricas reais da web

Os Core Web Vitals

Métrica Mede Bom
LCP tempo até o maior elemento aparecer até 2,5s
CLS quanto o layout "salta" até 0,1
INP tempo entre toque e resposta até 200ms

Medem a experiência real do utilizador, não a opinião de quem construiu a página.

O que degrada estas métricas em rede móvel

  • LCP alto: imagens grandes, fontes bloqueantes, servidor lento.
  • CLS alto: imagens sem dimensões reservadas, fontes que trocam de tamanho.
  • INP alto: JavaScript pesado, scripts de terceiros, animações mal otimizadas.

Em rede móvel, a latência é maior e cada pedido extra ao servidor custa tempo real.

Exemplo resolvido · diagnosticar um LCP alto

O Lighthouse reporta LCP de 5,8s, com a imagem de fundo do cabeçalho identificada como elemento LCP, a pesar 2,4 MB em PNG sem compressão.

Resolução: converter para WebP e comprimir (para cerca de 180 KB), adicionar <link rel="preload" as="image">. Nova medição: LCP desce para 2,1s.

Bloco 10 · Otimização de imagens e tipos de letra

Imagens leves e no tamanho certo

  • WebP / AVIF em vez de JPEG/PNG para o mesmo aspeto visual.
  • Squoosh (Google) ou TinyPNG, ferramentas gratuitas de compressão.
  • loading="lazy" adia imagens fora do ecrã inicial.
  • width/height no HTML reservam espaço e reduzem o CLS.
<img src="produto.webp" loading="lazy" width="400" height="300" alt="Colar artesanal">

Tipos de letra eficientes

  • font-display: swap: mostra texto com fonte alternativa enquanto a personalizada carrega.
  • Subconjunto de carateres: incluir só os carateres usados.
  • preconnect/preload: avisar o browser cedo.
  • Fontes variáveis: um ficheiro cobre vários pesos.
  • Fontes do sistema: eliminam por completo o download.

Bloco 11 · PWA: manifest e service worker

O manifest.json

{
  "name": "Horário da Escola de Música",
  "short_name": "Horário",
  "start_url": "/",
  "display": "standalone",
  "theme_color": "#1a1e5d",
  "icons": [{ "src": "icone-192.png", "sizes": "192x192", "type": "image/png" }]
}

display: standalone remove a barra de endereço; start_url define o que abre ao tocar no ícone.

O service worker e as estratégias de cache

Estratégia Como funciona
Cache first tenta a cache; só vai à rede se faltar
Network first tenta a rede; usa a cache se falhar
Stale-while-revalidate responde da cache, atualiza depois

Ciclo de vida: install (pré-guardar), activate (limpar caches antigas), fetch (intercetar pedidos).

Exemplo resolvido · service worker com cache first

const CACHE = 'horario-v1';
self.addEventListener('install', (e) => {
  e.waitUntil(caches.open(CACHE).then((c) => c.addAll(['/', '/estilo.css', '/app.js'])));
});
self.addEventListener('fetch', (e) => {
  e.respondWith(caches.match(e.request).then((r) => r || fetch(e.request)));
});

A biblioteca gratuita Workbox (Google) gera estas estratégias sem escrever tudo à mão.

Bloco 12 · Acessibilidade móvel

Contraste, texto e leitores de ecrã

  • Contraste: rácio mínimo de 4,5:1 (WCAG), verificável no WebAIM Contrast Checker.
  • Texto: nunca desativar o zoom (user-scalable=no).
  • Leitores de ecrã: VoiceOver (iOS) e TalkBack (Android); precisam de alt e aria-label.
  • Foco visível: :focus-visible, nunca removido sem substituto.

Exemplo resolvido · corrigir contraste insuficiente

Botão "Ver mais" a cinzento claro (#aaaaaa) sobre fundo branco, rácio de cerca de 2,3:1.

Resolução: escurecer para #5a5a5a, rácio acima de 4,5:1, mantendo a paleta da marca mas com legibilidade garantida.

Bloco 13 · Testar e depurar

Dispositivo real e depuração remota

  • Android + Chrome: USB, "Opções de programador", chrome://inspect.
  • iOS + Safari: USB, "Web Inspector" no telemóvel, menu Programar no Safari do Mac.
  • Lighthouse: audita desempenho, acessibilidade, boas práticas e SEO, gratuito.
  • WebPageTest: mede a partir de redes e localizações reais.

O emulador não substitui um telemóvel real: só ele mostra a rede, a bateria e o toque verdadeiros.

Checklist de compatibilidade

  • Funciona em Android e iOS, em retrato e paisagem.
  • Gestos e alvos de toque respondem em ecrãs pequenos e grandes.
  • A rede lenta ("Slow 3G") não deixa a app inutilizável.
  • Testado com pelo menos um leitor de ecrã.

Bloco 14 · Exportar e publicar

Publicar uma PWA

  1. Alojar em HTTPS (obrigatório para o service worker registar).
  2. Verificar a instalabilidade em DevTools > Application > Manifest.
  3. Testar "Adicionar ao ecrã principal" em Android e iOS.
  4. Empacotar também para lojas com a PWA Builder (Microsoft, gratuita), se necessário.

Publicar uma app híbrida ou nativa

  1. Gerar o pacote: AAB (Android) ou IPA (iOS).
  2. Assinar digitalmente com certificado próprio.
  3. Submeter na Play Console ou na App Store Connect.
  4. Aguardar a revisão da loja: Android costuma ser rápido, a Apple faz revisão manual.

Recapitulando

  • O contexto móvel (toque, ecrã pequeno, rede, bateria) orienta todas as decisões.
  • Escolher entre nativa, híbrida, web app e PWA conforme o projeto.
  • Usabilidade para o polegar + layout adaptativo com media queries e imagens responsivas.
  • Programar gestos e animar com transform/opacity, sempre com prefers-reduced-motion.
  • Medir com LCP, CLS e INP, otimizar imagens e fontes, construir uma PWA.
  • Acessibilidade, teste em dispositivo real e publicação fecham o ciclo.

Próximo: fichas e projeto, desenhar e publicar uma aplicação móvel de raiz.

NOTAS DO PROFESSOR - enfatizar: cada capítulo seguinte liga-se a uma destas diferenças; vale a pena voltar a este slide ao longo do curso. - erro comum/pergunta: perguntar quem já usou um site "de computador" no telemóvel e o que correu mal. - exemplo/analogia: comparar sentar-se a uma secretária (desktop) com andar na rua a segurar o telemóvel numa mão.

NOTAS DO PROFESSOR - enfatizar: assumir interrupção não é um extra, é requisito, sobretudo em formulários longos. - erro comum/pergunta: perguntar o que acontece a um formulário a meio se chegar uma chamada. - exemplo/analogia: uma app de compras que guarda o carrinho automaticamente, sem precisar de "guardar" manual.

NOTAS DO PROFESSOR - enfatizar: não há "a melhor", há a certa para o orçamento, o prazo e o que a app precisa de aceder no telemóvel. - erro comum/pergunta: alunos assumem que nativo é "sempre melhor"; discutir o custo de duas equipas. - exemplo/analogia: nativa é um fato à medida; PWA é um fato bem cortado de pronto-a-vestir, mais rápido e mais barato.

NOTAS DO PROFESSOR - enfatizar: percorrer o raciocínio em voz alta, critério a critério, não só dar a resposta. - erro comum/pergunta: perguntar o que mudaria se a app precisasse de acesso avançado à câmara. - exemplo/analogia: pedir à turma outro caso real e decidir a abordagem em conjunto.

NOTAS DO PROFESSOR - enfatizar: sem esta meta tag, nada do resto do curso funciona como esperado. - erro comum/pergunta: esquecer a viewport é o erro mais comum de quem começa; mostrar o "antes e depois". - exemplo/analogia: a viewport é como dizer ao browser "estás num telemóvel, não finjas ser um monitor".

NOTAS DO PROFESSOR - enfatizar: simular a rede lenta muda tudo, não simular só o tamanho do ecrã. - erro comum/pergunta: perguntar porque o layout aparece minúsculo sem a viewport configurada. - exemplo/analogia: fazer a demonstração ao vivo com um site real da turma.

NOTAS DO PROFESSOR - enfatizar: a navegação principal e o botão de ação primária vivem na zona fácil, não no topo. - erro comum/pergunta: apps antigas copiadas do desktop põem tudo importante no cabeçalho; porque é mau em móvel? - exemplo/analogia: pensar na mão a segurar o telemóvel como um raio de compasso a partir do polegar.

NOTAS DO PROFESSOR - enfatizar: a área mínima aplica-se mesmo quando o texto do botão é curto; usar padding para crescer a área de toque. - erro comum/pergunta: mostrar dois botões colados sem espaço e perguntar o que acontece a quem tem dedos maiores. - exemplo/analogia: comparar a área de um botão pequeno de site com o alvo de um jogo de dardos.

NOTAS DO PROFESSOR - enfatizar: crescer a área de toque com padding, não só aumentar o texto. - erro comum/pergunta: perguntar porque "Cancelar" deve ser visualmente menos destacado que "Confirmar". - exemplo/analogia: pedir à turma para medir com os dedos um botão real de 24px no telemóvel deles.

NOTAS DO PROFESSOR - enfatizar: mobile-first evita que o telemóvel receba e descarte regras pensadas para desktop. - erro comum/pergunta: perguntar o que acontece a um site desktop-first quando a rede móvel é lenta. - exemplo/analogia: construir a casa a começar pela porta principal, não pelas anexas.

NOTAS DO PROFESSOR - enfatizar: srcset deixa o browser escolher, o programador não decide qual imagem carregar. - erro comum/pergunta: usar só px fixos e perguntar o que acontece quando o utilizador aumenta o tamanho de letra do sistema. - exemplo/analogia: sizes é como dizer ao empregado de mesa "esta mesa é para dois, aquela para seis".

NOTAS DO PROFESSOR - enfatizar: o HTML não muda, só o CSS reorganiza o mesmo conteúdo. - erro comum/pergunta: perguntar porque não se faz uma grelha fixa de 4 colunas para todos os ecrãs. - exemplo/analogia: as mesmas peças de lego arrumadas em fila ou em quadrado, conforme a caixa disponível.

NOTAS DO PROFESSOR - enfatizar: cada gesto tem uma expectativa criada por outras apps; não inventar gestos novos sem necessidade. - erro comum/pergunta: perguntar o que aconteceria se "swipe" apagasse um item sem confirmação. - exemplo/analogia: os gestos são como um vocabulário partilhado entre todas as apps do telemóvel.

NOTAS DO PROFESSOR - enfatizar: o estado active tem de ser instantâneo, sem atraso percetível. - erro comum/pergunta: perguntar porque um botão sem feedback visual gera toques repetidos e acidentais. - exemplo/analogia: comparar com um interruptor de luz físico, que dá um "clique" percetível ao ser premido.

NOTAS DO PROFESSOR - enfatizar: Pointer Events unificam rato, caneta e dedo no mesmo código. - erro comum/pergunta: perguntar a diferença entre "click" e "touchstart" e quando cada um dispara. - exemplo/analogia: os eventos são como sensores que avisam o código de cada fase do gesto.

NOTAS DO PROFESSOR - enfatizar: o limiar (threshold) é uma decisão de desenho, não só de código; testar valores diferentes. - erro comum/pergunta: perguntar o que aconteceria com limiar zero. - exemplo/analogia: como decidir a força mínima para considerar um "empurrão" e não um encostar sem querer.

NOTAS DO PROFESSOR - enfatizar: reflow (recalcular layout) é caro; transform/opacity não o exigem. - erro comum/pergunta: mostrar uma animação de "left" a engasgar num telemóvel mais fraco e comparar com transform. - exemplo/analogia: mover uma peça sobre a mesa (transform) é mais leve do que reconstruir a mesa inteira (layout).

NOTAS DO PROFESSOR - enfatizar: não é um extra estético, é acessibilidade real, com impacto físico em quem sofre. - erro comum/pergunta: perguntar como se testa esta preferência sem mudar as definições do telemóvel (DevTools permitem emular). - exemplo/analogia: é o equivalente visual a baixar o volume para quem é sensível ao som.

NOTAS DO PROFESSOR - enfatizar: estas métricas vêm de utilizadores reais (Google), não são só um número de laboratório. - erro comum/pergunta: perguntar porque "parece rápido no meu computador" não chega como garantia. - exemplo/analogia: são como os sinais vitais de uma pessoa, medem saúde real, não aparência.

NOTAS DO PROFESSOR - enfatizar: cada causa liga-se a um capítulo já dado (imagens, fontes, animação). - erro comum/pergunta: perguntar qual das três causas é mais fácil de corrigir primeiro num projeto real. - exemplo/analogia: um camião com carga a mais (JavaScript pesado) demora mais a arrancar em qualquer estrada.

NOTAS DO PROFESSOR - enfatizar: o Lighthouse é gratuito e já vem instalado no Chrome; correr no projeto real da turma. - erro comum/pergunta: perguntar porque comprimir a imagem vale mais do que só adicionar preload sozinho. - exemplo/analogia: preload é "avisar com antecedência"; comprimir é "trazer menos bagagem".

NOTAS DO PROFESSOR - enfatizar: width/height no HTML não distorcem a imagem, apenas reservam o espaço antes de carregar. - erro comum/pergunta: perguntar o que acontece ao CLS quando falta width/height e a imagem "empurra" o texto. - exemplo/analogia: reservar o lugar no cinema antes de o filme começar, para ninguém se sentar em cima de ninguém.

NOTAS DO PROFESSOR - enfatizar: sem font-display, o texto pode ficar invisível até a fonte carregar (flash de texto invisível). - erro comum/pergunta: perguntar quantos pesos de fonte (regular, negrito, itálico) o projeto realmente usa. - exemplo/analogia: uma fonte variável é como uma caixa de lápis com um só lápis que muda de espessura.

NOTAS DO PROFESSOR - enfatizar: sem manifest válido, o browser não oferece "Adicionar ao ecrã principal". - erro comum/pergunta: perguntar porque são precisos ícones em mais do que um tamanho. - exemplo/analogia: o manifest é como um bilhete de identidade que a app mostra ao sistema operativo.

NOTAS DO PROFESSOR - enfatizar: cada estratégia serve um tipo de conteúdo diferente; não há uma só certa para tudo. - erro comum/pergunta: perguntar qual estratégia usar para o horário de aulas, que muda de vez em quando. - exemplo/analogia: cache first é uma despensa cheia; network first é ir sempre ao mercado primeiro.

NOTAS DO PROFESSOR - enfatizar: este código funciona offline logo após a primeira visita, uma vez instalado. - erro comum/pergunta: perguntar o que acontece se um ficheiro do array FICHEIROS não existir. - exemplo/analogia: apresentar o Workbox como o "atalho" para quem já entendeu a lógica manual.

NOTAS DO PROFESSOR - enfatizar: acessibilidade móvel soma-se à do desktop, não a substitui; o ecrã pequeno agrava os erros. - erro comum/pergunta: perguntar porque desativar o zoom prejudica quem tem baixa visão. - exemplo/analogia: o alt text é como descrever a imagem a alguém ao telefone.

NOTAS DO PROFESSOR - enfatizar: pequenas mudanças de cor resolvem a maioria dos problemas de contraste sem redesenhar nada. - erro comum/pergunta: perguntar como confirmar o rácio sem fazer as contas à mão (usar o verificador). - exemplo/analogia: é o equivalente a subir o volume de uma voz baixa numa sala ruidosa.

NOTAS DO PROFESSOR - enfatizar: fazer sempre pelo menos um teste em dispositivo real antes de publicar. - erro comum/pergunta: perguntar que problemas o emulador não consegue mostrar. - exemplo/analogia: conduzir um simulador de condução não substitui a primeira vez a sério na estrada.

NOTAS DO PROFESSOR - enfatizar: esta checklist corre-se antes de qualquer publicação, sem exceção. - erro comum/pergunta: perguntar o que fazer quando um item da checklist falha em cima da hora. - exemplo/analogia: é a lista de verificação de um piloto antes da descolagem, curta mas obrigatória.

NOTAS DO PROFESSOR - enfatizar: sem HTTPS, nada de service worker funciona, mesmo que o resto esteja correto. - erro comum/pergunta: perguntar porque a Apple e a Google exigem HTTPS para instalar uma PWA. - exemplo/analogia: HTTPS é como a fechadura da porta antes de convidar alguém a instalar-se em casa.

NOTAS DO PROFESSOR - enfatizar: a revisão da Apple pode demorar dias e pedir correções; planear prazo para isso. - erro comum/pergunta: perguntar o que acontece se faltar a política de privacidade na submissão. - exemplo/analogia: submeter a app é como entregar um dossiê a um júri, tem de estar completo à primeira.