practice-uffs / app-practice Goto Github PK

Gaveta de opções gerais do aplicativo fica do lado direito. Ela é aberta quando o usuário clica no ícone das “três barrinhas”, no canto superior direito.

Tela de referência: MENU001-A

A tela de mensagens é uma cópia exata do aplicativo Telegram: teremos chats em grupo e individuais. Além disso, determinados chats ficarão agrupados em uma “pasta”. Para essa primeira versão da tela de mensagem, basta replicar o layout de funcionamento do telegram/whatsapp sem que mensagens sejam realmente enviadas e recebidas (tudo pode ser fake).

Tela: C001-A

Antes a requisição de login já retornava os dados do usuário automaticamente, mas como ela foi atualizada para utilizar o wndpoint da api, essas informações não vêm automaticamente. Portanto, é necessário criar uma requisição para o endpoint auth/me para obter os dados do usuário. A requisição precisa rodar apenas uma vez, visto é são dados que só mudarão se outro usuário logar. Logo, eles podem ser armazenados.

Atualmente, as requisições são feitas utilizando promises, mas os resultados são retornados via callback, o que não é uma solução muito robusta. Portanto, seria conveniente utilizar promises (async e await) para deixar as requisições mais robustas e fáceis de utilizar e manter.

O objetivo dessa tarefa não é implementar todas as funcionalidades, mas a estrutura inicial: uma área para visualizar o que a câmera captura, um botão sobreposto a essa visão, e uma parte mostrando as informações do usuário (com um código QR qualquer).

Tela: S001-A

Essa tela é acessível através de um ícone na página home do aplicativo. Ao acessar a página serviços, o usuário é apresentado com a seguinte lista:

• Vídeo: apresentação composta (pessoa é gravada seguindo um documento de apresentação, que será intercalado via edição com as falas; baseado em https://www.youtube.com/watch?v=DoDjWzsQ4PU)
• Vídeo: apresentação simples (apenas grava a pessoa falando na câmera com o fundo que ela escolheu)
• Vídeo: animação “mão-livre” (horizonte 1)
• Audio: audio simples (uma única trilha de audio, por exemplo, fala)
• Audio: audio composto (duas ou mais trilhas de áudio, ex.: fala, música, efeitos sonoros, combinação de fontes diferentes)

Atualmente as notícias estão com conteúdo placeholder. Elas precisam mostrar conteúdo real agora. Para isso, as informações sobre notícias podem ser obtidas através de https://practice.uffs.cc/feed.xml . Atualmente esse feed não contém todas as informações necessárias, mas depois que practice-uffs/website-programa#53 for implementada, isso será possível.

Vou marcar o @CleissonVieira nessa tarefa, porque ele está trabalhando na practice-uffs/website-programa#53. Ele pode avisar quando ela ficar pronta.

A classe Storage será responsável por armazenar os dados da aplicação localmente para dados possam ser persistidos. Além disso, a classe também fará comunicação com a API do web-feedback para sincronizar quaisquer elementos.

Para implementar essa issue, utilize o arquivo abalitycs.js como ponto de partida. Ele faz praticamente tudo que precisamos, porém ele faz algumas coisas a mais (como enviar estatísticas, que não é necessário na classe storage).

A classe Storage guardará todas as suas informações em disco como um objeto json stringficado (JSON.stringfy). Quando a classe for inicializada, ela deve carregar do disco essa string, parsear ela (JSON.parse) e colocar o objeto na memória.

A inicialização da classe Storage segue o mesmo funcionamento de inicialização da classe Analytics . Você pode utilizar essa mesma ideia.

A tela Profile (que na verdade é uma tab na tela Home) precisa ser atualizada para mostrar os dados do usuário logado. É evidente que ela depende da issue #51. Assim que o login via idUFFS estiver funcionando, mostrar os dados do usuário na Profile será algo bem simples.

No entanto, esta tela também possui as moedas e conquistas do usuário, e essas são funcionalidades ainda não implementadas. Portanto, ao realizar essa tarefa, deve-se adicionar as moedas e as conquistas nas feature flags para não mostrá-las ao usuário final.

Seguindo o que foi feito em practice-uffs/mural#71, o projeto do aplicativo do programa precisa definir os requisitos de engenharia de software de uma forma mais concreta. Esse issue é para garantir que isso seja feito para guiar os próximos passos do desenvolvimento.

O repositório grintex/app-covid contém um aplicativo funcional pronto para deploy, com licença ideal. Copiar toda a estrutura do projeto, porém manter apenas as seguintes telas do app:

• https://github.com/grintex/app-covid/blob/dev/src/pages/about.f7.html
• https://github.com/grintex/app-covid/blob/dev/src/pages/stats.f7.html
• https://github.com/grintex/app-covid/blob/dev/src/pages/home.f7.html
• https://github.com/grintex/app-covid/blob/dev/src/pages/404.f7.html

Criar a barra de navegação que fica na base do aplicativo, visível em todas as telas:. Haverá quarto opções na barra de navegação. Usar Tabbar no Framework7 com labels sendo ícones do fontawesome para implementar essa issue.

As páginas que cada uma das opções abre está documentada aqui.

Conforme requisitado pelo @Dovyski, é necessário gravar um vídeo simples mostrando as telas e os fluxos do app.

Atualmente a página sobre do aplicativo está mostrando os integrantes do projeto antigo (app-covid). Atualizar essa página para mostrar os membros do practice e suas equipes.

Há um erro acontecendo na criação de comentários e ele precisa ser investigado para que seja resolvido. Ele consiste em, ao enviar o comentário, parece que tudo dá certo, nenhum erro é mostrado. No entanto, ao carregar os comentários do serviço, o novo comentário não está lá.

Visto que será possível ver os serviços que eu solicitei, é necessária uma tela para visualizar cada serviço separadamente. A estrutura da mesma está pronta, seria apenas uma questão de ajuste de layout e chamadas aos endpoints.

Acabei de ver esse projeto da Microsoft sobre cards para diversos aplicativos. Pelo visto, tem muita coisa que podemos usar.

Visto que houveram alterações no quadro de bolsistas e coordenadores do PRACTICE, é necessário atualizar esses dados no app também. Outra opção seria remover isso do app para evitar ter que atualizar isso. Outra opção seria uma outra tela para mostrar a equipe do app ou do PRACTICE. E mais uma opção seria carregar esses dados do site da mesma forma que é feito com as notícias (embora fosse melhor que tais dados fossem via API ou mesmo fixos).

Aguardo sugestões (@Dovyski).

Agora que o app possui feature flags, é conveniente criar um modo de desenvolvedor para não ser necessário "malabarismos" para implementação de novas features.

Uma abordagem seria criar uma opção nas configurações para ativar ou desativar o modo de desenvolvidor, mas o problema dessa abordagem é que o usuário final poderia usar essa funcionalidade e acabar acessando funcionalidades não funcionais.

Outra abordagem seria implementar ambientes dinâmicos em que, por exemplo, se compilo o app como dev, as funcionalidades aparecem, mas se compilo como prod, as feature flags entram em ação. No entanto, falta-me a expertise necessária para implementar algo assim.

Deixo essa issue aberta para novas sugestões.

Conforme acordado na issue #43, deve ser desenvolvido o conteúdo da tela inicial que o usuário acessa antes de fazer seu login. A ideia desta tela é apresentar uma mensagem de boas vindas ao usuário, dizer em poucas palavras o objetivo do app e dar possíveis instruções, assim diminui a chance de que o usuário se sinta perdido ao acessar o app pela primeira vez ou acessar depois de muito tempo sem utilizar.

No caso, a tela já existe, falta apenas inserir o conteúdo. Optei por criar esta issue para que o progresso desta tarefa fique documentado e público.

Embora a classe storage tenha sido implementada a fim de centralizar as requisições de dados do app, a requisição de notícias ainda está sendo feita na tela de notícias. Portanto, é necessário refatorar essa parte para que fique certinho.

Vários da equipe estão enfrentando um erro ao tentar executar o app em seus ambientes locais de desenvolvimento. O erro que eu estou enfrentando é o que está logo abaixo:

Se alguém estiver enfrentando outro erro, favor comentar aqui. Esse problema é bem urgente porque impede o desenvolvimento de várias outras tarefas.

A tela de login deve solicitar o idUFFS e a senha do usuário. A autenticação pode ser feita utilizando-se uma das APIs do curso de Ciência da Computação (falar com @Dovyski).

A tela de serviços do aplicativo deve mostrar uma lista com os serviços solicitados pelo usuário.

Esse modal deve ter como estrutura um elemento gráfico, um título, um texto e um botão/link de continuar. O elemento gráfico precisa ser, obrigatoriamente, um Lottie file. Como consequencia, a conclusão dessa tarefa envolve a integração do player web do lottie files no app.

Embora essa issue fale em modal, isso é apenas para exemplificar o comportamento desejado: algo aparecerá na tela do usuário cobrindo todo o conteúdo. Usaremos isso para mostrar mensagens de conclusão de tarefas, etc.

Eu sugiro fazer a implementação dessa tela exatamente como o Open as modal da tela de login do exemplo do Framework7. O modal de login que abre quando o usuário clica em Open as modal é exatamente o que queremos: um modal que cobre toda a tela e tem um botão/link para fechar.

Referência: MODAL001-A

Permite a visualização de um serviço em particular. Essa tela pode ser adaptada ou compartilhada do sistema web-feedback.

Tela: O002-A

Para disponibilizarmos o app para o nosso usuário final, é evidente que não podemos mostrar telas e funcionalidade que não estão prontas. Portanto, faz-se necessário a implementação de feature flags, um sistema que habilita e desabilita determinadas funcionalidades e telas para mostrar ao usuário apenas o que realmente estiver pronto. Assim que isso estiver pronto, a ideia é que no ambiente de desenvolvimento seja possível ver tudo o que o app tem, mas que no ambiente de deploy só seja possível ver o que estiver pronto.

Depende de: #54

Ajustar a página de configurações para que ela mostre o conteúdo descrito na tela de referência.

Referência: T001-A

Para essa issue, não é necessário que os dados da página de configurações sejam salvos em disco.

A tela ambiente mostrará informações e interações que o usuário tem dependendo do ambiente onde ele está. Por exemplo, se o usuário estiver em uma sala XXX do campus Chapecó, uma opção que aparecerá nessa tela é “Reservar a sala XXX para o seu uso?”.

Essa tela sempre mostrará uma informação seguida de pequenos botões para interação. Por exemplo, responder/postar enquete.

O objetivo dessa tarefa não é implementar todas as funcionalidades, mas a estrutura inicial: uma área para o usuário intergir, um campo de texto com botão na base da tela para enviar dados.

Tela: E001-A

Atualmente, o token do usuário é apenas obtido ao realizar login, sendo que é necessário atualizá-lo de tempos em tempos, pois ele pode expirar se o usuário ficar inativo por muito tempo. Se isso acontece, é necessário realizar login novamente, pois algumas funcionalidades não funcionarão se o token não estiver atualizado.

Portanto, os objetivos desta issue são:

• Implementar a atualização de token
• Deslogar o usuário quando o token está expirado

Atualmente o texto é o mesmo do template. Atualizar para conter informações relevantes. O README do repositório https://github.com/grintex/app-covid é uma ótima fonte a ser copiada sem dó.

Na tela de serviços do aplicativo, deve existir um botão para que o usuário possa fazer uma solicitação. Ao clicar nesse botão, o usuário é apresentado com uma nova tela (ou um modal) que lista todos os serviços disponíveis. A lista de serviços disponíveis estará disponível como um endpoint do web-feedback.

Ao selecionar o serviço desejado, uma tela ou modal semelhante àquela usada no web-feedback deve ser mostrada.

Depois que a aplicação iniciar, o usuário precisa se autenticar com seu idUFFS e senha. Depois que isso acontecer, o usuário poderá acessar as outras telas marcadas como "somente para usuários autenticados".

Essa issue está relacionada a fazer essa autenticação funcionar em termos de informar o idUFFS e qualquer senha, baixar os dados do usuário em questão, e depois permitir que o usuário continue para as próximas telas. Não teremos uma API online que faça a autenticação, então o app pode simplesmente acessar um json qualquer fixo hospedado como um gist para fingir que está falando com a API.

O json pode ter a seguinte estrutura:

{
            "username": "fernando.bevilacqua",
            "uid": "[email protected]",
            "email": "[email protected]",
            "name": "Fernando Bevilacqua",
            "cpf": "4.4.4.333.4",
            "token_id" : "dsdsdsdsd"
}

Como o projeto foi inicializado com base em outro aplicativo, o estilo atual do app não corresponde à identidade visual do PRACTICE. Portanto, é necessário ajustar navbar, cores, fontes e vários outros detalhes para tornar o estilo compatível com o PRACTICE.

Essa tela mostra a conversa em um grupo ou com um usuário em particular. A organização de conteúdo e interação deve ser idêntica ao do Telegram.

Para o cumprimento dessa issue, essa tela não precisa ter funcionamento real, apenas o layout com os elementos clicáveis/etc. A comunicação pode ser falsa.

Tela: C002-A

Visto que o app ainda vai evoluir muito e sua arquitetura de projeto atual é meio obsoleta, faz-se necessário reestruturá-la, pois chegará o dia em que muitas pessoas trabalharão neste projeto e é conveniente manter um padrão de código limpo e atual.

Fara fazê-lo, é necessário redistribuir todos os arquivos em diferentes pastas, renomeá-los de acordo com convenções de nomes (resolver, controller, etc) e ajustar todas as importações para que a mudança de nenhum arquivo afete o funcionamento do app.

Criar a tela inicial conforme a estrutura abaixo.

Tela: H001-A

Elementos que simbolizam texto (retangulos cinza) podem ser trocardos por textos lorem ipsum.

Essa tela mostra uma notícia em particular. No momento, o conteúdo da notícia sendo mostrado pode ser hardcoded para todas as notícias. No futuro, deixaremos isso dinâmico.

Tela: N002-A

Requisito que seja implementado o deploy automático do app no ci.uffs.cc, assim podemos testar o comportamento do app e de seus componentes de formas diferentes, além do app ficar disponível para o restante da equipe.

Visto que o PRACTICE está evoluindo sua arquitetura para criar uma API central modular que pode "acoplar" múltiplos serviços e gerenciar suas requisições, faz-se necessário ajustar as requisições feitas para a API central. Todavia, como esta etapa ainda está em desenvolvimento, será necessário aguardar para que cada alteração seja feita.

• Ajustar autenticação de usuários
• Ajustar gerenciamento de serviços

Visto que é possível solicitar serviços pelo app, faz-se necessário que, ao visualizar a linha do tempo de uma solicitação, seja possível criar cometários diretamente pelo app. Portanto é necessário criar um modal ou um formulário para criação de um comentário e utilizar o endpoint api/service/:id/comments para tornar funcional.

O app do practice precisa ser capaz de gravar audio do microfone do celular do usuário, da mesma forma que o whatsapp/telegram permitem isso. A diferença é que, no nosso caso, usaremos esses audios como narrações de materiais.

O objetivo dessa issue não é desenvolver a tela com a UI/UX necessária para o usuário final. Pelo contrário, o objetivo é desenvolver a funcionalidade básica, que funcione, para que possamos criar a tela depois.

Para isso, na página sobre, colocar em algum local a seção "Experimentos", e lá colocar um link para uma página nova chamada record-audio.html. Essa página deve conter um botão de gravar simples, com dois estados (gravar e parar gravação). Algo estilo o mostrado abaixo:

"

Não precisa se preocupar com a UI, não é o foco.

Em relação a gravação, ela deve, obrigatoriamente, ser armazenada localmente utilizando IndexedDB. Eu recomendo que a lib idb seja usada para isso. O audio precisa ser armazenado no banco do indexedDb com informações sobre a data de criação e duração.

O usuário pode gravar quantos audios quiser, e todos eles ficam disponíveis para consulta. Os audios já gravados devem ser listados nessa página e o usuário pode ouvir o audio ou apagar ele.

Tela: E001-A

Vamos iniciar os trabalhos para que a tela de ambiente comece a ficar funcional. Essa tela tem o objetivo de entregar informações úteis para o contexto no qual o usuário está: se está na biblioteca, mostra informações de locações; se está em um evento, mostra quiz de perguntas do palestrante; se está em aula, mostra opções sobre como o usuário está se sentindo.

O objetivo dessa issue é integrar na tela de ambiente a interface do botui. Depois de integrado, fazer esse exemplo do botui funcionar na tela de ambiente do app. Se tudo der certo, o usuário abrirá a tela de ambiente no app practice e poderá interagir com esse thermostat-bot do exemplo.

Esse exemplo é importante porque ele tem interação "vai-e-vem" entre usuário e contexto. No futuro, teremos várias desse tipo.

Atualmente, a tela de login faz uma simulação de login através do idUFFS. Precisamos que agora o login seja efetivamente feito através de uma requisição ao idUFFS. Mais informações serão adicionadas assim que possível.

Essa tela mostra as informações do usuário que está autenticado e usando o aplicativo. No mínimo, essa tela tem que mostra:

• Nome
• idUFFS

Visto que foram feitas validações de token e webhooks na api, é necessário ajustar o login para realizar a requisição para a nossa api.

Para que o app seja colocado no ar (mesmo que em debug), o projeto precisa ser ajustado em alguns aspectos. Essa issue é voltada a todos esses ajustes (inclusive de documentação para que qualquer pessoa saiba fazer o build).

A tela de notícias deve mostrar um feed de notícias, ao estilo do feed do instagram (imagem mais texto pequeno de informação). Nesse primeiro momento, as notícias podem ser hardcoded de um json ou array em memória.

Tela: N001-A

É necessário a criação de um ícone (1024 x 1024) e uma splash screen (2500 x 2500) para o app. Obviamente, ambas as imagens devem seguir a identidade visual do PRACTICE, o qual se encontra nesta pasta do Drive. Já tem bastante coisa lá, creio que não seja algo tão trabalhoso, utilizar o que já tem pronto é mais que o suficiente.

Tela: S001-A

Implementar a leitura real de códigos QR. Para a implementação dessa tarefa, a lib html5-qrcode deve ser usada obrigatoriamente (a não ser que algo melhor seja encontrado; a saber: rode tanto no browser quanto em cordova; API simples; bom desempenho).

Além de ler um código QR, a aplicação precisa emitir um evento interno chamado qr:read (ver esse docs sobre custom events) com a informação lida no código QR.