App de registro de corridas

Um app de registro de corridas é um app para celular que anota a distância, o tempo, o ritmo e o percurso de cada corrida no momento em que ela acontece, e mostra a cada pessoa que entrou apenas os seus próprios registros. Quando uma corrida termina, o registro de hoje se soma à lista, e os registros de uma pessoa não ficam visíveis para as outras.

Este exemplo mostra uma coisa. Um app para celular usa exatamente o mesmo backend que você usaria em um serviço web. Guardar registros, receber membros e fazer com que cada pessoa veja só os seus próprios registros não é diferente na web e no app. Por isso este exemplo também percorre, do começo ao fim, todo o processo de montar esse backend (os dados que guardam os registros, o login de membros e a permissão de ver só os próprios registros), e aponta à parte as duas coisas que mudam por ser celular: a publicação e a conexão que traz o resultado do login de volta para o app.

O que vamos construir

Em vez de uma loja de roupas ou um blog, desta vez o exemplo é um app pessoal de registro de corridas. As telas são três.

• Tela de login: você entra com o Google.
• Lista de registros: a pessoa que entrou vê os registros de corrida que anotou até agora, do mais recente ao mais antigo.
• Adicionar registro: você anota a distância, o tempo, o ritmo, o percurso e a data de uma corrida.

O ponto central é "cada pessoa vê só os seus próprios registros". À pessoa que entrou são entregues apenas os registros que ela anotou, e os registros dos outros não ficam visíveis. Essa condição é o que, mais adiante, torna necessários juntos o login de membros e a permissão.

Fazer as telas primeiro e depois conectar

Construir este app por conta própria são dois passos. Primeiro você faz as telas do app e depois entrega para a WEEGLOO o que fica por trás dessas telas.

1. Criar o design das telas. As telas acima foram geradas dando a um LLM um prompt como o de baixo. Basta escrever em uma linha que tipo de app você está fazendo, a lista de telas e o que cada tela contém, e a direção de design.

Faça o design das telas de um app de registro de corridas. É um app de celular na vertical.

Telas:

• Login: uma linha de apresentação do app e um botão "Continue with Google".
• Lista de registros (início): resumo da distância total e do número de corridas, uma lista de cartões de registro de corrida (data, distância, tempo, ritmo, miniatura do percurso) e um botão de adicionar registro.
• Adicionar registro: campos de data, distância, tempo, ritmo, anotações e foto do percurso, mais o salvar.

Com um visual limpo e ativo, de modo que números como distância e ritmo se leiam de relance. Siga as convenções de UI para celular.

As três telas de "O que vamos construir" acima são o resultado deste prompt. Neste ponto ainda não há dados nem login, é só as telas.

2. Conectar à WEEGLOO. Conecte o agente à WEEGLOO (Conectar) e diga o seguinte.

Integre isto com a WEEGLOO.

Sem precisar explicar longamente o que você está fazendo, o agente examina essas telas e monta o que é necessário por trás delas. Esse fluxo de entregar tudo de uma vez é o mesmo de Integrar em uma frase.

O que a WEEGLOO monta por trás das telas

Com a única instrução "integre isto", o agente olha as telas e monta estas quatro coisas. É o backend que a WEEGLOO assume por trás das telas.

1. Uma estrutura de dados para guardar os registros de corrida (Content Type). Guarda itens como distância, tempo, ritmo, percurso e data.
2. Login com o Google (ServiceLogin). Faz com que os usuários do app se cadastrem e entrem por conta própria.
3. A permissão "só os próprios registros". Faz com que a pessoa que entrou leia, escreva e apague apenas os registros que ela anotou.
4. Entrega dos próprios registros. Envia a cada pessoa que entrou apenas os seus próprios registros, em forma de lista.

Essas quatro coisas são exatamente as mesmas de que você precisa ao fazer o mesmo serviço para a web. Como lidar com cada parte separadamente é tratado uma a uma em Adicionar cadastro e login, Dividir permissões e Guardar e recuperar dados. Se você quiser anotar junto uma imagem do mapa do percurso ou uma foto, também pode anexar um arquivo (Media).

O que de fato foi criado

Abaixo estão os recursos que foram de fato criados no Space Stride deste exemplo. Isto não é um passo a passo de como configurar cada um, e sim uma olhada no que apareceu neste app como resultado do "integre isto".

A estrutura que guarda os registros de corrida

A primeira é a estrutura que guarda os registros de corrida (Content Type), "Run". Os valores que entram em uma única corrida ficam divididos em campos por item.

Não há um campo separado que guarde o ritmo médio. É um valor que sai só a partir da distância e do tempo, então o app o calcula e mostra na hora (o "auto-calculated" na tela de adicionar registro).

Login com o Google

A segunda é o canal por onde os membros entram com o Google (ServiceLogin). Neste exemplo o nome ficou como "Stride", e o único método de login ativado foi o Google. Quem entra pela primeira vez recebe por padrão a permissão "Runner" abaixo. Quando o login termina, esse resultado volta para o app passando pela página de ponte intermediária mencionada em Trazer o resultado do login de volta para o app.

A permissão "só os próprios registros"

A terceira é a permissão que os membros recebem (ServiceUserRole), "Runner". As regras são estas.

Como "ler" está preso a "só os que a própria pessoa criou", na lista aparecem para cada um apenas os seus próprios registros. Das quatro coisas mencionadas antes, a número 3 (permissão) e a número 4 (entrega) na verdade saem juntas desta única regra. Como os registros que cada membro consegue ler são só os seus, é justamente essa a lista entregue a essa pessoa.

Registros e fotos

A quarta é cada registro de corrida individual (Content) e a foto do percurso (Media). Esses dois não são criados de antemão, e sim criados um a um em nome do membro quando ele anota uma corrida no app. Abaixo está um registro que foi de fato anotado. A estrutura "Run" anterior está preenchida com valores, e uma foto do percurso vem anexada junto.

A distância 42.195 é uma maratona completa. O tempo é guardado em segundos (aqui, um registro de 3 horas e 53 minutos) e no app é mostrado como 3:53:00. A foto do percurso é guardada à parte como um arquivo (Media), e o registro guarda apenas um vínculo que aponta para esse arquivo. A lista e os cartões de "O que vamos construir" são a aparência de vários desses registros já acumulados.

As duas coisas diferentes da web

Até aqui é igual à web. Um app para celular usa o mesmo backend do jeito que está. Por ser celular, só duas coisas mudam.

Publicação: a loja de apps fica fora da WEEGLOO

Um serviço web pode colocar o que ficou pronto na internet com o Web Hosting (Colocar um site na internet), mas levar o app de celular pronto às mãos das pessoas (o registro na loja de apps) acontece fora da WEEGLOO. O que a WEEGLOO assume são os dados, os membros e as permissões por trás das telas do app.

Trazer o resultado do login de volta para o app

O recurso de login em si é acoplado do mesmo jeito que na web. O que muda em relação à web é a conexão que traz o resultado de volta para o app depois que o login termina. O resultado do login só pode voltar para um endereço web, então é preciso um passo a mais: uma página que faz o papel de ponte intermediária e passa esse resultado para o app. Esse passo técnico é tratado na Auth API.

Ver que fica mesmo só os próprios registros

A condição central deste app, "cada pessoa vê só os seus próprios registros", de fato se mantém. Abaixo estão as telas de início do mesmo app aberto com duas contas diferentes. É o mesmo app, mas a distância total, o número de corridas e os registros que aparecem na lista são todos diferentes.

Uma conta mostra só uma corrida de 5km, e a outra mostra só duas corridas, uma maratona e uma de 3km. Os registros de uma não ficam visíveis para a outra. O Stride guarda todos esses três registros (veja O que de fato foi criado), mas a cada membro são entregues apenas os registros que ele anotou. É o resultado de prender a leitura a "só os que a própria pessoa criou" em A permissão "só os próprios registros" acima.

O que fazer a seguir

• Adicionar cadastro e login: trata de como acoplar à parte um login que recebe os seus próprios membros.
• Auth API: trata do passo técnico de trazer o resultado do login de volta para o app.
• Dividir permissões: trata de como definir permissões para que os membros lidem só com o que é deles.
• Guardar e recuperar dados: trata de como criar uma estrutura de dados e preenchê-la com conteúdo.