慵懒的下午写篇小心得

写在前面

回学校将近一个月了，这段时间以来也一直都在做毕设，期间也踩了许多之前未踩过的坑，这篇小心得主要就是针对其中一个小功能做的总结。

功能

先简单介绍一个这个小功能。
这个功能在某种程度上来说类似于以前的那种网上聊天室，但是在表现形式上却跟传统的聊天室有很大的不同。
具体的应用场景是在传统教学课堂上。
以前上课时有过这种经历，老师在提出某个问题并且希望有学生主动回答时，讲台下的我这时候是跃跃欲试的，但是却因为胆小怕回答错迟迟不敢站起来说出正确答案，结果在我犹豫这几秒之后就有其他同学站起来并且说出了我心中的答案，这时候我的心里是极度。。。。的。
那么就针对这样一个场景做了一个小功能，老师在上课时首先打开教师机进入这个小功能的界面，界面如下：

image.png

这时候投影仪就会将教师机显示的内容投影到讲台前方的幕布上，同学们就可以看到这个界面了。这时候同学们可以拿起手机扫描界面左侧的二维码，进入一个发送消息的界面(有些小简陋)，如下图：

image.png

同学们就可以在如上界面中输入自己想说的内容，然后点击确定，就可以发送到教师机上了，动态效果图如下:

手机端

PC端

实现

为了防止使用过程中手抖一刷新就把页面上的这些弹框给刷新掉了，所以必须得针对这些信息做一个存储，就不采用关系型数据库了吧，随便找个Redis来缓存这些信息好了。
再讲接下来的内容之前，先给学生每发送的一条信息(也就是PC弹出来的那个对话框)一个定义，就称它为talk。
为了准确区分账号下的某会话中有哪些talk，也为了避免各个talk存储在Redis中可能会造成的数据冲突，就必须得给talk一个唯一的标识了，这个唯一标识由userid，sessionid，talkid构成，结构如下图：

image.png

可以看到，一个user下有多个session，一个session下有多个talk，这是一个层级关系。也就是说如果现在我要找到某一个talk就得先找到他对应的user，再找到session，才能最终获取到talk，这样不管是修改还是获取都好像有些麻烦，而且对于Redis来说实现这样一个存储关系貌似也有点复杂，
最终想出一个方案，就是将这样一个层级关系给压平，效果如下图:

image.png

在存储talk时就给他这样一个形式的唯一标识，这时候不管是想查找，还是修改，都可以一步到位了，而且这个结构也很简单，就是一个键值对的关系。

我们来看看最终的效果图：

image

可以看到，这时候我点击刷新，就会提示已存在课堂，选择进入之前的课堂，就会加载出之前的所有talk

最后

NULLPointException