为了方便后期的维护和版本迭代,说明下 app 的代码结构
app 分包的话按模块划分,网络,数据库操作,bean,provider,service,widget等分别在各自的目录下,ui目录下中包含了所有各版块的界面,其内部按照业务逻辑界面进行划分。
目前使用的是Retrofit+okHttp,各种请求操作封装在 net 包下的RetrofitService,通过CampusRetrofit类的getRetrofitService()方法来获取RetrofitService 的实例。
请求的 url 包括各种界面的数据请求,以及配置文件的拉取。
ccnu 目录下则为模拟登录的爬虫,其逻辑是直接写死在客户端,万一学校信息门户的登录方式改了需要尽快修改其中的代码发版。
目前使用原生的 SQLite,之后在发新版本的时候如果改了数据库的表结构记得在DataBase类中处理好相关的升级逻辑。
SQLite数据库缓存
- 课表
- 部门信息
- 图书搜索历史
- banner 课表的话主要是与服务器同步,现在是每次只要用户联网就向服务器发请求看是否课表一致,这个到时候要改,要不然服务器压力比较大。 部门信息的话是只要部门数量有变化就会更新,(之前有过部门信息给错的情况没更新这点没考虑到) 图书搜索历史:图书搜索历史是直接本地存储,没有上传至服务器,所以用户只要清空缓存就会删掉,当无用户登录状态时也会保存记录。 banner:存储了 banner 的跳转链接,图片地址等。。
SharedPreferences 存储 基本上其他一些数据都是通过这个来存储:用户名,密码,课程表当期那州,校历图片地址等,可以在PreferenceUtil这个类中查看具体的存储数据。用户的学号和密码是直接写了全局静态变量,因为调用比较频繁而且应用的占用内存不大所以被回收的可能性不大。
图片加载的话是用了Fresco这个图片加载库,用之前得了解下它的特性,注意加载的图片长宽是要给定好的。闪屏加载的大图得给16:10的图,因为要考虑到有些手机的分辨率比较奇怪。切图时需要1200x1920的图,设计给图的时候文字离左右两边远点,这样不会导致在某些分辨率下文字显示在边界外面。
- bugly:崩溃分析上报
- 诸葛 io:用户行为分析及反馈
- 信鸽:推送
- TinkerPatch:热修复版本控制平台
平台的账号密码可找组长要。
- 调节请求配置文件的频率,比如一天请求一次,版本号的更新也改为一天请求一次。
- 数据库改用 greenDAO 实现方便做数据库升级以及相关代码的生成。
- 用户反馈疑问比较多的界面完善。