Serviço de registro de corridas

O serviço de registro de corridas anota na hora a distância, o tempo, o ritmo e o percurso da corrida feita no celular, e mostra a cada pessoa que entrou apenas os seus próprios registros. Ao terminar de correr, o registro do dia se acumula na lista, e os registros de uma pessoa não ficam visíveis para as outras. O mesmo registro você vê tanto no app do celular quanto na web.

O que este exemplo mostra é uma coisa só. O app do celular e a web, duas telas, usam juntas um único backend do WEEGLOO. Por isso esta página primeiro apresenta o backend que o app e a web usam juntos e, depois, se divide para o lado que te interessa mais, o app ou a web. Qualquer que seja o lado escolhido, o backend é o mesmo. Esse é o ponto.

O que você monta

Em vez de uma loja de roupas ou de um blog, desta vez o exemplo é um serviço pessoal de registro de corridas. O mesmo registro você vê em duas telas, o app do celular e a web. As telas do app 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 para o mais antigo.
• Adicionar registro: você anota a distância, o tempo, o ritmo, o percurso e a data da corrida.

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

Você pode ir direto para o lado que te interessa. Quem quer montar o app do celular vai para Usar como app, e quem quer montar a web vai para Usar como web. Só que o "backend por trás das telas", logo abaixo, é comum tanto ao app quanto à web, então lê-lo primeiro faz os dois lados se encaixarem bem.

O backend por trás das telas (comum ao app e à web)

Quando você diz ao agente que montou e conectou as telas "integre com o WEEGLOO" (Conectar, Integrar com uma única frase), o agente examina as telas e prepara o que é preciso por trás delas. Um formato de dados que guarda os registros de corrida (Content Type), o login do Google (ServiceLogin), a permissão de "apenas o que é seu" (ServiceUserRole) e, conforme essa permissão, a entrega que baixa para cada membro apenas os seus próprios registros. Esse backend é o mesmo, comece pela tela do app ou pela tela da web, e o app e a web o usam juntos, sem mudanças. A forma de tratar cada peça separadamente é vista, uma a uma, em Adicionar cadastro e login, Dividir permissões e Guardar e usar dados.

Abaixo estão os recursos de fato criados no Stride Space deste exemplo. Não é como configurar cada um, mas o que surgiu como resultado do "integre".

O formato que guarda os registros de corrida

O primeiro é o formato que guarda os registros de corrida (Content Type) "Run". Os valores contidos em uma corrida ficam divididos em campos por item.

O ritmo médio não tem um campo próprio para ser guardado. É um valor que sai só com a distância e o tempo, então o app o calcula e o mostra na hora (o "auto-calculated" da tela de adicionar registro).

O login do Google

O segundo é o caminho pelo qual o membro entra com o Google (ServiceLogin). Neste exemplo, o nome fica como "Stride" e, como forma de login, só o Google foi ativado. Quem entra pela primeira vez recebe por padrão a permissão "Runner" abaixo. Ao terminar o login, o resultado volta para a tela, e a forma de voltar é um pouco diferente no app e na web. Essa diferença é tratada separadamente em Usar como app e Usar como web.

A permissão de "apenas os próprios registros"

O terceiro é a permissão que o membro recebe (ServiceUserRole) "Runner". As regras são estas.

Como a "leitura" está amarrada a "somente os que ele mesmo criou", na lista aparecem para cada um apenas os seus próprios registros. Como o que cada membro consegue ler são só os seus, essa é justamente a lista que é entregue a ele. Essa regra é aplicada igualmente tanto no app quanto na web.

Os registros e as fotos

O quarto são cada um dos registros de corrida (Content) e as fotos do percurso (Media). Esses dois não são criados de antemão, e sim um a um em nome da pessoa, quando o membro anota uma corrida. Abaixo está um registro de fato anotado. O formato "Run" acima está com os valores preenchidos, e uma foto do percurso está anexada.

A distância 42.195 é a maratona completa. O tempo é guardado em segundos (aqui, um registro de 3 horas e 53 minutos) e, na tela, é mostrado como 3:53:00. A foto do percurso é guardada à parte como arquivo (Media), e o registro contém apenas a ligação que aponta para esse arquivo.

Usar como app

Primeiro, o app do celular. Você monta as telas do app e preenche o que fica por trás delas com o backend por trás das telas acima.

Montar e integrar as telas do app

1. Criar o design das telas. As três telas de "O que você monta" acima foram geradas dando ao LLM um prompt como o abaixo. Basta escrever em uma linha que tipo de app você monta, a lista de telas com o conteúdo de cada uma e a direção de design.

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

Telas:

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

Com um visual limpo e ativo, de modo que números como distância e ritmo sejam lidos de relance. Siga as convenções de UI móvel.

As telas geradas assim ainda são só telas, sem dados nem login.

2. Integrar com o WEEGLOO. Você conecta o agente ao WEEGLOO e diz "integre com o WEEGLOO"; o agente examina essas telas e prepara o backend por trás das telas acima.

As duas coisas a cuidar por ser app

O backend é igual ao de quando você monta pela web. Por ser app, há duas coisas a cuidar.

• Publicação: levar o app móvel pronto até as mãos das pessoas (o registro na loja de aplicativos) acontece fora do WEEGLOO. O que o WEEGLOO assume são os dados, os membros e as permissões por trás das telas do app. (A web não tem loja de aplicativos. Isso é tratado em Usar como web.)
• Callback de login: a ligação que recebe de volta no app o resultado depois que o login termina é diferente da web. O resultado do login só pode voltar por um endereço web, então é preciso uma etapa a mais: uma página que faz o papel de ponte intermediária, passando esse resultado para o app. Essa etapa técnica é tratada na Auth API.

Ver se cada um vê só os próprios registros

A condição central "cada um vê apenas os seus próprios registros" é de fato cumprida no app. Abaixo está a tela de início do mesmo app aberta 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 diferentes.

Numa conta aparece só uma corrida de 5km, na outra só as duas de maratona e 3km. Os registros de um não ficam visíveis para o outro. No Stride estão guardados esses três registros, mas a cada membro são entregues apenas os que ele mesmo anotou. É o resultado de, na permissão A permissão de "apenas os próprios registros" acima, a leitura estar amarrada a "somente os que ele mesmo criou".

Usar como web

A web usa o mesmo backend do app, sem mudanças. A web lê o backend por trás das telas acima e mostra os mesmos registros.

Montar e integrar as telas da web

A web também são os mesmos dois passos do app.

1. Criar o design das telas da web. Assim como no app, você gera as telas da web dando ao LLM um prompt como o abaixo. O conteúdo é o mesmo do app, ajustado para um layout web adequado a telas largas.

Faça o design das telas web de registro de corridas. É uma web para desktop.

Telas:

• Login: uma linha de apresentação do serviço e um botão "Continuar com o Google".
• Lista de registros (painel): resumo de distância total, número de corridas e ritmo médio, uma lista de registros de corrida (data, distância, tempo, ritmo, miniatura do percurso) e um botão de adicionar registro.
• Adicionar registro: entrada de data, distância, tempo, ritmo, nota e foto do percurso, e salvar.

Com um layout que aproveite a tela larga, de modo que números como distância e ritmo sejam lidos de relance. Siga as convenções de UI web.

2. Integrar com o WEEGLOO. Você diz ao agente conectado "integre também esta web com o WEEGLOO". Se você já tiver montado o app, o agente não levanta de novo o backend por trás das telas acima, e sim o reaproveita como está. Não há nenhum recurso do WEEGLOO criado de novo. O que se cria de novo na web são só as telas web. (Se você começou pela web sem passar pelo app, é aí que esse backend surge pela primeira vez, e mesmo que depois você acrescente o app, ele o usa igualmente como está. Qualquer que seja o lado, o backend é o mesmo.)

Esta tela web é a conta que aparece em Ver se cada um vê só os próprios registros (este mês 45.2km, a maratona de 42.20km e os 3km) aberta na web. A distância total, o número de corridas e os registros são idênticos aos da tela de início do app. Como o backend é um só, os mesmos dados que o app mostrou a web mostra igualmente em uma tela de desktop.

As duas coisas diferentes por ser web

A web também tem duas diferenças em relação ao app, mas o sentido é o oposto do app, então desta vez há até menos a cuidar.

• Publicação: a web não precisa de loja de aplicativos. Você coloca os arquivos web criados direto na internet com o Web Hosting (Colocar o site na internet).
• Callback de login: na web, o resultado do login volta direto por um endereço web. A página de ponte intermediária que era preciso no app não é necessária na web.

A permissão segue igual, então na web também cada membro vê apenas os seus próprios registros. A permissão A permissão de "apenas os próprios registros" acima é aplicada igualmente na web.

O que fazer a seguir

• Adicionar cadastro e login: trata de como acrescentar à parte um login que recebe membros próprios.
• Auth API: trata da etapa técnica de receber no app o resultado do login.
• Dividir permissões: trata de como definir a permissão para que o membro trate apenas do que é seu.
• Guardar e usar dados: trata de como criar um formato de dados e preencher o conteúdo.
• Colocar o site na internet: trata de como publicar a web com o Web Hosting.