4.1 Interfaces da aplicação móvel
4.1.4 Profile Stack: os dados do pessoais
Como mostrado na seção 3.3.2.4, a pilha de navegação Profile Stack possui três telas: Profile.js, EditProfile.js e ChangePassword.js. A figura 32 mostra a interface final destas telas, enumeradas de 1 a 3. A tabela 8 mapeia o número mostrado na figura 32 com as telas descritas na seção 3.3.2.3.
Quando a aplicação navega até a pilha de navegação de perfil, através de um toque do usuário no item 4 da figura 22, o usuário é apresentado à tela Profile. Esta tela, ao
Figura 31 – Página de detalhes do pedido. 1: em andamento, 2: cancelado, 3: finalizado Fonte – Própria
Figura 32 – Página de perfil do usuário. 1: perfil, 2: editar perfil, 3: mudar senha Fonte – Própria
Tabela 8 – Mapeamento da figura 32 para as telas da pilha de navegação Númeração Tela 1 Profile.js 2 EditProfile.js 3 ChangePassword.js Fonte – Própria
ser montada, recupera as informações do usuário autenticado e atualiza o seu estado em nível de componente. Por consequência, o React invoca o método render e o componente renderiza a tela 1 da figura 32 para o usuário. Na imagem, os dados pessoais do usuário são parcialmente cobertos para que a privacidade seja mantida. A tela Profile.js apresenta 6 opções para o usuário da quais apenas 2 ocasionam em navegação na plataforma: edição de perfil e troca de senha. As demais opções levam o usuário para um site ou aplicativo de e-mail padrão do telefone.
Quando o usuário seleciona a edição de perfil, tocando no lápis presente no canto superior direito da tela 1 da figura 32, a aplicação navega até a tela EditProfile. Quando montada, a tela recupera as informações do usuário autenticado que estão presentes no estado da em nível de aplicação. Assim, a tela invoca a função render e renderiza a interface número 2 da figura 32. Novamente, os dados pessoais do usuário foram parcialmente cobertos para que a privacidade seja mantida. O usuário pode editar os campos de: nome, e-mail e telefone. CPF e data de nascimento são campos considerados imutáveis e não podem ser atualizados pelo usuário. Após a edição, o usuário toca no botão "Salvar"para que suas mudanças sejam persistidas na API. A aplicação faz uma requisição HTTP PATCH apenas com as informações enviadas pelo usuário. Em caso de falha, a API retorna um HTTP 400 com uma mensagem de erro. Mas nem todos os campos podem ser alterados. Em caso de sucesso, o retorno da API possui um código HTTP 200, a aplicação mostra uma mensagem de sucesso ao usuário e navega de volta para a tela Profile.js.
De volta a tela Profile.js, o usuário pode escolher mudar a sua senha tocando em "Mudar a senha", fazendo a aplicação navegar até a tela ChangePassword.js. Esta tela,
diferente das outras, não recupera nenhuma informação, apenas renderiza o formulário contento: senha original, nova senha e confirmação da nova senha. Ao finalizar o preen- chimento do formulário, o usuário toca no botão "Salvar nova senha"para persisti-la na API. No momento que o usuário toca neste botão, a aplicação móvel checa se a nova senha e confirmação da nova senha são iguais. Se não, o usuário recebe uma mensagem de erro avisando deste fato. Caso sim, a aplicação faz uma requisição HTTP POST para a API contento no corpo a senha atual e a nova senha. A API vai checar se a senha atual é realmente a enviada pelo usuário e, se sim, atualiza-la com a nova senha enviada na requisição. Em caso de falha, a API retorna um HTTP 400 com uma mensagem contendo
o erro. Em caso de sucesso, o usuário recebe uma mensagem de sucesso e a aplicação navega de volta para a tela de Profile.js.
5 CONCLUSÃO
Neste Capítulo são apresentadas as conclusões sobre este trabalho de pesquisa a partir da visão dos objetivos gerais e secundários propostos, assim como as possibilidades de trabalhos futuros.
Este trabalho teve como objetivo geral o desenvolvimento de uma plataforma de e-commerce com foco em delivery, da API à aplicação móvel. Para atingir este objetivo geral, foram traçados objetivos secundários como forma de checkpoints.
O primeiro objetivo secundário foi a modelagem do banco de dados para os casos de uso do e-commerce. Para isto, foi necessário aplicar o conceito de diagrama entidade relacional, entender de que forma as entidades se relacionam e, assim, disponibilizar uma estrutura de banco de dados com uso focado para o delivery.
O segundo objetivo secundário foi a implementação das regras de negócio e dispo- nibilização delas através de uma API. Com a ajuda do Django REST Framework e das entidades modeladas no primeiro objetivo, as regras de negócio referentes a autenticação de usuários, compra, venda e entrega de produtos foram possíveis.
O terceiro objetivo secundário foi a implementação da aplicação móvel. Utilizando React Native, tecnologia baseada no desenvolvimento híbrido, foi possível desenvolver esta aplicação e disponibiliza-la nas lojas de aplicativos App Store1 e Play Store 2 sob o nome
DrinkApp - Delivery de Bebidas.
O quarto objetivo foi fazer com eque esta implementação seja utilizada por usuários. Até às 23:59 do dia 22/11/2019, de acordo com os dados da App Store, o aplicativo final já foi baixado 2346 vezes nesta plataforma e de acordo com a PlayStore o aplicativo final já foi baixado 8566 vezes. Até às 16:05h do dia 23/11/2019, de acordo com a tabela CUstomer, mencionada na seção 3.1.1, esta aplicação teve 6462 clientes cadastrados.
O quinto objetivo secundário foi a validação da implementação através de vendas e cadastros da aplicação móvel. Os dados de downloads e cadastro foram citados acima. E, até às 16:05h do dia 23/11/2019, esta aplicação já recebeu R$ 95,740.72 em pedidos.
Por estes cinco objetivos, a aplicação final conseguiu lograr êxito no que foi proposto como objetivo deste trabalho.
1https://www.apple.com/ios/app-store/ 2https://play.google.com/