技术领域

本发明涉及计算机通信网络技术， 特别涉及一种实现微博消息页的 方法和装置。 发明背景

即时通信 ( IM, Instant Messaging )工具已经成为人们日常沟通必不 可少的工具。 因此， 用户对 IM工具软件的易用性、 稳定性和安全性等 方面提出了更高的要求。 目前， IM软件主要实现一对一的单独消息聊 天模式和一对多的群或讨论组的消息聊天模式 。

微博作为一种扩展 IM消息传播机制的新生事物也得到了快速发展� �� 微博用户可以用 140个字左右的一句话来表达自己思想， 这种方式可以 快速地传播消息， 从而实现了用户消息聊天模式从一对一、 一对多到一 对无穷的跨越。

从内容上看， 在微博消息页中可能出现的内容主要分成以下 几类, 如表一所示：

内容类型 说明

微博消息 微博产品的核心， 即用户发表的内容， 通常还会包含一 些附加信息。

"消息拉 如果用户操作触发了从服务器拉取消息的逻辑 ， 那在消 取中"信息 息拉取完毕之前， 需要向用户展现 "拉取中" 的状态。 断层信息 每次拉取操作通常都是以微博消息的发表时间 为序进行 批量拉取， 并且每批拉取的消息条数会有一个上限值。 断层出现的条件是： 如果前后两批微博消息， 在发表时 间线上没有交集， 说明在这两批消息之间可能存在部分 微博消息没有拉取回来。此时，需要向用户展 现一个 "断 层信息"。

上限信息 当一次消息拉取操作完成之后， 如果检查到当前消息页 内的消息总数已经超过了最大条数限制， 则需要向用户 提示已经达到上限。

其他信息 根据应用场景的不同， 在微博消息页中可能还会出现其 他内容。 比如， 当进入某用户的消息页时， 除了微博消 息以外， 还需要展示该用户的一些个人资料信息。

从界面组成的角度上看， 不同类型的内容被封装成不同的界面控件 来展现， 换句话说， 微博消息页成为控件的容器， 其最主要的作用是对 其中的控件进行创建、 销毁和布局排序的管理。

然而， 在对消息页的控件进行创建或销毁的时候， 会与具体的应用 场景对应的消息更新逻辑发生耦合， 影响可复用性。 以主页和客人页为 例： 主页展示的消息包括： 自己发表的微博消息和自己收听的人发表的 微博消息， 而客人页所要展示的消息仅包括某一用户发表 的微博消息。 由于两个页面内展示的消息来源有所区别， 所以在技术实现上需要开发 两套消息的拉取（更新）逻辑。 然而， 现有技术没有将消息的拉取（更 新）逻辑和展现逻辑分开， 因此当消息拉取回来之后， 主页和客人页需 要根据拉取到的消息各自开发一套界面的展示 逻辑。

另外， 消息页在对各种控件进行排序布局管理的时候 ， 首先根据不 同类型的控件进行排序， 然后再对微博消息控件按照发表时间进行排 序， 排序算法比较复杂， 性能较差。 发明内容

本发明实施例在于提出一种用于实现微博消息 页的方法和装置，使 得消息页在对各种控件进行排序布局管理的时 候， 排序算法更加筒单和 高效。

为了实现本发明的发明目的， 本发明的技术方案为：

一种用于实现 專消息页的方法， 包括：

将多个消息页的公用逻辑封装在消息页基础控 件中；

拉取所述多个消息页之一的消息页控件的内容 数据；

使所述多个消息页之一的消息页控件继承所述 封装在消息页基础控 件中的公用逻辑；

该方法还包括：

执行所述公用逻辑以根据所拉取的内容数据， 将所述多个消息页之 一的消息页控件加载并展示到所述多个消息页 之一上。

一种用于实现微博消息页的装置， 包括：

消息页基础控件模块， 用于将多个消息页的公用逻辑封装在消息页 基础控件中；

控件数据拉取模块， 用于拉取所述多个消息页之一的消息页控件的 内容数据； 和

消息页控件模块， 用于使所述多个消息页之一的消息页控件继承 所 述封装在消息页基础控件中的公用逻辑， 并且执行所述公用逻辑， 其中 所述消息页控件模块包括： 加载单元， 用于根据所拉取的内容数据加载 所述多个消息页之一的消息页控件； 和展示单元， 用于将所述多个消息 页之一的消息页控件展示到所述多个消息页之 一上。

从上述方案可以看出， 本发明实施例提供的一种实现微博消息页的 方法和装置， 通过将多个消息页的公用逻辑封装在消息页基 础控件中， 并且每个消息页控件继承该公用逻辑， 可以方便地增加一类消息页， 同 时这类消息页的统一管理类进行管理， 极大地提高了代码架构的可扩展 性与可维护性， 而且对于开发过程来说， 极大提高了开发效率。 附图简要说明

为了更清楚地说明本发明实施例中的技术方案 ， 下面将对实施例中 所需要使用的附图作筒单地介绍， 显而易见地， 下面描述中的附图仅仅 是本发明的一些实施例， 对于本领域普通技术人员来讲， 在不付出创造 性劳动性的前提下， 还可以根据这些附图获得其他的附图。

图 1示出了根据本发明实施例的用于实现微博消� �页的方法的示意 性流程图；

图 2示出了根据本发明另一实施例的用于实现微� �消息页的方法的 示意性流程图；

图 3示出了根据本发明的示例性实施例的用于实� �微博消息页的方 法的示意性流程图；

图 4示出了根据本发明实施例的用于实现微博消� �页的装置的结构 图；

图 5A和 5B示出了根据本发明实施例的微博消息页的界� ��层次结构 图和用于实现微博消息页的类图；

图 6A至 6C示出了根据本发明实施例的微博基础消息页� ��界面结构 图和用于实现微博基础消息页的类图；

图 7是示出了根据本发明的示例性实施例的用于� �现微博消息页的 类图。 实施本发明的方式

为使本发明的目的、 技术方案及优点更加清楚明白， 下面将结合本 发明实施例中的附图， 对本发明实施例中的技术方案进行清楚、 完整地 描述， 显然， 所描述的实施例仅是本发明一部分实施例， 而不是全部的 实施例。 基于本发明中的实施例， 本领域普通技术人员在没有作出创造 性劳动前提下所获得的所有其他实施例， 都属于本发明保护的范围。

微博作为一种扩展 IM消息传播机制的新应用， 最重要功能的展示 各类的消息页， 例如最常用的主页、 客人页以及@消息页。 除了这类基 本的消息页之外， 随着微博应用的不断扩展， 增加了类似广播大厅消息 页、 话题消息页、 转播聚合消息页、 地理位置聚合消息页或者对话消息 页等等， 因此从这种角度看， 对于这类多消息页的展示需要一种更加快 速的添加与开发的技术方案， 以提高多消息页的管理与维护性。

因此， 本发明实施例提出了一种有效提高消息页的可 扩展性的技术 方案， 在该技术方案中， 各种消息页的公用逻辑被封装在实现消息页基 础控件的基础类中， 而通过使实现消息页控件的类继承该基础类实 现复 用。 通过实现该技术方案， 可以非常方便地增加一类消息页， 同时这类 消息页的统一管理类进行管理， 极大的提高了代码架构的可扩展性与可 维护性， 对于开发过程来说， 极大提高了开发效率。

以上是本发明实施例的总体构思， 下面将详细给出示例性的实施方 案， 以便于本领域技术人员理解本发明。

图 1示出了根据本发明实施例的用于实现 專消息页的方法 100的 示意性流程图。

参见图 1 , 该方法 100包括：

步骤 110, 将多个消息页的公用逻辑封装在消息页基础控 件中。 在该步骤中， 为了方便各种消息页的扩展， 将各种消息页的公用逻 辑封装于消息页基础控件（MsgPageCtrlBase ) 中。 在这里， 公用逻辑可 以包括下面的一个或多个： （1 )根据拉取回来的消息加载控件； （2 )对 当前消息页内的各种控件进行排序； （3 )根据排序后的结果， 结合各个 控件的尺寸， 进行界面上的布局控制。 例如， 公用逻辑可以包括用于装 载大多数微博消息页都要展示的消息控件、 加载中控件、 更多控件和 / 或断层控件等等的逻辑。 另外， 有的消息页还可能包括特有的控件， 例 如在客人页中包括展示客人资料的控件， 这些控件由专用的逻辑来加 载。

本发明针对微博消息页以及在页面中可能出现 的内容类型设计了对 应的控件类型， 如表 2所示的消息页控件类型说明：

控件类型 内容类型 说明

消息控件 微博消息 一个 MsgltemCtrl用于展示一条微博消息

(MsgltemCtrl) 以及其附加信息

加载中控件 表示正在 LoadingltemCtrl 上会展示一个表示等待

(LoadingltemC "消息拉 的动画。 一批消息开始拉取时出现， 拉 trl) 取中" 的 取完毕之后控件消失， 并在它原来的展 状态信息 现位置插入新拉取回来的这批消息。 断层控件 断层信息 满足断层出现的条件时， 在相邻的两个

(FaultltemCtrl) MsgltemCtrl 之 间 会 插 入 一 个

FaultltemCtrl, 在 FaultltemCtrl上面显示 一个信息断层的图片和提示语。

"更多" 控件 上限信息 当 MsgltemCtrl达到或超过消息页上限的 MoreltemCtrl 时候才显示， 并且可以只显示在消息页 的底部， 并且可以只有一个。 "其他" 控件 其他信息 "其他" 控件可以一律只显示在消息页 的顶部， 并且可以只有一个。

消息页控件 对应于整 是以上所有控件的容器。 按照排序规则，

(PageCtrl) 个微博消 将所有 ItemCtrl按照垂直方向排成一列。

息页 MoreltemCtrl可以只出现在底部， "其他" 控件则可以只出现在顶部。

步骤 120, 拉取多个消息页之一的消息页控件的内容数据 。

本步骤中， 每个消息页根据拉取逻辑拉取消息页控件所要 展示的内 容数据。

步骤 130, 使多个消息页之一的消息页控件继承公用逻辑 。

本步骤中， 不同应用场景下的消息页只需要继承消息页基 础控件即 可复用这些公用逻辑， 从而提高可复用性。

步骤 140, 执行公用逻辑以根据所拉取的内容数据将多个 消息页之 一的消息页控件加载并展示到所述多个消息页 之一上。

本步骤中， 消息页控件由于继承而各自具备了公用逻辑的 功能， 并 且各种消息页的消息页控件可以执行各自继承 的公用逻辑以根据所拉 取的内容数据将其所包括的各个控件加载并展 示到消息页上。 例如， 消 息页控件通过继承公用逻辑将至少一个消息控 件、 至少一个加载中控 件、 至少一个断层控件和 /或更多控件加载并展示到消息页上， 当然， 本 发明并不限于这些控件。

图 2 示出了根据本发明另一实施例的用于实现微博 消息页的方法

200的示意性流程图。

参见图 2, 该方法包括：

步骤 210, 将多个消息页的公用逻辑封装在消息页基础控 件中。 步骤 220, 使消息页的消息页控件继承消息页基础控件中 的公用逻 辑。

步骤 230, 如果消息页中包括了其他控件， 则执行步骤 290, 否则继 续执行步骤 240。

在本步骤中， 其他控件的加载及展示需要专用的逻辑来实现 ， 在这 里， 将这种专用的逻辑称为其他逻辑。

步骤 240, 拉取消息页内容数据。

本步骤中， 可以执行消息页的拉取（更新）逻辑来拉取消 息页内容 数据。

步骤 250 , 根据拉取的消息页内容数据加载消息页控件。

本步骤中， 执行所继承的公共逻辑中的消息页控件加载逻 辑和其它 逻辑中的加载逻辑， 以将消息页内容数据封装成消息页控件。

步骤 260, 获取消息页控件中各控件的时间值和尺寸。

本步骤中， 如果消息页不包括除了所继承的公共控件之外 的其他控 件， 则消息页控件需要通过多个消息页的消息页控 件公共接口获取至少 一个消息控件、 至少一个加载中控件、 至少一个断层控件和 /或更多控件 的时间值和尺寸。 如果消息页中包括其他控件， 则消息页控件还需要另 外获取其他控件的时间值和尺寸。 消息页控件负责加载各种类型的控 件， 并负责它们的排序和布局。 就这个逻辑而言， 消息页控件需要从它 所加载的各个控件上获取用于排序的时间值信 息以及用于布局的尺寸 信息。

在实际应用中， 在实现消息页时从消息页控件所加载的各个控 件上 抽象出了共同的接口， 消息页控件公共接口， 而该共同的接口提供了供 消息页控件获取各个控件的时间值和大小的方 法。

步骤 270, 根据所获取的时间值和尺寸对消息页中各控件 进行排序 和布局。

如果消息页中不包括其他控件， 则消息页控件分别根据所获取的时 间值和尺寸对至少一个消息控件、 至少一个加载中控件、 至少一个断层 控件和 /或更多控件进行排序和布局。如果消息页中� �括其他控件， 则消 息页控件还需要同时对其他控件进行排序和布 局。

在实际应用中， 消息页内各个控件的排序规则可以基于时间值 的大 小顺序。 在微博消息页 (PageCtrl)中， 各种控件 （ ItemCtrl )按照垂直方 向排成一列， 其中微博消息 (MsgltemCtrl)是主体， 每一条微博消息都有 一个发表时间， 不同的消息页以发表时间为序， 越新的消息越接近于顶 部。

例如， 将消息的发表时间（年 /月 /日 /时 /分 /秒）换算之后， 可以得到 一个以秒为单位的 32位无符号整数值， 这个值越大， 说明发表时间越 接近当前时间， 也就是消息越新。 所以在处理消息页的排序时只需要筒 单地根据这个时间值大小进行排序即可。

进一步， 对于加载 中控件（LoadingltemCtrl)和断层控件 (FaultltemCtrl), 可以根据它们出现位置附近的消息页的时间值 来确定控 件本身的时间值。 "更多" 控件 （ MoreltemCtrl ), 由于可以只出现在消 息页底部， 所以可将其时间值设置为 0 (根据换算规则， 正常的发表时 间不会出现该值）； "其他" 控件由于可以只出现在消息页顶部， 所以可 以将其时间值设置为 4294967295 (即 232-1 , 根据换算规则， 正常的发 表时间不会出现该值）。 当然， 本发明并不限于此， 只要其它控件和更 多控件的时间值与消息控件的时间值不发生沖 突即可。

这样， 对于消息页内所有控件的排序规则都可以统一 为根据控件对 应的时间值大小进行排序， 在垂直方向上， 各个控件按照从上到下， 时 间值从大到小的顺序排列。 根据本发明的另一实施例， 消息页内各个控件可以是等宽的， 所以 在布局上， 只需要按照从上到下的顺序取得控件的高度， 即可确认各个 控件的布局位置。 当然， 本发明的不限于此。

根据本发明的又一实施例， 可以设置其他控件具有最大的时间值， 更多控件具有最小的时间值， 并且消息控件所展示的消息发表的时间越 晚， 消息控件的时间值就越大。 另外， 加载中控件和断层控件的时间值 才艮据与加载中控件和断层控件相邻的控件的 时间值来确定。

步骤 280 , 将消息页中各控件展示到消息页上。

本步骤中， 如果消息页不包括其他控件， 则将多个消息页之一的消 息页控件展示到多个消息页之一上； 如果消息页包括其他控件， 则还需 要将其他控件展示到多个消息页之一上。

步骤 290, 将消息页的其他逻辑封装在其他控件中， 继续执行步骤

240。

本步骤中， 将多个消息页之一的其他逻辑封装在多个消息 页之一的 其他控件中。

在实际应用中， 本发明并不限于步骤 250至步骤 280的顺序。 换句 话说， 可以根据需要同时或交替进行各控件的加载、 排序、布局及展示。

根据本发明的另一实施例， 该方法还可以进一步包括： 分别将相应 的管理逻辑封装在相应的管理控件中， 其中消息页控件分别通过相应的 管理控件管理至少一个消息控件、至少一个加 载中控件和 /或至少一个断 层控件。 例如， 目前出现在消息页中的加载中控件有三种， 这三种控件 有可能同时出现， 所以在加载中控件和消息页基础控件之间添加 了一个 用于管理加载中控件的管理控件， 用来处理各个加载中控件的逻辑。

图 3示出了根据本发明的示例性实施例的用于实� �微博消息页的方 法的示意性流程图。 根据应用场景的不同， 在微博消息页中可能会出现该消息页特有的 内容。 例如， 当进入某用户的消息页 （筒称为客人页， GuestPageCtrl ) 时， 当前客人页除了需要展示该用户发表的微博消 息以外， 还需要展示 该用户的一些个人资料信息。 因此， 客人页会有一个自己特有的控件， 即客人资料控件 （ GuestlnfoCtrl ), 需要插入到客人页之中。

参见图 3 , 根据本发明的实施例的实现客人页的方法包括 ： 步骤 310, 将多个消息页的公用逻辑封装在消息页基础控 件中。 在 这里， 这些消息页包括客人页。

步骤 315 , 使客人页的客人页控件继承公用逻辑。 客人页控件可以 包括或装载客人页消息控件、 客人页加载中控件、 客人页更多控件和 / 或客人页断层控件。

步骤 320, 将客人页的其他逻辑封装在客人资料控件中。 在这里， 客人页控件另外包括或装载客人资料控件， 即上文中提及的其他控件， 而其他逻辑用来将客人资料控件加载到客人页 上。

步骤 325 , 获取客人页控件中各控件的时间值和尺寸。

获取客人页控件中各控件的时间值和尺寸的步 骤见图 2所描述的实 施例。 而在本实施例中， 客人页控件可以通过调用继承于消息页控件公 共接口的客人资料控件接口来获取所述客人资 料控件的时间值和尺寸。

步骤 330, 将客人资料控件排列在客人页的顶部。

本步骤中， 先创建客人资料控件， 以展示该微博用户的基本资料。 根据所获取的客人资料控件的时间值和尺寸将 客人资料控件排列在客 人页的顶部。 在实际应用中， 这可以通过将客人资料控件的时间值设为 最大值来实现。

步骤 335 , 按照发表的时间拉取客人页消息数据。

本步骤中， 通过客人页本身的微博消息更新逻辑（ GuestPageLogic ) 发起一次更新操作， 例如， 当用户第一次进入客人页时， 按照客人页消 息的发表时间拉取之前发表的最新的 30条消息。 而当用户再次进入客 人页， 或者收到服务器的消息更新消息后， 同样可以触发步骤 335 , 从 而拉取比之前拉取的消息更新的消息。

步骤 340, 判断是否有新的客人页消息需要加入。

本步骤中， 如果有新的客人页消息需要加入到客人页中， 执行步骤 370, 否则执行步骤 345 , 以根据不同的情况进行相应的处理。 这是因为 步骤 335按照发表时间顺序拉取历史客人页消息， 当有新的客人页消息 需要加入时， 在拉取新的客人页消息之后可能会出现诸如消 息不连续之 类的断层等问题。

步骤 345 , 判断是否返回客人页消息。

本步骤中， 如果没有及时返回客人页消息， 换句话说， 没有及时将 消息拉取回来， 则执行步骤 395 , 否则继续执行步骤 350。 当然， 在实 际应用中可以省略步骤 345和步骤 395而直接执行步骤 350。

步骤 350, 根据返回的客人页消息数据加载客人页消息控 件。

本步骤中， 消息拉取回来之后， 可以根据拉取回来的数据加载各个 客人页消息控件。

步骤 355 , 按照时间顺序展示客人页消息控件并隐藏相应 的客人页 加载中控件。

本步骤中， 消息拉取回来之后， 在客人页插入相应的客人页消息控 件， 并根据客人页消息控件的时间值和尺寸进行排 序和布局并展示在客 人页中， 同时把该客人页加载中控件隐藏。 例如， 最新的客人页消息控 件在客人资料控件之后依次排列。

步骤 360, 是否超出客人页的最大消息数目限制？

本步骤中， 重复执行步骤 335至 355 , 直到所加载的客人页消息控 件的数目超出客人页的最大消息数目限制。 如果超出最大消息数目限 制， 则执行步骤 365。

在实际应用中， 当前用户所发表的消息可能大于 30条，也就是说服 务器上可能还存在未拉取到本地的历史消息， 所以当用户自上往下浏览 到当前展示的最后一条消息的时候， 需要再触发一次更新操作， 拉取发 表时间在最后一条已展示的消息之后另外 30条消息， 在消息未返回之 前， 在消息页的底部 （即最后一条消息下方）， 需要展示加载中控件。 消息拉取回来之后的处理逻辑与步骤 350和步骤 355的相同。

步骤 365 , 在客人页的底部展示客人页更多控件。

本步骤中， 如果所加载的客人页消息控件的数目超出客人 页的最大 消息数目限制， 则客人页更多控件被展示在所述客人页的底部 。 换句话 说， 如果用户重复执行步骤 335至 360的操作， 消息页的最大消息数可 能超过最大限制， 此时在底部展示客人页更多控件， 且不再触发历史消 息的拉取操作， 即超过最大限制则不再追加历史消息。 在这里， 所谓的 "客人页更多控件" 可以是能够表示还有更多消息没有展示的提示 语或 者图片。

步骤 370, 判断是否超出所述客人页的最大消息数目限制 ， 如果是， 则执行步骤 390, 否则继续执行步骤 375。

步骤 375 , 判断与已展示的客人页消息在发表时间上是否 有交集。 本步骤中， 需要通过判断待加入的新的客人页消息与已展 示的历史 消息在发表时间上是否有交集， 以确定是否存在断层问题， 如果没有交 集， 则说明存在断层问题， 则执行步骤 345 , 如果有交集， 则说明没有 断层问题， 则直接执行步骤 380。

步骤 380, 展示相应的客人页断层控件， 并继续执行步骤 385。 如果发现拉取回来的更新的客人页消息与本地 已经展现的客人页消 息在发表时间上没有交集， 则需要在最新拉取的那一批消息的末尾插入 客人页断层控件， 例如， 该客人页断层控件的时间值等于其上方那条消 息的时间值减 1。

步骤 385 ,当用户点击相应的客人页断层控件时，继续� �行步骤 345 , 加载与客人页断层控件的时间值对应的时间之 后的预定数目的客人页 消息控件。 例如， 用户可以通过点击客人页断层控件， 触发拉取客人页 断层的时间值对应的时间之后 30条消息。 如果用户没点击客人页断层 控件， 则可以只展示客人页断层控件。 当然， 在实际应用时， 也可以根 据需要省略步骤 375至步骤 385。

步骤 390, 从所述客人页的底部移除相等数量的客人页消 息控件。 本步骤中， 当有新的消息需要加入消息页， 如果所装载的客人页消 息控件的数目超出客人页的最大消息数目限制 ， 则从客人页的底部移除 相等数量的客人页消息控件， 并继续执行步骤 375 , 以将与更多新的客 人页消息对应的客人页消息控件加入到客人页 中。

步骤 395 , 展示相应的客人页加载中控件。

本步骤中， 在消息未返回之前， 可以在消息页中展示加载中控件， 以提示用户客人页正在加载消息。

根据本发明的另一实施例， 上述尺寸指宽度， 即其他控件、 至少一 个消息控件、 至少一个加载中控件、 至少一个断层控件和 /或更多控件的 宽度相等并根据时间值的大小顺序在消息页上 从上到下进行排列。

图 4示出了根据本发明实施例的用于实现 專消息页的装置 400的 结构图。

参见图 4, 该装置 400主要包括： 消息页基础控件模块 410、控件数 据拉取模块 420和消息页控件模块 430。

消息页基础控件模块 410, 用于将多个消息页的公用逻辑封装在消 息页基础控件中。

控件数据拉取模块 420, 用于拉取多个消息页之一的消息页控件的 内容数据。

消息页控件模块 430, 用于使多个消息页之一的消息页控件继承公 用逻辑， 并且执行所述公用逻辑， 其中消息页控件模块包括： 加载单元 431 , 用于根据所拉取的内容数据加载多个消息页之 一的消息页控件； 和展示单元 432, 用于将多个消息页之一的消息页控件展示到多 个消息 页之一上。

根据本发明的另一实施例， 该装置可以进一步包括： 消息页其它控 件模块 440, 用于将多个消息页之一的其他逻辑封装在多个 消息页之一 的其他控件中。

根据本发明的又一实施例， 消息页控件模块 430可以进一步包括： 管理单元 434, 用于分别将相应的管理逻辑封装在相应的管理 控件中， 以供消息页控件分别通过相应的管理控件管理 消息页控件所包括的各 个控件。

根据本发明的再一实施例， 消息页控件模块 430可以进一步包括： 排序布局单元 433 , 用于通过消息页控件公共接口获取各控件的时 间值 和尺寸， 并且分别根据所获取的时间值和尺寸各个控件 进行排序和布 局。

通常， 上述消息页控件所展示的内容数据可以从服务 器获取， 而消 息页可以显示在显示器上。 由于本领域技术人员知道如何实现从服务器 获取数据以及将消息页显示在显示器上， 因此， 这里不再详细描述。

下面主要结合本发明的消息页的界面层次结构 图和实现消息页的类 图来进一步描述本发明的装置的功能。

图 5A和 5B示出了根据本发明实施例的微博消息页的界� ��层次结构 图和用于实现微博消息页的类图。图 6A至 6C示出了根据本发明实施例 的微博基础消息页的界面结构图和用于实现微 博基础消息页的类图。 图 7是示出了根据本发明的示例性实施例的用于� �现微博消息页的类图。 在这些图中， 空心三角形箭头表示继承关系， 例如， 在图 5B 中 IFaultltemCtrl继承 IPageltemCtrl的功能。 菱形实心箭头表示包含关系， 并且该关系是一对一的， 例如， 在图 6C中， 一个 MsgPageCtrlBase对象 里面有一个接口为 IMsgltemCtrlMgr的对象。 菱形空心箭头也表示包含 关系， 但该关系是一对多的， 例如在图 6C 中， 一个 CMsgltemCtrlMgr 对象里面会包含多个接口为 IMsgltemCtrl的对象。

参见图 5A可以看出， 微博消息页控件（PageCtrl )是一个容器。 它 负责加载各种类型的控件 （ItemCtrl ), 负责它们的排序和布局。 就这个 逻辑而言， PageCtrl需要从 ItemCtrl上面获取的信息非常筒单： 用于排 序的 ItemCtrl的时间值信息以及用于布局的 ItemCtrl的尺寸。 以客人页 为例， 客人页控件可以包括或装载至少一个消息控件 （MsgItemCtrl )、 至少一个加载中控件 （ LoadingltemCtrl )、 至少一个断层控件

( FaultltemCtrl )、 更多控件 （ MoreltemCtrl ) 和 /或客人资料控件

( GuestlnfoCtrl )。

参见图 5B , 仍以客人页为例， PageCtrl所加载的各种控件可以由图 5B 中示出的各种类来实现： 类 CFaultltemCtrl 对应于断层控件； 类 CGuestlnfoCtrl对应于客人页的客人资料控件；类 CLoadingltemCtrl对应 于加载中控件； 类 CMoreltemCtrl对应于更多控件； 类 CMsgltemCtrl对 应于客人页消息控件。 为了获取各控件的排序和布局信息， 在实现客人 页的时候可以从各种控件 ItemCtrl上抽象出共同的接口， 即消息页控件 公共接口 （ IPageltemCtrl )。 IPageltemCtrl提供方法， 供 PageCtrl获取各 个 ItemCtrl的时间值和大小。 根据本发明的另一实施例， 排序布局单元 433 进一步用于通过 IPageltemCtrl获取至少一个 MsgltemCtrl、 至少一个 LoadingltemCtrl, 至 少一个 FaultltemCtrl和 /或 MoreltemCtrl的时间值和尺寸，并且分别才艮据 所获取的时间值和尺寸对这些控件进行排序和 布局。

消息页其它控件模块 440, 用于将客人页的其他逻辑（即客人资料 相关逻辑）封装在 GuestlnfoCtrl 中， 并且将该 GuestlnfoCtrl 插入到 MsgltemCtrl 中。 消息页控件模块 430 根据客人资料相关逻辑将 GuestlnfoCtrl 加载到客人页上。 排序布局单元 433 进一步用于通过 IPageltemCtrl获取获取至少一个 MsgltemCtrl、至少一个 LoadingltemCtrl、 至少一个 FaultltemCtrl、 MoreltemCtrl和 /或 GuestlnfoCtrl的时间值和尺 寸， 并且分别根据所获取的时间值和尺寸对这些控 件进行排序和布局。

GuestlnfoCtrl 可以具有最大的时间值， MoreltemCtrl 可以具有最小 的时间值， 并且至少一个 MsgltemCtrl所展示的消息发表的时间越晚， 至少一个 MsgltemCtrl的时间值越大。 至少一个 LoadingltemCtrl和至少 一个 FaultltemCtrl的时间值根据与它们相邻的控件的� �间值来确定， 例 如将 LoadingltemCtrl的时间值设置为它上方的 MsgltemCtrl的时间值减 1。 由于 GuestlnfoCtrl具有最大的时间值， 因此客人资料控件总是首先 排列在客人页的顶部， 相反， MoreltemCtrl则排列在客人页的底部。

参见图 6A, 示出了微博消息页基础控件 （ MsgPageCtrlBase ) 的对 象结构图。 为了方便各种消息页的扩展， 消息页基础控件模块 410将各 种消息页的公用逻辑封装于 MsgPageCtrlBase中。 这样， 不同应用场景 下的消息页只需要继承 MsgPageCtrlBase即可复用这些公用逻辑。

参见图 6B ,示出了多种消息页的消息页控件与消息页基� �控件的继 承关系。 消息页控件模块 430可以使消息页控件继承公用逻辑。 通过继 承， 使得该消息页控件具备了 MsgPageCtrlBase所具备的全部功能。 另 外， 从各种消息页抽象出来的消息页公共接口 （ IMsgPageCtrl )可用于 对各种消息页进行调用。 参见图 6C, 从图 6C示出的类图应该可以清楚 地看出， PageCtrl可以作为 ItemCtrl的容器。

管理单元 434 用于分别将相应的管理逻辑封装在相应的管理 控件 中， 其中消息页控件分别通过相应的管理控件管理 至少一个 MsgltemCtrl、 至少一个 LoadingltemCtrl和 /或至少一个 FaultltemCtrl。

参见图 6C, 类 CMoreltemCtrl对应于更多控件， 当一个消息页只有 一个这种控件时， 操作逻辑比较筒单， 所以相关的调用代码可以直接放 在 CMsgPageBase里。 CFaultltemCtrl对应于断层控件， 在逻辑设计上， 消息页可能出现多个断层的情况，所以封装了 FaultlemCtrlMgr对其进行 管理。 CLoadingltemCtrl对应于 Loading控件， 目前会出现在消息页的 Loading控件有三种： （1 )登录后第一次主动拉取新消息时置顶显示的 Loading控件； （ 2 )往下拉滚动条触发拉取旧消息时置底显示的 Loading 控件； （3 )点击断层之后， 断层消息拉取完毕之前显示的 Loading控件； 几种控件有可能同时出现， 相对来说逻辑操作会稍显复杂， 所以在 CLoadingltemCtrl 和 CMsgPageBase 之 间 封 装 了 一 个 CLoadingltemCtrlMgr 用 来处理 Loading 控件的逻辑， 筒化 CMsgPageCtrlBase对 Loading控件的调用。 CMsgltemCtrl对应于 博消 息控件， 逻辑操作更为复杂， 所以也就有了 CMsgltemCtrlMgr的存在。 CMsgltemCtrlMgr的主要作用是， 当一批消息数据拉取回来之后， 逐条 解析数据的内容,创建出对应的消息控件，即� �建出一个新 CMsgltemCtrl 对象， 插入到页面中。 另外， 当收到服务器通知某条消息已被删除时， 通过 CMsgltemCtrlMgr可以定位到该消息对应的那个 CMsgltemCtrl对 象， 然后将它从界面上移除。

根据本发明的另一实施例， 上述尺寸可以指宽度， 其他控件、 至少 一个消息控件、 至少一个加载中控件、 至少一个断层控件和 /或更多控件 的宽度相等， 并且排序布局单元 433使得消息页控件根据时间值的大小 顺序在消息页上从上到下排列 GuestInfoCtrl、 至少一个 MsgItemCtrl、 至 少一个 LoadingltemCtr, 至少一个 FaultltemCtrl和 /或 MoreltemCtrL 当 然， 本发明并不限于此。

参见图 7 , 示出了客人页的设计实例。 在图 7 中， 客人资料接口 ( IGuestlnfoCtrl )继承于 IPageltemCtrl, 以满足客人页对客人资料控件 的排序和布局调用。 客人页内展示的是某一用户发表的微博消息， 而 CGuestlnfoCtrl 则用来展示这个用户相关的一些资料信息 （如性别， 籍 贯， 听众数， 广播数等）。 CGuestlnfoCtrl是一个客人页特有的控件， 需 要和其它页面内控件一起参与排序。另夕卜， 客人资料涉及的字段比较多， 读取， 触发更新， 响应更新的逻辑也比较繁杂， 这些逻辑的实现目前都 封装在类 CGuestlnfoData里面， 而 CGuestlnfoData对这些资料信息的进 行了整合封装。

运用本发明提出的这种有效提高消息页可扩展 的技术方案， 可以非 常方便地增加一类消息页， 同时这类消息页统一管理类来进行管理， 极 大的提高了代码架构的可扩展性与可维护性， 同时，对于开发过程来说， 极大提高了开发效率。 另外， 由于仅仅根据时间值对消息页上的各种控 件进行排序， 使得排序算法更加筒单、 高效。

以上所述仅为本发明的较佳实施例而已， 并不用以限制本发明， 凡 在本发明的精神和原则之内， 所做的任何修改、 等同替换、 改进等， 均 应包含在本发明保护的范围之内。