fullStackChatApp

完整的堆栈移动聊天应用

内容

• 1. 介绍
• 2. 客户端
  • 2.1。嗯
  • 2.2。记忆
• 3. 服务器端
  • 3.1。应用逻辑
  • 3.2。 NOSQL数据库
• 4. 屏幕截图
• 5. 视频演示

1。简介

警告：几乎没有完成应用程序的剩余时间。它需要添加用户注册屏幕，后台通知以及朋友请求的数据更新和通过插座的新朋友。

目前，该应用程序已经开发了一个月，一个月，它经历了实施每个基本要求的时间。

完成基本要求后，检测到的新要求以及其余更复杂的要求将继续实施。

2。客户端

应用程序的创建始于图形接口的简单草图。由于这个原因，这些草图丢失了，我不能把它们放在这里。请查看显示项目照片的最后一部分。

使用静态测试数据时实现了图形接口。

2.1。嗯

这是迄今为止与我所做的旧项目有很大差异的第一个项目。我尝试以最合乎逻辑，最佳的方式使用设计模式以具有干净的代码并保护业务逻辑。

在一个时间限制中，设计了设计，由于Hive的局限性，必须对设计进行一些更改（仅与消息相关的类）。

• 构建器设计模式被用来以最佳和快速的方式构建主要和次要用户。
• 观察者设计模式用于从服务器接收到数据时（通过插座或REST API）通知客户端。
• 桥梁设计模式用于将非客户相关类别分开，以便客户可以动态调用方法。

2.2。记忆

为了提供快速，最佳的应用程序，我决定将消息保存在设备内存中。为了以某种方式使用hive工具，该工具是本地NOSQL数据库。

作为最佳解决方案，每次新消息都会出现时，我都会将它们保存在设备中以及RAM中，以便聊天屏幕不必使用户等待。设备现有转换的最后一条消息将保存在RAM中。

同样，应该注意的是，用户的配置文件图像将存储在用户的设备上，而本地图像的地址将存储在RAM中。

3。服务器端

3.1。应用逻辑

要演示服务器逻辑，请参见下面的图像。

查看图像，该图像模拟了将朋友请求发送给另一个用户的用户的会话。

给出了示例，以查看何时需要使用Websocket以及何时使用REST API。

诸如发送消息和朋友请求之类的实时操作将使用Websockets，而诸如打开会话和更新用户数据之类的操作将使用REST API。

这是尚待抛光的部分。主要缺少的是优化REST API代码（以更正确的方式），将新方法添加到频道部分以添加新的通知并将方法添加到REST API和频道中，以供用户注册。

3.2。 NOSQL数据库

为了提供更好的用户体验（从速度意义上讲），有必要使用NOSQL数据库，因为这样可以更快地访问用户的数据。

显然，这种想法不能说是正确的，因为由于身份之间存在关系，因此必须更新与主要用户相关的其他用户的数据。

很快，本节可以更改和改建。目前，模型的逻辑非常基本，每个用户将包含尚未读取的消息，用户名是他们的朋友，用户名和数据（例如用户名，图像（加密）等）的用户名。

还应注意的是，Django尚未正式具有NOSQL数据库集成，因此，我使用了Djongo工具，这非常好奇且非常有用，它将SQL模型应用于MongoDB来保护业务逻辑。

4。屏幕截图

5。视频演示

chat.app.flutter.django.django.channels.demo.1.mp4