No último post, apresentei-vos um projeto pessoal que encontro-me a desenvolver neste momento relativa a uma aplicação Android para gestão de atividades de um grupo de idosos e falei-vos um bocado sobre alguns problemas que passei na configuração das dependências da aplicação.
Hoje quero vos falar mais especificamente de alguns detalhes da aplicação. Mas antes quero falar sobre um bocado da arquitetura técnica da aplicação.
Neste momento, a pessoa que me pediu esta aplicação quer a aplicação para si mesma, mas é possível que no futuro a aplicação seja usada pela instituição dessa funcionária havendo uma integração de sistemas de informação através de serviços Restful. Pelo que me apercebi da aplicação da instituição, aquilo deve de certeza ter uma API Restful por trás e essa aplicação usa essa API. Se não existir nenhuma API Restful e ser apenas uma plataforma Web REST mas não Restful, é importante que os dados de toda a gente e da instituição sejam migrados para uma API Restful para que se possa integrar a app a desenvolver.
No entanto como se trata de integrar/estender serviços, não vamos apagar aquilo que existe. Vamos aproveitar os dados já existentes e apenas integrar uma outra API Restful personalizada só para este requisito de negócio desta funcionário que representa todas as outras funcionárias.
Aqui está um pequeno esquema do que eu estou aqui a falar:
Duas API's = duas bases de dados. A base de dados da instituição terá os idosos, o serviço Web de autenticação(provávelmente por token Json Web Token). Desta forma o serviço da instituição continua ativo e só existirá um novo serviço Web no mesmo servidor em que terá uma base de dados relacional que terá duas tabelas em que a primeira tabela chama-se Elder e nada mais nada menos será uma cópia da tabela Elder da base de dados da instituição mas com detalhes reduzidos. Digamos, a base de dados da instituição guarda dados médicos dos idosos e o meu serviço não vai trabalhar com dados médicos. Convém que o id do idoso seja o mesmo id do idoso da base de dados da instituição para não causar conflitos nas buscas. Terá também uma outra tabela chamada participações que indicará que atividades os idosos participaram num determinado dia. Uma relação de um para muitos. Um idoso tem várias participações e uma participação pertence a um idoso num determinado dia.
Saindo da arquitetura técnica vou falar um bocado dos ecrãs da aplicação.
O primeiro ecrã, mostrei-vos no post passado, mas voltarei a explicar com mais detalhe:
Este ecrã não contém idosos registados. Na aplicação que a funcionária quer, quer registar os idosos, mas se esta aplicação tiver de ser integrada na empresa, o botão '+' irá desaparecer para o funcionário e só a chefia terá acesso a este botão. Contem uma RecyclerView para representar os idosos sendo esta a recomendação pelo Android Developer, de usar uma RecyclerView para representar listas.
Ao clicar no botão '+', abrirá um novo ecrâ que pedirá o nome do idoso:
Ao carregar no botão de ok, irá adicionar um novo idoso:
De seguida, o funcionário terá um ecrã em que poderá consultar as participações dos idosos em cada dia:
Neste ecrã poderão ver representado um calendário em formato grid. No entanto, eu inicialmente queria que ele fosse paginado em formato de semana e com scroll horizontal mas cheguei à conclusão que era uma solução complexa e custosa. Teria de criar um layout chamado semana e definir todos os dias. Bem que não fosse talvez assim tão complexo. Passava os dias de semana e com o ciclo "for" ia preenchendo os dias da semana desse layout e gerava uma lista nova. Ou seja uma lista de lista de dias. Uma lista de 7 dias. E desta forma conseguiria paginar os dias da semana e fazer o calendário horizontal paginado por semana.
Bem poderei pensar um bocado na ideia no final, mas vamos ver como corre assim. Eu acho que deveria ser paginado por semana, mas isto sou eu, Quando vamos ao calendário nós vemos paginado por semana certo ? Portanto, why not ? Mas é questão de ver. O visual da aplicação fica muito feio assim, é por este motivo que eu não quero em grid porque mostra sempre a abreviatura do dia da semana em cada componente de dia.
Quanto ao botão add, tendo o dia selecionado, ele vai abrir um ecrã que permite adicionar uma participação a esse dia:
É possível selecionar as atividades que participaram e informações extra sobre as participações.
Ao carregar no botão "<-" ele cancelará a adição da participação e voltará ao ecrã anterior.
Ao carregar no botão ok ele vai a criar a participação e vai adicioná-la ao dia.
Agora se eu mudar o dia para 24 ele vai esconder os elementos da lista e vai mostrar as participações desse dia.
Reparem que eu agora se voltar ao dia anterior, ele vai mostrar as participações do dia anterior:
Algumas das coisas que eu acho que a aplicação deverá ter é uma forma de consultar o histórico de participações por semana, ou seja agrupar as participações por semana, isto teria de ter uma lista de listas. Ou seja uma lista com a semana de dia tal até dia tal e as suas participações. Ou então agrupar por idoso e expandir numa activity diferente para cada idoso as participações dessa semana. É questão de estudar e ver.
Uma das aprendizagens que eu retiro destas mockups, sendo as mais importante é:
- Comunicação contínua com o cliente. O engajamento é importante
- Investigar
- Desenhar as nossas ideias num papel. Quando se trata de uma aplicação móvel, pensamos em ecrâs e que dados vão receber.
