全栈移动聊天应用

目录

• 1. 简介
• 2. 客户端
  • 2.1. UML
  • 2.2. 内存
• 3. 服务器端
  • 3.1. 应用逻辑
  • 3.2. NoSQL数据库
• 4. 截图
• 5. 视频演示

1. 引言

警告：应用程序即将完成。还需要添加用户注册屏幕、后台通知以及通过socket更新好友请求和新好友的数据。

到目前为止，该应用程序已经开发了一个月，在这一个月中，我们经历了一段时期来实施每个基本需求。

在完成基本需求后，将继续实施新发现的需求和剩余的更复杂的需求。

2. 客户端

应用程序的创建始于简单的图形界面草图。这些草图丢失了，因此我无法在此处展示。请参阅最后一部分，其中展示了项目的照片。

在使用了静态测试数据的情况下实现了图形界面。

2.1. UML

这是我迄今为止做过的与以往项目差异最大的项目。我已尽最大可能以最逻辑和最优化方式使用设计模式来获得干净的代码并保护业务逻辑。

在时间限制内，实现了设计，但由于Hive的限制，不得不对设计进行一些更改（仅限于与消息相关的类）。

• 使用了建造者设计模式，以便能够以优化且快速的方式构建主要用户和次要用户。
• 使用了观察者设计模式来通知客户端何时从服务器接收到数据（通过sockets或rest api）。
• 使用了桥接设计模式来分离与客户端无关的类，以便客户端可以动态调用方法。

2.2. 内存

为了提供一个快速且优化的应用程序，我决定将消息保存在设备内存中。为此，我使用了hive工具，它作为一个本地nosql数据库。

作为一项优化解决方案，每次收到新消息时，我都会将其保存在设备中，同时保存在RAM中，以便聊天屏幕不会让用户等待。现有对话的最后一条消息将保存在RAM中。

这里还应该注意的是，用户的个人资料图片将存储在用户的设备上，而本地图像的地址将存储在RAM中。

3. 服务器端

3.1. 应用逻辑

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

看看这张图片，它模拟了一个用户向另一个用户发送好友请求的会话。

举这个例子是为了说明何时需要使用websockets以及何时需要使用rest api。

发送消息和好友请求等实时操作将使用websockets，而打开会话和更新用户数据等操作将使用rest api。

这是仍需打磨的部分。主要缺失的是优化rest api代码（以更正确的方式）、向channels部分添加新方法以添加新通知，以及向rest api和channels添加用户注册方法。

3.2. NoSQL数据库

为了提供更好的用户体验（在速度方面），有必要使用nosql数据库，因为这样可以更快地访问用户数据。

显然，这种想法不一定是正确的，因为在身份之间存在关系，所以必须更新与主用户相关的其他用户的数据。

很快，这一部分就可以进行更改和重新建模。目前，模型逻辑非常基础，每个用户将包含未读消息、是好友的用户名、发送过好友请求的用户名以及诸如用户名、（加密的）图片等数据。

还应该注意的是，django尚未官方支持nosql数据库集成，因此我使用了djongo工具，这非常有趣且非常有用，它将sql模型应用于mongodb以保护业务逻辑。

4. 屏幕截图

5. 视频演示

GitHub

查看 Github