A anatomia de uma aplicação

Já escreveste o teu primeiro programa e sabes o que se passa por baixo — bits, portas lógicas, CPU, sistema operativo, redes. Agora damos o passo seguinte: perceber como um punhado de linhas cresce até se tornar uma aplicação a sério, feita de partes que cooperam.

Nem todas as apps são iguais

"App" é uma palavra que usamos para coisas muito diferentes: o site que abres no browser, o jogo no telemóvel, o programa de desenho no computador, o comando que escreves numa janela de texto. Por fora parecem mundos separados. Por dentro, partilham quase tudo.

Onde é que uma app "vive"?

A diferença mais importante entre os tipos de aplicação não é o que fazem — é onde correm e como chegam até ti. Pensa nos veículos: uma bicicleta, um carro, um comboio e um avião servem todos para te levar a algum lado, mas movem-se em terrenos diferentes e apanham-se de maneiras diferentes. Com as apps é igual.

• Aplicação web — vive num servidor e corre dentro do browser. Não instalas nada: escreves um endereço e ela aparece. Este curso é uma. Vantagem: chega a qualquer aparelho que tenha um browser. (Lembras-te do Módulo 4 da Parte I? É a Web a trabalhar.)
• Aplicação móvel — instalas no telemóvel ou tablet a partir de uma loja. Corre no teu bolso e pode usar câmara, GPS e notificações.
• Aplicação de secretária (desktop) — instalas no computador. Corre na máquina à tua frente e costuma ser a mais poderosa (editar vídeo, jogos pesados).
• Linha de comandos (CLI) — sem botões nem janelas: dás ordens escritas numa consola de texto. Parece antiquado, mas é rápido, preciso e perfeito para automatizar. Os programadores vivem aqui.

Há mais famílias — os jogos (que muitas vezes desenham cada ponto do ecrã de raiz) e os sistemas embebidos (o software escondido dentro de um micro-ondas, de um carro ou de uma máquina de lavar) — mas estas quatro cobrem quase tudo o que usas todos os dias.

O que é sempre igual, por baixo

Aqui está a ideia que vais levar para o resto desta Parte: por mais diferentes que pareçam, quase todas estas aplicações têm os mesmos três órgãos.

• uma interface — a parte com que falas (o que vês e tocas);
• uma lógica — as regras que decidem o que acontece;
• uns dados — a informação que a app guarda e volta a usar.

Muda a embalagem; os órgãos são os mesmos. Vamos dissecá-los um a um nos próximos módulos. Mas primeiro, treina o olho para reconhecer os tipos:

O que o utilizador vê e toca

A interface — a UI, de user interface — é a cara da aplicação: o que aparece no ecrã, os botões em que carregas, os campos onde escreves. É a única parte da app que o utilizador vê mesmo. Tudo o resto trabalha escondido para a servir.

Lembras-te dos quatro ingredientes de um programa (Parte I, Módulo 3): entrada, memória, lógica e saída? A interface é onde a entrada e a saída ganham forma e cor. Quando carregas num botão, isso é entrada; quando o ecrã muda, isso é saída. A UI é o programa a falar contigo em imagens, em vez de texto cru.

Três camadas: esqueleto, roupa e reflexos

Uma interface na Web faz-se com três coisas que convém não misturar na cabeça:

• HTML — o esqueleto (estrutura). Diz que peças existem: um título, um parágrafo, uma imagem, um botão. É só a ossatura, sem qualquer preocupação com o aspeto.
• CSS — a roupa (estilo). Diz qual é o aspeto dessas peças: cor, tamanho, tipo de letra, espaço, cantos redondos. A mesma estrutura pode vestir mil roupas diferentes.
• Eventos — os reflexos (comportamento). Dizem o que acontece quando interages: ao carregar, ao escrever, ao arrastar. É aqui que a interface reage e ganha vida.

Esta separação é poderosa. Mudar a roupa (CSS) não mexe no esqueleto (HTML): o texto de um botão continua a ser o mesmo, mesmo que o pintes de vermelho e lhe arredondes os cantos. Vê com os teus olhos — no estúdio abaixo, mexe no estilo e repara que a estrutura (o texto do botão) só muda quando és tu a mudá-la:

E o browser?

Quem pega no HTML e no CSS e os transforma em pontos de luz no ecrã é o browser — um programa enorme e espantoso. Ele lê a tua descrição ("um botão teal, texto escuro, cantos redondos"), calcula onde cada coisa fica, desenha-a, e fica à espera dos teus cliques para disparar os eventos. Uma app web é, no fundo, uma conversa constante entre o que tu descreves e o que o browser desenha.

Onde vivem as regras

Por trás dos botões há regras: quem pode fazer o quê, o que acontece quando carregas em "guardar", como se calcula um resultado, o que é permitido e o que não é. A essa inteligência da app chamamos lógica — e ela costuma viver longe do teu ecrã, num computador chamado servidor.

Cliente e servidor

Toda a aplicação existe para fazer alguma coisa — tem uma função. Para a cumprir, precisa de regras em que se possa confiar. A grande pergunta é: onde é que essas regras ficam guardadas? A resposta quase nunca é "no teu ecrã".

Pensa num jogo online com vários jogadores. Há regras — que jogadas são válidas, quantos pontos vale cada coisa, quanto ouro tens — e há o estado de cada jogador: a sua vida, a sua pontuação, onde está no mapa. Agora imagina que tudo isto ficava guardado no computador de cada jogador. Qualquer um podia abrir esse ficheiro e escrever "tenho 999 vidas e um milhão de pontos". Era batota à vontade — e o jogo deixava de ter graça.

Por isso o jogo não confia no aparelho de cada jogador. As regras e o estado verdadeiro de cada um ficam guardados num computador central, longe dos jogadores: o servidor. O teu ecrã — o cliente — mostra o jogo e pede ao servidor aquilo que queres fazer ("mover para aqui", "atacar"). O servidor verifica se as regras permitem, atualiza o estado, e responde. Se tentares fazer batota, é o servidor que diz que não.

Funciona assim em quase todas as apps, não só nos jogos: a interface (o cliente) mostra e pede; o servidor guarda as regras e o estado, decide, e responde. Reconheces este vaivém? É o pedido e resposta do HTTP que estudaste na Parte I, agora ao serviço da aplicação.

A API: a lista de pedidos permitidos

Mas o cliente não pode pedir qualquer coisa ao servidor de qualquer maneira. O servidor publica uma lista do que aceita — que pedidos existem e como se fazem. A essa lista chama-se API (de Application Programming Interface): no jogo de há pouco, seria o conjunto de ações que o servidor reconhece — "mover", "atacar", "comprar item". O que não estiver na lista, o servidor recusa.

Cada pedido da API tem um método (o tipo de pedido) e uma rota (o endereço do que queres). Dois métodos chegam para quase tudo:

• GET — "dá-me" alguma coisa (ler). Ex.: GET /modulos → devolve a lista de módulos.
• POST — "toma, guarda" alguma coisa (escrever). Ex.: POST /progresso → grava que concluíste um módulo.

É exatamente isto que esta app faz: tem uma API real em /api/progresso, com um GET (buscar o teu progresso) e um POST (guardá-lo).

JSON: a forma de escrever os dados

Quando o cliente e o servidor trocam informação, precisam de uma maneira arrumada de a escrever, que ambos entendam. A mais comum chama-se JSON. É só texto, com uma estrutura simples de nome: valor, entre chavetas. Um aluno poderia ser assim:

{
  "nome": "Rita",
  "idade": 13,
  "modulos": ["m1", "m2"]
}

Repara: é legível por ti e pela máquina. E, lá no fundo (Parte I, Módulo 1), é tudo bytes — mas organizados de forma que qualquer programa, em qualquer linguagem, os saiba ler.

Como uma app se lembra

Fechas a aplicação, voltas no dia seguinte — e as tuas coisas continuam lá: as mensagens, as fotos, o progresso neste curso. Parece óbvio, mas não é. Como é que uma app se lembra?

Memória que esquece vs. memória que fica

Na Parte I (Módulo 2) conheceste a RAM — a memória de trabalho, rápida mas volátil: quando se desliga a corrente, apaga-se tudo. É como o que tens na cabeça enquanto fazes uma conta: assim que te distrais, foi-se. Se as apps só usassem RAM, perderias tudo sempre que fechasses.

Por isso existe outro tipo de memória: persistente, que sobrevive a desligar a máquina. É o disco — e a ideia de ficheiro que viste na Parte I (Módulo 3) é a primeira forma de lá guardar coisas. Mas para uma app com muitos dados, e muitas perguntas a fazer-lhes, um monte de ficheiros soltos não chega. É aí que entra a base de dados.

O que é uma base de dados

Uma base de dados é um sítio organizado para guardar informação e, sobretudo, para a voltar a encontrar depressa. Pensa no ficheiro de uma biblioteca: milhares de livros, mas um sistema que te deixa achar num instante "todos os livros de ficção científica publicados depois de 2000". Uma base de dados faz isso com os dados de uma app.

Há duas formas muito comuns de arrumar os dados:

• Tabelas (bases de dados relacionais) — como uma folha de cálculo: linhas (cada aluno) e colunas (nome, idade, cidade). Ordem certinha e rígida.
• Documentos (bases de dados NoSQL) — cada registo é um pequeno JSON, como o do módulo anterior. Mais flexível. (É o que esta app usa: o teu progresso é um documento.)

Consultar = fazer perguntas

Guardar é metade; a magia está em perguntar. A uma pergunta feita a uma base de dados chama-se consulta (em inglês, query). "Dá-me todos os alunos com 13 anos ou mais, da cidade do Porto" é uma consulta. A base de dados percorre o que tem e devolve só as linhas que respondem "sim". Experimenta:

A viagem de um clique

Já viste os três órgãos em separado — a interface (Módulo 2), a lógica e a API (Módulo 3), os dados (Módulo 4). Agora vem a parte mais bonita: vê-los a trabalhar juntos. Porque um simples clique num botão desencadeia uma pequena viagem que atravessa a aplicação inteira.

Seguir o pedido, do princípio ao fim

Imagina que carregas em "Concluí este módulo" aqui neste curso. Em menos de um segundo, acontece isto:

1. No ecrã (a interface), o teu clique dispara um evento (Módulo 2).
2. A interface monta um pedido e envia-o à API por HTTP: POST /progresso (Módulo 3).
3. No servidor, a lógica recebe o pedido, confirma quem tu és e decide o que fazer.
4. O servidor fala com a base de dados e guarda que concluíste o módulo (Módulo 4).
5. A base de dados confirma; o servidor monta uma resposta e devolve-a.
6. De volta ao ecrã, a interface recebe a resposta e atualiza-se: o botão fica verde. ✓

A este vaivém — cliente pede, servidor responde — chama-se arquitetura cliente-servidor. É o esqueleto invisível de quase todas as apps que usas. Segue a viagem, passo a passo:

Porquê separar assim?

Podíamos meter tudo no mesmo sítio — mas separar tem vantagens enormes. O mesmo servidor e a mesma base de dados podem servir muitos clientes ao mesmo tempo (o teu telemóvel e o teu computador, e os de milhares de outros alunos). A lógica sensível (as regras, a tua palavra-passe) fica guardada no servidor, longe de olhares. E cada peça pode ser melhorada ou substituída sem partir as outras — que é, precisamente, o tema da Parte III.

Já sabes do que é feita uma app

Uma aplicação deixou de ser uma caixa mágica. Sabes que tem uma interface (o que vês), uma lógica com API (as regras, do lado do servidor) e uma base de dados (a memória que fica) — e sabes como falam entre si num vaivém cliente-servidor.

Mas falta a pergunta mais humana de todas: quem constrói isto tudo, e como? Um software a sério não nasce de uma pessoa numa noite — nasce de uma equipa, com um método, ao longo do tempo.