一种界面激活方法和装置与流程

本申请涉及界面构建技术，具体涉及一种界面激活方法和装置。

背景技术：

在一些具有复杂的多个界面交互的软件系统中，为完成某一项功能，通常需要用户完成对多个界面按顺序执行的一系列界面操作，以触发系统激活一系列的任务界面，这种按顺序执行的一系列界面操作被称为“任务流”。

例如，用户想要购买某一件商品，用户点击“购物”按钮，系统激活(即，触发显示)购物首页界面，用户在首页界面上点击“分类”，并选择所需商品所在的分类，系统激活相应分类的界面，然后在分类界面上点击相应的品牌或店铺，系统激活品牌或店铺的首页界面，用户在该界面上点击进入相应商品的商品信息显示界面，并确认购买；商品选择完毕后，系统激活结算界面，用户点击确认后，系统激活支付界面；用户通过支付界面成功支付后，系统激活成功购买界面；如果支付失败，则系统激活支付失败界面。因此，购物首页界面、相应分类的界面、品牌或店铺的首页界面、商品信息显示界面、结算界面、支付界面、成功购买界面/支付失败界面就形成界面任务流。

为了使该界面任务流能够按照预定的顺序执行，现有技术中通常把每个任务流的逻辑代码都写在各任务界面的配置文件中，即，在各界面的配置文件中分别写入该界面在各任务流中的上一界面和下一界面的信息、以及各界面在各任务流中的输入数据、输出数据及数据流向信息等。具体地，可以将界面在各任务流中的上一界面和下一界面的信息称为该界面的“操作流逻辑”，以及可以将各界面在各任务流中的输入数据、输出数据及数据流向信息称为该界面的 “数据流逻辑”。

以上述购物任务流中的支付界面为例，该界面的操作流逻辑包括：在用户购买商品这一任务流中，支付界面的上一界面为结算界面，下一界面为成功购买界面/支付失败界面。

以上述购物任务流中的结算界面为例，该界面的数据流处理逻辑包括：从各商品信息显示界面获取各商品信息，包括各商品的缩略图、商品名称、商品金额、店家名称等；计算总金额；然后将总金额发送给支付界面。

因此，现有技术中的界面激活方法如下：激活界面；根据该界面中的逻辑代码确定该界面在该任务流中的操作流逻辑和数据流处理逻辑；接收用户的操作，并根据用户操作和操作流逻辑激活另一界面；根据数据流处理逻辑确定数据流向，并发送至相应的模块。

由于软件系统中的交互界面非常多，一些界面可能出现在多个界面任务流中。例如，a界面出现在a，b，c三个任务流中，按照现有技术中的方案，a界面中将同时存在a，b，c三个任务流的业务代码，使得a界面的逻辑变得复杂，不便于维护。

采用现有技术中的界面激活方法，界面逻辑复杂，不便于维护。

技术实现要素：

本申请实施例中提供了一种界面激活方法和装置，用于解决现有技术中的界面激活方法导致的界面逻辑复杂，不便于维护的问题。

根据本申请实施例的一个方面，提供了一种界面激活方法，包括：根据预先创建的配置文件激活第一界面；在该配置文件中查询该第一界面的配置信息，该配置文件包括多个界面的配置信息，该配置信息包括各界面的上一界面和下一界面的信息；根据该第一界面返回的用户操作和该第一界面的配置信息，激活第二界面，其中，该第二界面包括该第一界面的上一界面或下一界面。

根据本申请实施例的另一个方面，提供了一种界面激活装置，包括：第一 激活模块，用于根据预先创建的配置文件激活第一界面；查询模块，用于在该配置文件中查询该第一界面的配置信息，该配置文件包括多个界面的配置信息，该配置信息包括各界面的上一界面和下一界面的信息；第二激活模块，用于根据该第一界面返回的用户操作和该第一界面的配置信息，激活第二界面，其中，该第二界面包括该第一界面的上一界面或下一界面。

采用本申请实施例中的界面激活方法，能够将配置文件与界面隔离，在进行界面跳转时，可以在配置文件中查询当前第一界面的配置信息，并根据用户的操作和该配置信息来激活另一界面，从而使得任务界面只需要负责数据的呈现和与用户的交互，便于维护。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1是根据本申请实施例的界面激活方法中的任务流引擎启动时的流程图；

图2为本申请实施例一所示的界面激活方法的流程图；

图3是实施根据本申请实施例一的界面激活方法时，任务流引擎、taskflow、taskview之间的交互流程图；

图4为本申请实施例二所示界面激活装置的结构示意图。

具体实施方式

在实现本申请的过程中，申请人发现，采用现有技术中的界面激活方法，界面逻辑复杂，不便于维护。

另外，还可能出现以下情况：例如由于未来需求变化，a界面可能出现在b，c，d，e任务流中，此时则必须重新维护a界面的业务逻辑，长此下去，当a界面加入新的任务流时，a界面中就会包含越来越多的逻辑代码，同时，各个 任务流的逻辑代码，也会分散在各种界面中，维护起来很不方便。

针对问上述题，本申请实施例中提供了一种界面激活方法，能够将配置文件与任务界面隔离，在进行界面跳转时，可以在配置文件中查询当前第一界面的配置信息，并根据用户的操作和该配置信息来激活另一界面，从而使得任务界面只需要负责数据的呈现和与用户的交互，便于维护。

本申请实施例中的方案可以应用如超文本标记语言html、js(javascript)、css(cascadingstylesheet，层叠样式表)、面向对象的编程语言c#、.net、面向对象程序设计语言java、通用编程语言c++等多种编程语言实现。

本申请实施例中的方案可以应用于构建如qq、微信等多界面应用软件系统、以及操作系统等多界面的软件系统。

为了使本申请实施例中的技术方案及优点更加清楚明白，以下结合附图对本申请的示例性实施例进行进一步详细的说明，显然，所描述的实施例仅是本申请的一部分实施例，而不是所有实施例的穷举。需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。

实施例一

在本申请实施例一中，将对根据本申请实施例的创建配置文件并启动任务流的全过程进行描述。

如图1所示，根据本申请实施例创建配置文件并启动任务流的过程包括以下步骤：

s101，使用者通过任务流引擎，创建配置文件。

具体实施时，在实施本申请中的的界面激活方法之前，可以通过任务流引擎，又称为任务流管理模块预先创建任务流的配置文件，该配置文件由使用者配置，配置之后的内容将形成配置文件；该配置文件中包括该任务流中的多个界面的配置信息，该配置信息包括各界面名称、以及各界面的上一界面和下一界面的信息。具体地，该用户可以是系统的管理人员，例如，可以是支付宝平 台的管理人员、微信平台的管理人员等。

在具体实施时，用户还可以通过任务流引擎，创建多个不同的配置文件，该多个不同的配置文件可以是具有不同权限的，也可以是针对不同用户的，本申请对此不作限制。

在具体实施时，在创建配置文件之后，用户还可以通过该任务流引擎对任务流的配置文件进行管理，如创建、启动、禁用、停止等。同时，还可以定义相应的软件使用用户，并为不同的用户适配不同权限的配置文件。具体地，该软件使用用户可以用角色来标识。

任务流引擎包含的功能可以如下：

launch：启动引擎。启动时，将读取预先设置的配置文件，同时创建对应的界面任务流，及与角色的对应关系。

taskflowstore：界面任务流容器。该容器执行对任务流的管理，如：取得指定名称的任务流，启动/结束任务流，启用/禁用任务流等。

stop：停止引擎。停止引擎，将销毁容器中所有的任务流。

在具体实施时，任务流引擎可以多个功能模块，该多个功能模块可以包括：引擎基本信息设置模块、角色配置模块、任务流配置模块、任务界面配置模块等。各配置模块功能可以如下：

基本信息模块：用于配置包括引擎名称；软件系统的context上下文对象；发生错误时的处理函数等的基本信息。

对于某些软件系统(例如网页、qq、微信等)来说，在其存在的操作系统中可能存在多个任务流引擎；但对于某些软件系统(例如操作系统)来说，可能就存在一个任务流引擎。无论是哪一种情况，均可以采用引擎名称来唯一标识任务流引擎。软件系统的context上下文对象可以用于定义任务流引擎的作用域，也就是与该任务流引擎相关的系统或界面的范围；例如，购物任务流的作用域包括购物应用、支付应用、安全应用等。发生错误时的处理函数用于定义在引擎发生异常时，如系统发生逻辑错误时的处理函数。

角色配置模块：用于配置角色的名称；从软件系统中获取当前的角色的函数。

角色的名称是指某一任务流的使用者在软件系统中的角色，不同角色对应的任务流的权限可能不同，例如，任务流的管理员可以创建任务流；一般的使用者不可以创建任务流；不同角色对应的任务流可能也不相同，例如，一般员工可执行的任务流与系统管理员可执行的任务流可能不同。

在具体实施时，可以先通过例如get_currentuserinfo()的函数获取当前角色的用户信息，并从用户信息中提取用户名，然后根据该用户名确定用户角色。

任务界面配置模块：用于配置任务界面的名称；取得该任务界面实例的软件包路径。

在具体实施时，在一个软件系统中，任务界面的名称通常也用于唯一的标识该任务界面，通过该任务界面配置模块，配置各任务流中包含的任务界面；以及获取该任务界面实例的软件包路径，从而保证界面的成功激活。

任务流配置模块：用于配置任务流的信息，包括：任务流的名称；包含的任务界面的名称的集合；该任务流对应的角色名称集合；是否在引擎启动时，创建该任务流实例。

通过任务流配置模块，可以建立任务流与任务界面之间的关系、角色与任务流之间的关系；以及定义任务流创建的时机。

在具体实施时，任务流引擎可以预先对任务流的配置文件进行抽象和封装，命名为taskflow。具体地，可以将实现某一项功能的、具有一定顺序的一系列界面中的各任务界面的名称、各任务界面在不同用户操作时的上一界面、下一界面的信息、以及各任务界面的输出数据、输入数据、以及数据流向信息写入配置文件中，并将该配置文件标示为与该任务流对应。

taskflow包含的功能可以如下：

create：通过该功能，具有相应权限的用户可以创建一个界面任务流，同时可以向任务流引擎注册该界面任务流所包含的任务界面。在taskflow中创 建一个界面任务流时，可以同时将该任务流所包含的任务界面发送至任务流引擎的任务流配置区，以实现在任务流引擎中的注册。具体地，该相应权限的用户可以是例如第三方应用的管理人员，例如，微信平台中购物功能对应的第三方平台为京东，则该购物任务流的管理人员可以是京东的管理人员。

launch：通过启动功能，可以启动界面任务流。

stop：结束该界面任务流。通过该方法，使用者可以主动的结束该界面任务流。

enable：使该界面任务流可用。

disable：禁用该界面任务流。

activatetastview：激活指定名称的任务界面接口taskview。激活通常包括触发该模块的功能，例如，激活taskview，可以是指使任务界面接口激活对应的任务界面，而激活任务界面可以是指使任务界面显示。

deactivatetaskview：反激活指定名称的taskview。反激活任务界面接口通常包括反向触发该模块的功能，例如，反激活taskview，可以是指使任务界面接口反激活对应的任务界面，而反激活任务界面可以包括隐藏或者销毁该界面。

getactivateview：获取当前激活的taskview。

在具体实施时，任务流引擎还可以建立与各任务界面的接口，该接口用于在任务流和任务界面之间传递信息，该信息包括激活指令、反激活指令、输出数据、输入数据等，并可以将该接口命名为taskview。每一个任务界面对应一个taskview，每个taskview可以具有用于唯一标示该接口对应的界面的名称，例如，界面1对应的taskview的名称为taskview1；界面2对应的taskview的名称为taskview2等。

taskview包含的功能可以为：

activate：激活任务界面，并提供方法供子类复写激活时的特有逻辑；激活时的特有逻辑包括任务界面的自有逻辑，包括数据的输入、输出、编辑等，例 如，在激活某一界面时，该界面中某一子类将根据自有逻辑，从某一路径获取相应的数据展示等。例如，激活的任务界面中包括一子类为广告插件，该广告插件将根据用户在天猫的商品浏览记录推送相关商品。

deactivate：反激活任务界面，通常是隐藏或者销毁该界面，同时提供方法供子类复写反激活时的特有逻辑。反激活时的特有逻辑包括任务界面的自有逻辑，包括数据的输出等，例如，在反激活某一界面时，该界面中某一子类将根据自有逻辑，将当前数据输出至某一特定路径等。例如，反激活的任务界面中包括一子类为商品推荐栏，在反激活该任务界面时，该商品推荐栏将用户对推荐栏中的各商品的关注度输出至特定路径等。

在具体实施时，用户操作可以包括以下一种或多种：完成数据输入、返回上一界面、取消或关闭界面、跳转至下一界面。相应的，taskview返回的用户操作可以包括：

done：表示用户在该界面输入数据完成。

back：表示用户在该界面点击了返回上一界面的操作。

cancel：表示用户在操作时，选择取消了该步骤的操作，或者关闭了界面。

goto：表示用户在操作时，发出跳转至某个界面的操作指令。该操作指令可以是点击某一链接的指令、点击“下一页”的按钮等。

在具体实施时，任务流taskflow与任务界面之间的数据交互均可以通过该taskview来实现，使得任务流与任务界面之间能够更好的实现隔离。

在具体实施时，可以设置taskview在激活时，接收由taskflow发送的相应数据作为被激活界面的输入数据，在反激活界面时，则向任务流发送用户的操作及输出数据。

至此已对配置文件设置完毕。接下来，可以启动该任务流引擎以启动任务流。

s102，启动任务流引擎，并创建任务流。

在具体实施时，可以通过任务流引擎的launch功能启动任务流引擎，并读 取在s101中设置的配置文件，并根据该配置文件创建对应的界面任务流。

具体地，在s101中设置的配置文件可以为对应于不同权限的多个配置文件；也可以为一个配置文件及与角色的对应关系；本申请对此不作限制。

当s101中设置的配置文件可以为对应于不同权限的多个配置文件时，在步骤102中还进一步包括：建立各任务流和不同权限的用户角色之间的对应关系。具体地，可以从配置文件中获取各任务流对应的角色名称，然后将各任务流与其对应的角色一一关联。

s103，建立任务流和任务界面的对应关系。

在创建任务流之后，可以进一步根据步骤101中的配置文件，建议任务流和任务界面的对应关系。具体地，可以从配置文件中获取各任务流所包含的任务界面的名称，然后将各任务流与其所包含的任务界面一一关联。

s104，触发启动任务流。

在具体实施时，可以通过触发任务流taskflow的launch功能，来启动界面任务流。

至此，任务流已经启动完毕。接下来可以执行本申请实施例中的界面激活方法。下面结合实施例二对本申请中的界面激活方法进行描述。

实施例二

图2为本申请实施例二所示的界面激活方法的流程图。

如图2所示，根据本申请实施例二所示的界面激活方法包括以下步骤：

s201，根据预先创建的配置文件激活第一界面；

s202，在配置文件中查询第一界面的配置信息，该配置文件包括多个界面的配置信息，该配置信息包括各界面的上一界面和下一界面的信息；

s203，根据第一界面返回的用户操作和第一界面的配置信息，激活第二界面，其中，该第二界面包括第一界面的上一界面或下一界面。

具体地，上一界面和下一界面信息可以是上一界面和下一界面的名称、编号等在任务引擎作用域内唯一标识该界面的信息。

在具体实施时，根据预先创建的配置文件激活第一界面具体可以包括：根据预先创建的配置文件，通过预先创建的任务界面接口激活该第一界面，该任务界面接口对应该第一界面。具体地，由于每一个任务界面对应一个taskview，因此，可以通过每个任务界面对应的taskview来激活相应的任务界面。

例如，在界面1对应的taskview的名称为taskview1时，任务流通过activatetastview1来激活tastview1，然后tastview1通过activate来激活界面1。

在具体实施时，在根据预先创建的配置文件激活第一界面之后，激活第二界面之前，还可以包括：通过任务界面接口，接收该第一界面发送的用户操作，其中，用户操作包括第一界面接收的用户操作。具体地，该用户操作包括以下一种或多种：完成数据输入、返回上一界面、取消或关闭界面、跳转至下一界面。具体地，根据第一界面返回的用户操作和第一界面的配置信息，激活第二界面具体可以包括：当用户操作包括完成数据输入时，激活第一界面的下一界面；或者当用户操作包括返回上一界面时，激活所述第一界面的上一界面；或者当用户操作包括跳转至下一界面时，激活第一界面的下一界面；或者当用户操作包括取消或关闭界面时，激活第一界面的上一界面。

例如，用户在商品信息显示界面点击“直接购买”以发出跳转至结算界面的指令，此时，商品信息显示界面通过任务界面接口向任务流发送goto结算界面。

在具体实施时，第一界面接收用户操作，并通过任务界面接口发送至该任务流的步骤，与步骤202查询第一界面的配置信息的步骤之间没有严格的时序顺序，可以是先接收用户操作；再查询第一界面的配置信息，也可以先查询第一界面的配置信息，再接收用户操作；还可以是并发执行等；本申请对此不作限制。

在具体实施时，在激活第二界面之前，还可以包括：反激活该第一界面。

如前所述，反激活该第一界面可以是隐藏第一界面，或者销毁第一界面。

在具体实施时，反激活该第一界面的步骤，与步骤202查询第一界面的配 置信息的步骤之间没有严格的时序顺序，可以是先反激活该第一界面；再查询第一界面的配置信息，也可以先查询第一界面的配置信息，再反激活该第一界面；还可以是并发执行等；本申请对此不作限制。

在具体实施时，在反激活该第一界面之后，还可以包括：通过任务界面接口，接收该第一界面的输出数据。具体地，接收到第一界面的输出数据后，可以保存该数据，并作为其他任务界面的输入数据。

例如，用户在商品信息显示界面点击“直接购买”以发出跳转至结算界面的指令，此时，商品信息显示界面的输出数据可以包括商品名称、商品金额、店铺信息等。

在具体实施时，该第一界面的输出数据可以作为第二界面的输入数据，也可以不作为第二界面的输入数据，二者之间没有明显的对应关系。

在具体实施时，在激活第一界面之后，和/或在反激活该第一界面之后，还包括：公布该第一界面的状态信息，该状态信息包括第一界面为激活状态或反激活状态。

在具体实施时，taskflow还可以包含addlistener功能，即，在任务流启动运行后，可以在每一个任务界面激活和/或反激活时，向外公布一个事件接口，以公布该第一界面处于激活状态或反激活状态；以使得引擎使用者(如开发人员)，可在界面任务流创建后和启动前，对任务流中的这些界面状态进行监听，以及时处理业务逻辑。

例如，开发人员创建了一个任务流，包括a、b两个任务界面，其操作流逻辑为，b为a的下一界面；但在启动该任务流之前，另一任务流激活了界面a，使得a中的某些数据有所改变，此时，可能需要将c作为a的下一界面。通过发布该a界面的事件接口，能够使开发人员监听到界面a的激活和反激活状态，从而及时处理业务逻辑。

在具体实施时，在激活第二界面之前，还可以包括：在配置文件中查询该第二界面的输入数据信息；并根据该输入数据信息获取该第二界面的输入数 据。具体地，该输入数据信息可以是输入数据的路径、标识等信息，也可以是可以唯一标识该输入数据的其他信息，本申请对此不作限制。具体地，还可以通过任务界面接口，将该第二界面的输入数据发送给该第二界面。

在具体实施时，在根据预先创建的配置文件激活第一界面之前，还可以包括：获取用户信息；根据所述用户信息，确定对应权限的配置文件。

在具体实施时，对于不同的用户，对应的配置文件可以不同。即，对应的任务流中的任务界面、各界面的上一界面和下一界面信息、或者、各界面的输入数据、输出数据、数据流向等均可能不相同，也可能部分不同。

例如，当前用户为“买家”，则其对应的商品信息显示界面的输入数据仅包括商品名称、商品图片、图品介绍、商品金额等信息；而如果当前用户为“店主”，则其对应的商品信息显示界面的输入数据除商品名称、商品图片、图品介绍、商品金额等信息之外，还可以进一步包括：商品入库时间、商品浏览人数等。

应当理解，在首次执行界面激活方法之前，可以预先执行本申请实施例一中创建配置文件及启动任务流的流程。在创建配置文件并启动任务流之后，可以一次或多次执行本申请实施例二中的界面激活方法；本申请对此不作限制。

图3是实施根据本申请实施例二的界面激活方法时，任务流引擎、taskflow、taskview之间的交互流程图。

实施根据本申请实施例一的界面激活方法时，任务流引擎、taskflow、taskview之间的交互流程包括以下步骤：

s301，任务流引擎创建taskflow；

s302，taskflow向任务流引擎返回创建成功消息；

s303，任务流引擎启动taskflow；

s304，taskflow激活任务界面a的taskview，以激活任务界面a；

s305，任务界面a通过对应的taskview返回“完成数据输入”的用户操作；

s306，taskflow根据界面a的配置信息和步骤305中返回的用户操作，确定a的下一界面为b，激活任务界面b的taskview，以激活任务界面b；

s307，任务界面b通过对应的taskview返回“去往下一任务界面c”的用户操作；

s308，taskflow根据界面b的配置信息和步骤307中返回的用户操作，确定b的下一界面为c，激活任务界面c的taskview，以激活任务界面c；

s309，任务界面c通过对应的taskview返回“返回上一界面”的用户操作；

s310，taskflow根据界面c的配置信息和步骤309中返回的用户操作，确定c的上一界面为b，激活任务界面b的taskview，以激活任务界面b；

s311，任务界面b通过对应的taskview返回“完成数据输入”的用户操作；

s312，taskflow根据界面b的配置信息和步骤311中返回的用户操作，确定关闭任务流。

采用本申请实施例中的界面激活方法，能够将配置文件与界面隔离，在进行界面跳转时，可以在配置文件中查询当前第一界面的配置信息，并根据用户的操作和该配置信息来激活另一界面，从而使得任务界面只需要负责数据的呈现和与用户的交互，便于维护。

基于同一发明构思，本申请实施例中还提供了一种界面激活装置，由于该装置解决问题的原理与本申请实施例一及实施例二所提供的方法相似，因此该装置的实施可以参见方法的实施，重复之处不再赘述。

实施例三

图4为本申请实施例三所示界面激活装置的结构示意图。

如图4所示，根据本申请实施例三所示的界面激活装置400，包括：第一激活模块401，用于根据预先创建的配置文件激活第一界面；查询模块402， 用于在该配置文件中查询该第一界面的配置信息，该配置文件包括多个界面的配置信息，该配置信息包括各界面的上一界面和下一界面的信息；第二激活模块403，用于根据该第一界面返回的用户操作和该第一界面的配置信息，激活第二界面，其中，该第二界面包括该第一界面的上一界面或下一界面。

在具体实施时，第一激活模块具体可以用于根据预先创建的配置文件，通过预先创建的任务界面接口激活该第一界面，该任务界面接口对应该第一界面。

在具体实施时，根据本申请实施例二所示的界面激活装置还可以包括：操作接收模块，用于通过任务界面接口，接收所述第一界面发送的用户操作，其中，所述用户操作包括所述第一界面接收的用户操作。

在具体实施时，根据本申请实施例二所示的界面激活装置还可以包括：反激活模块，用于反激活该第一界面。

在具体实施时，根据本申请实施例二所示的界面激活装置还可以包括：输出数据接收模块，用于通过任务界面接口，接收该第一界面的输出数据。

在具体实施时，根据本申请实施例二所示的界面激活装置还可以包括：公布模块，用于公布第一界面的状态信息，该状态信息包括第一界面为激活状态或反激活状态。

在具体实施时，根据本申请实施例二所示的界面激活装置还可以包括：输入数据查询模块，用于在该配置文件中查询该第二界面的输入数据信息；输入数据获取模块，用于根据该输入数据信息获取该第二界面的输入数据。

在具体实施时，根据本申请实施例二所示的界面激活装置还可以包括：输入数据发送模块，用于通过任务界面接口，将该第二界面的输入数据发送给该第二界面。

在具体实施时，根据本申请实施例二所示的界面激活装置还可以包括：信息获取模块，用于获取用户信息；确定模块，用于根据该用户信息，确定对应权限的配置文件。

在具体实施时，该用户操作可以包括以下一种或多种：完成数据输入、返回上一界面、取消或关闭界面、跳转至下一界面。

在具体实施时，该第二激活模块具体可以用于当用户操作包括完成数据输入时，激活第一界面的下一界面；或者当用户操作包括返回上一界面时，激活第一界面的上一界面；或者当用户操作包括跳转至下一界面时，激活第一界面的下一界面；或者当用户操作包括取消或关闭界面时，激活第一界面的上一界面。

采用本申请实施例中的界面的激活装置，能够将配置文件与界面隔离，在进行界面跳转时，可以在配置文件中查询当前第一界面的配置信息，并根据用户的操作和该配置信息来激活另一界面，从而使得任务界面只需要负责数据的呈现和与用户的交互，便于维护。

本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。

本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中 的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

尽管已描述了本申请的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例作出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本申请范围的所有变更和修改。

显然，本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样，倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。