最近在写一个社交APP的时候,在控制消息计数,及界面红点显示时总会或多或少有延迟或计数偏差,网上大多是对界面绘制的探讨,而在处理数据处理上相对较少,因此,我琢磨着能写一个快捷方便,且只需要配置一次,之后均自动更新数字,显示、隐藏的库。于是有了它 —— SuperBadge (全局角标数据模型管理库)
模型思路
通过树形结构将数字和红点进行分层管理,只关联父级和子级数据, 原则上不越级干扰其他控件,如图例1所示
- 根节点 也可理解为顶级节点,是所有子级节点最终的交汇点,其特点为:没有关联的上级节点(父节点),有关联的下级节点(节点A、节点B、节点C),不能进行增加数字和减少数字操作,能进行已读操作【调用read()方法】;
- 节点A、节点B、节点C 为普通节点,其特点为:有关联的上级节点(根节点),有关联的下级节点(节点1.2.3.4.5.6),不能进行增加数字和减少数字操作,能进行已读操作
- 节点1.2.3.4.5.6 最下级节点,红点数字的直接数据源。其特点为:有关联的上级节点(节点A、节点B、节点C),没有关联的下级节点,能进行增加数字和减少数字操作,能进行已读操作
举个栗子
主界面有【消息】【好友】【我的】三个模块,那么这三个模块均为独立的[根节点],以消息为例。【消息】节点下面绑定了好友会话A[节点A]、好友会话B[节点B]、好友会话C[节点C],每个好友会话下面分别绑定 语音消息[节点1.3.5] 、文本消息[节点2.4.6],如图例2所示
这样的设计方式我们能实现那些功能?
如果我们要在主界面标记为读取所有,那么调用 【消息】的 read()方法即可,其下所有节点数字均会设置为0(不显示);同理,如果我们要读取好友会话A,那么调用好友会话A的 read();语音消息和 文本消息数字均会被设置为0,而【消息】节点会减去好友会话A的数字,通过这种方式,我们在对任意一个层级做出数据更新的时候,其上下级都会联动。
为什么不允许非最下级节点之外的节点进行增减操作?
也可以理解为为什么我只允许在直接关联数据的节点上进行增减操作,其原因很容易理解,假设好友会话A发来一条好友文本消息&#