CN114461320A - Ui界面的控制方法及控制系统以及ui软件开发工具包 - Google Patents

Abstract

公开一种UI界面的控制方法及系统。该UI界面的控制方法包括：接收通知；将通知转发给多个UI组件；其中，多个UI组件处于监听状态，并在接收到通知时执行对应操作。本公开实施例将监听和处理逻辑都收归到UI组件，由UI组件根据监听到的通知采取合适的处理逻辑的做法，更有利于组件扩展并且更适用于用户根据自身需求设计个性化的UI界面，尤其适合那些自身就有大量的UI定制需求的客户。

Description

UI界面的控制方法及控制系统以及UI软件开发工具包

技术领域

本公开涉及前端UI设计领域，具体而言，涉及一种UI界面的控制方法及控制系统以及UI软件开发工具包。

背景技术

现今，基于众多企业都有UI(User Interface)界面的设计需求，因此有软件商研发并提供UI软件开发工具包(SDK，Software Development Kit)并提供给有需求的企业。UI工具包封装了各种形态的视觉元素以及视觉元素背后的处理逻辑。研发人员可在自家应用产品中加载并调用相应功能单元以实现UI界面。这种方式能够极大程度降低UI界面的开发成本并提高开发效率。

为了应对不同企业的UI界面的设计需求，UI工具包通常采用的策略是，尽可能在工具包内穷举可能会被拓展的各种视觉元素以及实现各种视觉元素所需的功能模块，以支持企业内部的开发人员进行选择性的使用。例如，针对直播界面的标题区域，A企业希望将标题区域设置在界面的左上角，B企业希望将标题区域设置在右上角，A公司对于字体、颜色有A要求，B公司对字体、颜色有B要求，对此，UI工具包集成所有实现这些可能的代码文件。

但这种策略的缺点在于，企业的UI设计需求千差万别，在UI工具包设计开发阶段，研发人员很难逐一穷举出来，并且无论如何也做不到。因此有必要重新设计和规划工具包。

发明内容

有鉴于此，本公开的目的是提供一种UI界面的控制方法及控制系统以及UI软件开发工具包，以解决现有问题。

根据本公开的第一方面，提供一种UI界面的控制方法，包括：

接收通知；

将所述通知转发给多个UI组件；

其中，所述多个UI组件处于监听状态，并在接收到所述通知时执行对应操作。

在一些实施例中，所述通知为UI界面发生指定状态变化或执行了指定操作的通知，所述对应操作为从服务器端获取数据和/或基于获取到的数据进行组件渲染和展示。

在一些实施例中，所述界面布局文件还用于限定所述多个UI组件在UI界面上的相对位置关系。

在一些实施例中，所述多个UI组件中的第一UI组件在自身状态发生变化和/或进行特定操作时，向所述多个UI组件中的第二UI组件发送事件，所述第二UI组件在接收到所述事件时，更新自身状态。

在一些实施例中，所述第一UI组件向所述第二UI用户发送用户操作事件，所述第二UI组件基于所述用户操作事件计算数据并重新渲染和展示组件。

在一些实施例中，采用配置信息管理各种通知和各种UI组件之间的对应关系。

根据本公开的第二方面，提供一种UI软件开发工具包，包括：

多个UI组件；

组件管理器，用于管理所述多个UI组件，并在接收到通知时，将所述通知转发给多个UI组件；

其中，所述多个组件处于监听状态，在接收到所述通知时执行对应操作。

在一些实施例中，还包括：事件管理器，用于实现多个UI组件之间发送和接收事件。

在一些实施例中，所述通知为UI界面发生指定状态变化或执行了指定操作的通知，所述对应操作为从服务器端获取数据和/或基于获取到的数据进行组件渲染和展示。

在一些实施例中，所述组件管理器根据可配置的界面布局文件限定所述多个UI组件以及所述多个UI组件在UI界面上的相对位置关系。

根据本公开的第三方面，提供一种UI界面的控制方法，包括：

构建UI界面,并根据可配置的界面布局文件控制多个UI组件在所述UI界面上的相对位置关系；

向所述多个UI组件发送通知，所述多个UI组件处于监听状态，并在监听到通知时执行对应操作。

在一些实施例中，通过Android Activity构建UI界面。

根据本公开的第四方面，提供一种UI界面的控制系统，包括：

上述任一项所述的UI软件开发工具包；

界面控制模块，用于构建UI界面,并向所述组件管理器发送所述通知。

根据本公开的第五方面，提供一种电子设备，包括存储器和处理器，所述存储器还存储有可由所述处理器执行的计算机指令，所述计算机指令被执行时，实现上述任一项所述的UI界面的控制方法。

根据本公开的第六方面，提供一种计算机可读介质，所述计算机可读介质存储有可由电子设备执行的计算机指令，所述计算机指令被执行时，实现上述任一项所述的UI界面的控制方法。

在本公开实施例中，每个UI组件将监听逻辑和数据填充逻辑等相关处理逻辑集成到该UI组件内部，并且UI组件自创建后处于监听状态，当监听到相应通知时自行决定是否采取操作以及采取何种操作。而传统技术方案是UI组件之外的处理逻辑来决定UI的操作。相比较而言，本公开实施例将监听和处理逻辑都收归到UI组件中的做法，更有利于组件扩展并且更适用于用户根据自身需求设计个性化的UI界面，尤其适合那些自身就有大量的UI定制需求的客户。

附图说明

通过参考以下附图对本公开实施例的描述，本公开的上述以及其它目的、特征和优点将更为清楚，在附图中：

图1是用于实施本公开实施例的方法和系统的硬件部署图；

图2为一个示例性的智能手机的结构示意图；

图3是根据本公开实施例提供的UI软件开发工具包的结构示意图；

图4a是本公开一实施例提供的界面控制模块和UI组件之间的交互示意图；

图4b是本公开另一实施例提供的界面控制模块和UI组件之间的交互示意图；

图5是安卓操作系统的Standard模式的Activity栈的结构图；

图6是本公开一实施例提供的两个UI组件之间进行通信的交互示意图。

图7是一个示例性的直播APP的UI界面的示意图。

具体实施方式

以下基于实施例对本公开进行描述，但是本公开并不仅仅限于这些实施例。在下文对本公开的细节描述中，详尽描述了一些特定的细节部分。对本领域技术人员来说没有这些细节部分的描述也可以完全理解本公开。为了避免混淆本公开的实质，公知的方法、过程、流程没有详细叙述。另外附图不一定是按比例绘制的。

在介绍本公开各个实施例之前，先介绍本公开中UI组件的设计理念。

本公开的设计UI组件，每个UI组件对应一个视觉元素，并将监听和数据填充逻辑等相关处理逻辑都集成到该UI组件内部，从而实现UI组件的高内聚并降低组件间的耦合。

本公开实施例的场景

本公开各个实施例提供的方法和系统可应用于如图1所示的由服务器101和终端设备103所构成的硬件环境中。如图1所示，服务器101通过网络102与终端设备103进行通信。终端设备103可安装应用程序，应用程序可以是视频应用程序、社交媒体应用程序、浏览器应用程序、教育应用程序、游戏应用程序等，这些应用程序可通过网络103从服务器101下载数据并呈现在应用程序的图形界面上。可在服务器101上或独立于服务器设置数据库105，用于为服务器101提供数据服务，例如，社交媒体应用程序将聊天记录上传到服务器101并经由服务器101存储到数据库105中，并且合适时机再从数据库105下载聊天记录，例如某个用户采用多个不同终端设备登陆社交媒体应用程序时，需要同步各个终端设备之间的聊天记录。

终端设备103可以包括但不限于以下至少之一：手机、笔记本电脑、平板电脑、掌上电脑、MID(Mobile Internet Devices，移动互联网设备)、PAD、台式电脑、智能语音交互设备、智能家电、车载终端等计算机设备，服务器101可以是单一服务器，也可以是由多个服务器组成的服务器集群，或者是云服务器。网络102可以包括但不限于：有线网络，无线网络，其中，该有线网络包括：局域网、城域网和广域网，该无线网络包括：蓝牙、WIFI及其他实现无线通信的网络。

特别地，图1示出了在终端设备103上运行的应用程序的UI界面1031，该UI界面1031呈现有视觉元素1至n。根据本公开的设计理念，视觉元素1至n中的每个视觉元素，包括数据填充、数据更新等处理逻辑都被集成在与该视觉元素对应的UI组件中。由此，当研发人员希望修改UI界面的某个视觉元素时，可通过修改对应的UI组件实现。传统做法是将所有视觉元素的处理逻辑都组织在一起，融合在一起，这种情况下，修改某个视觉元素的处理逻辑时，必须同时兼顾其他视觉元素的处理逻辑，以免对其他元素的处理逻辑产生破坏。因此相比较而言，本公开的UI组件实现了UI组件自身的逻辑闭环，更符合代码间的低耦合高内聚原则。

图2为一个示例性的智能手机的结构示意图。智能手机200包括：处理器201、输入单元202、显示单元203、传感器204、音频设备205、短距离通讯模块206、移动通讯模块207、电源208、存储器209。但本领域技术人员可以理解，图4中示出的手机结构并不构成对手机的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。

输入单元202用于接收输入的数字或字符信息，以及产生与手机200的用户设置以及功能控制有关的键信号输入。具体地，输入单元202可包括触摸屏。触摸屏可收集用户在其上或附近的触摸操作(比如用户使用手指、触笔等任何适合的物体或附件在触控屏上或在触控屏附近的操作)，并根据预先设定的程式驱动相应的连接装置，连接装置将触摸操作转换为触点坐标，送给处理器201。除了触摸屏之外，输入单元202还可以包括其他输入设备，例如摄像头,摄像头的位置可以为前置的，也可以为后置的，本申请实施例对此不作限定。此外，其他输入设备还可包括物理键盘、功能键(比如音量控制按键、开关按键等)、轨迹球、鼠标、操作杆等中的一种或多种。

显示单元203可用于显示由用户输入的信息或提供给用户的信息以及各种界面。显示单元可包括显示面板，显示面板可以采用液晶显示器(Liquid Crystal Disp lay，LCD)、有机发光二极管(Organic Light-Emitting Diode,OLED)等形式来配置。进一步地，触控屏可覆盖显示面板，当触控屏检测到在其上或附近的触摸操作后，传送给处理器201以确定触摸事件的类型，随后处理器201根据触摸事件的类型在显示面板上提供相应的视觉输出，因此虽然在图中，显示单元和输入单元作为两个独立的部件示出，但是实际上手机的输入输出功能是可以集成为一个部件的。手机200还可包括至少一种传感器204，比如光传感器、运动传感器以及其他传感器，在此不再赘述。

音频设备205用于收集音频数据并存储到存储器109中以制作媒体视频流，以及播放视频流中的声音信息。

短距离通讯模块206例如为WiFi模块、蓝牙模块等。WiFi模块用于无线的宽带互联网访问。蓝牙模块用于在不同机器之间通过蓝牙协议进行信号收发。

移动通讯模块207用于基于移动通讯协议进行信号接收和发送，特别地，将基站的下行信号接收后提供给处理器201处理，另外，将上行数据发送给基站。移动通讯模块207包括但不限于天线、至少一个放大器、收发信机、耦合器、双工器等。移动通讯模块207还可使用任一通信标准或协议与其他设备进行通信，包括但不限于全球移动通讯系统(GSM)、通用分组无线服务(GPRS)、码分多址(CDMA)、宽带码分多址(WCDMA)、长期演进(LTE))、电子邮件、短消息服务(Short Messaging Service，SMS)等。

电源208用于向系统供电。优选的，电源可以通过电源管理系统与处理器201逻辑相连，从而通过电源管理系统实现管理充电、放电、以及功耗管理等功能。

存储器209存储上文提及的各种应用程序、操作系统程序和各种数据。处理器201是手机200的控制中心，利用各种接口和线路连接整个手机的各个部分，通过运行或执行存储在存储器209内的各种程序，以及调用存储在存储器209内的数据，执行手机的各种功能和处理数据。特别地，存储器209存储的应用程序还包括基于本公开的设计理念构建的UI组件和使用该UI组件的应用程序。应用程序可以通过形成如图1所示的UI界面。例如直播应用程序，通过调用UI组件产生直播界面。

图3是根据本公开实施例提供的UI软件开发工具包的结构示意图。如图上所示，UI工具包300包括UI组件库2,备用组件库1、界面布局文件3和组件管理器4。UI组件库1包括大量的UI组件，每个UI组件将监听和数据填充逻辑等相关处理逻辑都集成到该UI组件内部，并且UI组件之间能够基于事件进行通信，这些操作都有助于UI组件的高内聚以及降低UI组件之间的耦合度。

备用组件库1包括多个空壳组件，每个空壳组件都规定如输入输出等基本规范，研发人员可基于规范进行自定义的代码填充。界面布局文件3作为提供给研发人员的配置接口，研发人员可根据在UI界面上要展示的各种视觉元素选择多个组件并将选中的多个组件填写到界面布局文件3中，并在界面布局文件3中限定选中的多个组件之间的相对位置关系。界面布局文件可采用XML格式或JASON格式。

组件管理器4用于管理UI组件库2中的多个UI组件，并将接收到的各种通知转发给界面布局文件3中选定的多个组件以及将从界面布局文件3中选定的多个组件接收到的反馈转发出去。研发人员可将完成编码的UI组件注册到组件管理器4，组件管理器4在接收到组件注册请求后，在数据库增加一条组件信息并持续维护组件信息。各种通知可以来自是UI界面6，例如UI界面感知到界面状态变化并向UI组件发送关于界面状态变化的通知，也可以来自构建UI界面并使用UI软件开发工具包300的外部系统，例如控制系统负责控制界面状态变化，然后将关于界面状态变化的通知发送给UI组件。可选地，组件管理器采用配置信息管理通知和UI组件之间的对应关系，并根据配置信息决定将每个通知发送给从界面布局文件3中选定的多个组件中的一个或几个。

在一些实施例中，为了达到集中并统一管理各个UI组件之间的事件收发功能的目的，UI软件开发工具包300还包括：事件管理器5，事件管理器5用于实现多个UI组件之间发送和接收事件，通过将UI组件之间的事件收发功能都集成中独立代码文件：事件管理器5中，从而简化代码文件。但应理解，也可将事件收发功能分布在各个UI组件中，虽然造成的后果是每个组件中都包含同样的事件收发功能，代码文件变得臃肿，但不影响整体方案的技术效果。

此外，在UI软件开发工具包提供的各种UI组件的基础上，研发人员可对各种UI组件的能力进行拓展和重构，这种做法通常应用于UI个性化需求较深的场景。如此，结合UI组件高内聚低耦合的设计，能够很好地解决开发阶段UI组件无法完全预定义，因此无法满足外部接入时所有的定制诉求的问题。

图4a是本公开一实施例提供的界面控制模块和UI组件之间的交互示意图。界面控制模块是UI界面的控制程序，负责UI界面的构建、启动、暂停、销毁等状态变化。UI组件根据本公开的设计理念设计，用于承担视觉元素的数据加载、数据渲染等处理逻辑。

如图上所示，界面控制模块在步骤S301中根据界面布局文件创建UI组件的实例，在步骤S302中界面控制模块执行某个操作使得界面状态发生变化或执行某个处理逻辑，在步骤S303中，经由组件管理器将通知发送给UI组件S303。

UI组件的实例在步骤S401中从创建之时就处于监听状态，在步骤S402中接收到通知，在步骤S403中，判断是否为第一通知，如果是，则执行步骤S404的执行设定操作。

图4b是本公开另一实施例提供的界面控制模块和UI组件之间的交互示意图。

与图4a所示的实施例的不同之处在于，本实施例在确定接收到的通知为第一通知时，执行步骤S405的从服务器端获取数据，然后执行步骤S406的渲染组件以显示UI组件。

虽然未示出，但是作为一种可选的实施方式，在步骤S405和S406之间还可以设置一个判断步骤，该判断步骤用于判断当前接收到的通知是否为第二通知。即，UI组件的实例在确定当前接收到的通知为第一通知时，执行步骤S405的从服务器端获取数据,在确定当前接收到的通知为第二通知时，执行步骤S406的渲染组件以显示UI组件。根据上文，第一通知和第二通知表示界面控制模块执行了两个不同操作使界面发生了不同变化，或者表示执行界面控制模块执行了两个不同的处理逻辑。

虽然未示出，但是作为一种可选的实施方式，在上述实施例之后还可以增加一个消息反馈步骤，该步骤由UI组件发起，将根据通知执行的操作结果反馈经由组件管理器反馈给界面控制模块。

在以上两个实施例中，界面布局文件规定了UI界面上的多个UI组件以及所述多个组件之间的相对位置关系。而界面控制模块则构建UI界面并创建多个UI组件的实例。此外，多个UI组件的显示与否由其自身决定，通常当界面控制模块创建完成多个UI组件的实例后，多个组件不会即时显示在UI界面上，而是在接收到特定通知才开始渲染组件并显示。

界面控制模块向UI组件发送的各种通知不仅指示UI界面的各种状态变化，而且能够指示界面控制模块已经进行或者即将进行的各种处理逻辑。对于某个通知，UI组件自行决定是否采取操作以及采取何种操作，因而，多个UI组件同时收到同一通知，可能只有其中之一的UI组件采取某个操作，其他UI组件均忽略该通知，或者，多个UI组件同时收到同一通知时，A组件采取A操作，B组件采取B操作，其他UI组件均则忽略该通知。

更具体地，UI组件可采取的操作包括数据加载和显示。数据加载是从服务器端获取数据，显示是采用数据渲染组件并在UI界面上展示组件。举例说明。直播APP的直播界面上显示有点赞汇总组件，用于显示点赞统计值。点赞统计值来自于服务器端的数据统计。直播界面显示在用户终端的显示屏之前，系统会进行一系列的操作，例如创建直播实例、初始化直播实例、加载界面布局文件等等，这些都会导致UI界面控制模块向各个UI组件发送通知。某个UI组件可选择在收到初始化直播实例的通知时获取数据，然后在接收到加载界面布局文件的通知时渲染组件以呈现组件，某个UI组件还可选择在收到初始化直播实例的通知时获取数据和渲染组件以呈现组件。

应该理解，UI组件从界面控制模块监听到各种通知并采用相应操作，这即是上文所述的“每个UI组件将监听逻辑和数据填充逻辑等相关处理逻辑集成到该UI组件内”的设计理念。尤其是，UI组件的数据加载和显示时机均由UI组件自身决定。而传统技术方案是界面控制模块根据UI界面的状态变化确定何时为UI组件加载数据和显示UI组件。相比较而言，本公开实施例更有利于组件扩展并且更适用于用户根据自身需求设计个性化的UI界面，尤其适合那些自身就有大量的UI定制需求的客户。

以上两个实施例可在智能手机上实现。因此下面以安卓操作系统为例介绍以上实施例如何实施。

安卓操作系统提供了Activity。一般而言，一个Activity对应一个单独的UI界面。安卓操作系统通过Activity栈对Activity进行管理。如图5所示，Standard模式下，按照创建顺序，第三次创建的Activity位于Activity栈的栈顶，相应地，终端的显示屏显示的是第三次创建的Activity对应的UI界面，而当顶端的Activity因为异常或其他原因被销毁时，处于栈第二层的Activity将被激活，上浮到栈顶；当新的Activity入栈时，原来栈顶的Activity会被压入到栈的第二层。

Activity包含多个方法。例如onCreate()完成初始化操作,onStart是将界面由不可见变为可见，onResume是暂停状态恢复为运行状态，onPause()是界面转为暂停状态，等等。Activity在调用这些方法时实现了UI界面的状态变化。Activity还有其他方法，通过调用其他方法进行其他逻辑处理。为了UI组件能够感知到UI界面发生的变化以及Activity进行的其他逻辑处理，Activity在执行这些方法时相应地向UI组件发送通知。但前提是，UI组件的实例此时已创建并具有监听能力，因此可选地，Activity在调用onCreate()方法时读取界面布局文件以确定归属于UI界面的多个UI组件，然后构建这些UI组件的实例并将这些UI组件关联到Activity对应的UI界面。

UI组件继承View类。View类是安卓操作系统提供的UI界面上各种视觉元素实现的基础类。研发人员通过在UI组件内重写View类，以便使UI组件具有监听能力并可根据监听到的各种通知执行各种预定操作。继续以直播APP为例进行说明。直播界面显示之前，Activity调用了onCreate和onStart方法，在onCreate方法中创建了直播界面中的点赞汇总组件的实例，并且点赞汇总组件的实例在接收到关于Activity调用onCreate方法的通知之后，从服务器端获取点赞汇总组件所需的点赞统计值，在接收到关于Activity调用onStart方法的通知之后，基于点赞统计值对点赞汇总组件进行渲染，并在UI界面绘制出点赞汇总组件。

图6是本公开一实施例提供的两个UI组件之间进行通信的交互示意图。

UI组件1的实例和UI组件2的实例都可在创建之后就处于事件监听状态(即步骤S501和S502)。

在步骤S502中，UI组件1的实例通过响应用户操作，接收到用户输入的数据。

在步骤S503中，UI组件1的实例发送事件以告知在步骤S502中的用户输入事件。

在步骤S602中，UI组件2的实例接收事件。

在步骤S603中，UI组件2的实例判断当前事件是否为第一事件，如果是，则执行步骤S603，即更新UI组件2的实例中的数据。

在步骤S604中，UI组件2的实例重新渲染并显示UI组件。

根据本实施例，UI组件通过接收其他UI组件发送的事件从而告知其他UI组件发生的变化，并可根据其他组件发生的变化进行自身的逻辑处理。仍旧以直播APP为例。直播界面上显示有点赞组件和点赞汇总组件，当用户通过点赞组件进行点赞操作时，点赞组件将向点赞汇总组件发送一个事件以告知又有一个用户进行了点赞操作，点赞汇总组件接收到该事件之后，更新点赞统计值，并在适当的时候更新显示在点赞汇总组件的点赞统计值。

根据本实施例，一个UI组件能够感知到另一个UI组件的状态变化并采取相应的处理逻辑。这种方式同样更有利于组件扩展并且更适用于用户根据自身需求设计个性化的UI界面。例如，新增一个UI组件时，其他组件不需要单独为该组件改变处理逻辑，只要正常发送事件通知即可，新增的UI组件针对接收到的事件自行决定该采用何种处理逻辑且不会影响到其他组件。

图7是一个示例性的直播APP的应用界面的示意图。参考图上所示，600为应用界面，601为用于显示当前进入直播间的用户名称的组件，602用于接收用户点击的组件。601的组件获取进入直播间的用户名称并显示在应用界面上。通常情况下，UI界面发送各种通知，分别告知直播界面将初始化、将启动、将呈现等状态变化，601的组件根据某个通知获取进入直播间的用户名称，并在UI界面呈现之后呈现用户名称。诸如此类。

本领域的技术人员能够理解，本公开可以实现为系统、方法和计算机程序产品。因此，本公开可以具体实现为以下形式，即完全的硬件、完全的软件(包括固件、驻留软件、微代码)，还可以实现为软件和硬件结合的形式。此外，在一些实施例中，本公开还可以实现为一个或多个计算机可读介质中的计算机程序产品的形式，该计算机可读介质中包含计算机可读的程序代码。

可以采用一个或多个计算机可读介质的任意组合。计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质。计算机可读存储介质例如但不限于为电、磁、光、电磁、红外线或半导体的系统、装置或器件，或其他任意以上的组合。计算机可读存储介质的更具体的例子包括：具体一个或多个导线的电连接，便携式计算机磁盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦除可编程只读存储器(EPROM或者闪存)、光纤、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器、磁存储器或者上述任意合适的组合。在本文中，计算机可读的存储介质可以是任意包含或存储程序的有形介质，该程序可以被处理单元、装置或者器件使用，或者与其结合使用。

计算机可读信号介质可以包括在基带中或者作为截波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或者其他任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质之外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令系统、装置或器件使用或者与其结合使用的程序。

计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于无线、电线、光缆、RF等等，以及上述任意合适的组合。

可以以一种或者多种程序设计语言或者组合来编写用于执行本公开实施例的计算机程序代码。所述程序设计语言包括面向对象的程序设计语言，例如JAVA、C++，还可以包括常规的过程式程序设计语言，例如C。程序代码可以完全地在用户计算机上执行、部分地在用户计算机上执行、作为一个独立的软件包执行、部分在用户计算机上部分在远程计算机上执行、或者完全在远程计算机或服务器上执行。在涉及远程计算机的情形中，远程计算机可以通过任意种类的网络包括局域网(LAN)或广域网(WAN)连接到用户计算机，或者，可以连接到外部计算机(例如利用因特网服务提供商来通过因特网连接)。

以上所述仅为本公开的优选实施例，并不用于限制本公开，对于本领域技术人员而言，本公开可以有各种改动和变化。凡在本公开的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本公开的保护范围之内。

Claims (13)

1.一种UI界面的控制方法，包括：

接收通知；

将所述通知转发给多个UI组件；

其中，所述多个UI组件处于监听状态，并在接收到所述通知时执行对应操作。

2.根据权利要求1所述的控制方法，其中，所述通知为UI界面发生指定状态变化或执行了指定操作，所述对应操作为从服务器端获取数据和/或基于获取到的数据进行组件渲染和展示。

3.根据权利要求1所述的控制方法，还包括：采用可配置的界面布局文件限定所述多个UI组件以及所述多个UI组件在UI界面上的相对位置关系。

4.根据权利要求1所述的控制方法，其中，所述多个UI组件中的第一UI组件在自身状态发生变化和/或进行特定操作时，向所述多个UI组件中的第二UI组件发送事件，所述第二UI组件在接收到所述事件时，更新自身状态。

5.根据权利要求4所述的控制方法，其中，所述第一UI组件向所述第二UI用户发送用户操作事件，所述第二UI组件基于所述用户操作事件计算数据并重新渲染和展示组件。

6.根据权利要求1所述的控制方法，其中，采用配置信息管理各种通知和各种UI组件之间的对应关系。

7.一种UI软件开发工具包，包括：

多个UI组件；

组件管理器，用于管理所述多个UI组件，并在接收到通知时，将所述通知转发给所述多个UI组件；

其中，所述多个组件处于监听状态，在接收到所述通知时执行对应操作。

8.根据权利要求7所述的UI软件开发工具包，还包括：事件管理器，用于实现所述多个UI组件之间发送和接收事件。

9.根据权利要求7所述的UI软件开发工具包，其中，所述通知为UI界面发生指定状态变化或执行了指定操作的通知，所述对应操作为从服务器端获取数据和/或基于获取到的数据进行组件渲染和展示。

10.根据权利要求7所述的UI软件开发工具包，其中，所述组件管理器根据可配置的界面布局文件限定所述多个UI组件以及所述多个UI组件在UI界面上的相对位置关系。

11.一种UI界面的控制方法，包括：

构建UI界面,并根据可配置的界面布局文件控制多个UI组件在所述UI界面上的相对位置关系；

向所述多个UI组件发送通知，所述多个UI组件处于监听状态，并在监听到通知时执行对应操作。

12.根据权利要求11所述的控制方法，通过Android Activity构建UI界面。

13.一种UI界面的控制系统，包括：

根据权利要求7至10任一项所述的UI软件开发工具包；

界面控制模块，用于构建UI界面,并向所述组件管理器发送所述通知。

Images