经过了小一个月的修改才知道它的客户端上篇已经介绍过了，但我那时候还以为是服务端给数据的，而事实情况是他的服务端只是个中转站，实际的数据是由电脑端一个.net软件进行控制的，我需要模拟数据格式是json进行对服务端请求 服务端才会再用netty进行广播分发给客户端
新的需求是：加入侧滑菜单 加入视频播放+pdf阅读+议程。所以后续的故事开始了。
上篇我们看到了所有界面采用activity 并且通过增加静态方法来让自己打开。但这种侧滑菜单按照谷歌推荐drawerlayout来实现。但不管什么方式都得用fragment啊，由activity变fragment简直就是框架上的大变动，同时还是请外包团队做的pdf这块的下载和优化速度。也怪我当初以为下载成功了就行了。结果这里面有大坑！
他用的是downloadmanager这个第三方框架进行下载。这个框架我必须要好好吐槽下，害人不浅。
1.他会将下载记录到数据库如果直接删除了下载的文件第二次就不会下载因为在数据库里面的记录是已经下载成功的，你还不能手动去更改数据库状态，只能用它提供的api进行删除，非常不利于某些情况下的下载。
2.他的下载一定要在能上网的环境下！组件的局域网明明服务器的其他接口都能访问，由于局域网不能上网，居然就不去下载了！何其蛋疼！
但同时我这期间服务器端的只是长进了不少。首先是配置本来是只会tomcat，文件下载要用到nginx 通过ng映射文件路径从而某个路径下的文件能够下载。学了一部分vue的使用，同时表单的post数据传输居然在其中加入一些div元素就会把对应的参数进行传递了。
由于后来对应的pdf议程要对应会议啊 所以必须要在议程外面再包一层，而单选多选又要对应能编辑选项所以再议程下面又要再多一层 利用前段时间学习的mvc知识，这些最终都做好了，然而噩耗开始，西藏比如的客户要的并不是这一通用版，于是重新设计了一版，由此产生了下一版我自己做的版本。
最主要的是这期版本除了在整体页面上的不符合，还因为pdf的滑动非常延迟卡顿而单独抽出来又不卡所以很怀疑是不是内存等管理不善所导致的或者某些东西占的资源过多，所以需要拿出来一一排查。最主要的是外包团队已经不做了。
网友评论