fullStackChatApp
1.0.0
AVISO: Há pouco restante para terminar o aplicativo. Ele precisa adicionar as telas de registro do usuário, notificações em segundo plano e as atualizações de dados de solicitações de amizade e novos amigos por meio de soquetes.
Por enquanto, o aplicativo vem se desenvolvendo há um mês, um mês em que passou por períodos de tempo implementando cada requisito básico.
Após a conclusão dos requisitos básicos, os novos requisitos detectados e os restantes mais complexos continuarão sendo implementados.
A criação do aplicativo começou com esboços simples da interface gráfica. Esses esboços foram perdidos por esse motivo, não posso colocá -los aqui. Consulte a última seção onde as fotos do projeto são mostradas.
A interface gráfica foi implementada ao usar dados de teste estático.
Este é o primeiro projeto que de longe tem uma grande diferença dos antigos que eu já fiz. Eu tentei da maneira mais lógica e ideal possível de usar padrões de design para ter código limpo e proteger a lógica de negócios.
Em um limite de tempo, o design foi implementado, o design que teve que ser alterado um pouco (apenas as classes relacionadas às mensagens) devido às limitações do Hive.
Para fornecer um aplicativo rápido e ideal, decidi salvar as mensagens na memória do dispositivo. Para fazer isso de uma maneira, usei a ferramenta Hive, que serve como um banco de dados NOSQL local.
Como uma solução ideal, sempre que novas mensagens venham, eu as salvarei no dispositivo, bem como na RAM, para que a tela de bate -papo não precise fazer o usuário esperar. Somente a última mensagem das conversões existentes do dispositivo será salva na RAM.
Também aqui deve -se notar que as imagens de perfil dos usuários serão armazenadas no dispositivo do usuário, enquanto os endereços das imagens locais serão armazenados na RAM.
Para demonstrar a lógica do servidor, consulte a imagem abaixo.
Veja a imagem, que simula uma sessão de um usuário que envia uma solicitação de amizade para outro usuário.
O exemplo foi dado para ver quando o uso de Websockets seria necessário e quando o uso da API REST.
Operações em tempo real, como enviar mensagens e solicitações de amizade, usarão o WebSockets enquanto operações como abrir uma sessão e atualizar os dados de um usuário usarão a API REST.
Esta é a seção que ainda precisa ser polida. A falta principalmente é otimizar o código da API REST (de uma maneira mais correta), adicione novos métodos à parte dos canais para adicionar novas notificações e adicionar métodos à API e canais REST para os usuários se registrarem.
Para oferecer uma melhor experiência do usuário (no sentido de velocidade), era necessário usar um banco de dados NoSQL, porque dessa maneira os dados do usuário podem ser acessados mais rapidamente.
Claramente, não se pode dizer que esse pensamento está correto, porque, como existem relações entre as identidades, os dados de outros usuários relacionados ao usuário principal terão que ser atualizados.
Em breve, esta seção pode ser alterada e remodelada. Por enquanto, a lógica do modelo é muito básica, cada usuário conterá mensagens que ainda não foram lidas, nomes de usuário, que são seus amigos, nomes de usuário que enviaram solicitações de amizade e dados como nome de usuário, imagens (criptografadas) e muito mais.
Deve -se notar também que o Django ainda não possui oficialmente as integrações de banco de dados NoSQL, por esse motivo que usei a ferramenta Djongo , que é muito curiosa e muito útil, aplica modelos SQL ao MongoDB para proteger a lógica de negócios.
