CN110442292A

CN110442292A - 一种多应用管理方法及装置

Info

Publication number: CN110442292A
Application number: CN201810419061.XA
Authority: CN
Inventors: 吴俊�; 施鹏飞
Original assignee: Shanghai Qinggan Intelligent Technology Co Ltd
Current assignee: Shanghai Qinggan Intelligent Technology Co Ltd
Priority date: 2018-05-04
Filing date: 2018-05-04
Publication date: 2019-11-12

Abstract

本发明提供了一种多应用管理方法及装置，用于管理UI界面上的多款应用，管理方法包括：在上述UI界面上定义若干卡槽区域；为每个卡槽区域提供应用接口；以及在各个卡槽区域内加载卡片，每个卡片由上述多款应用中的至少一款应用通过所属卡槽区域的上述应用接口提供，以指示相应应用的业务操作的交互视图。根据本发明提供的多应用管理方法及装置，能够在UI界面上以滑动卡片的形式展片不同应用形式，使用户大多数情况下不去点击启动应用就可以完成大部分的交互体验。

Description

一种多应用管理方法及装置

技术领域

本发明涉及交互领域，尤其涉及一种多应用管理方法及装置。

背景技术

随着电子行业的发展，安装在电子产品上、能够实现不同功能的大量应用程序应运而生。一方面，在电子产品上安装大量应用会使得电子产品的运行速度受到影响。另一方面，大量应用程序的存在不利于用户简单、快捷地与应用程序之间进行交互。

因此，亟需一种多应用管理方法及管理系统，能够用于管理安装在电子产品上的多个应用程序，并且能够为用户提供一种便捷的与应用程序交互的方式。使用户的操作感受更优。

发明内容

以下给出一个或多个方面的简要概述以提供对这些方面的基本理解。此概述不是所有构想到的方面的详尽综览，并且既非旨在指认出所有方面的关键性或决定性要素亦非试图界定任何或所有方面的范围。其唯一的目的是要以简化形式给出一个或多个方面的一些概念以为稍后给出的更加详细的描述之序。

为了解决上述问题，本发明提供了一种多应用管理方法，用于管理UI界面上的多款应用，包括：在上述UI界面上定义若干卡槽区域；为每个卡槽区域提供应用接口；以及在各个卡槽区域内加载卡片，每个卡片由上述多款应用中的至少一款应用通过所属卡槽区域的上述应用接口提供，以指示相应应用的业务操作的交互视图。

可选地，每个卡槽区域的上述应用接口所连接的上述至少一款应用皆对应上述卡槽区域的卡片类型。

可选地，上述卡片类型包括以下一项或多项：日历及消息中心、出行、车辆、多媒体、通讯、航旅、钱包。

可选地，上述多款应用的每款应用的程序包设有相应的应用卡片盒子用于容纳该应用的卡片的各种卡片视图，每个卡片视图具有所属应用的程序包的包名和所属应用卡片盒子的类名，上述加载卡片包括基于待加载的卡片的包名和类名定位应用卡片盒子并经由相应的应用接口获取上述卡片的卡片视图。

可选地，上述卡片视图包括以下形式：Activity、Widget、反射View。

可选地，对应导航类应用的卡片视图采用Activity形式，对应多媒体类应用的卡片视图采用Widget形式，对应通知卡片的卡片视图采用反射view形式。

可选地，上述卡片视图包括封面卡片视图和内部卡片视图，上述加载卡片包括经由相应的应用接口获取上述封面卡片视图以作为一级卡片进行显示，以及响应于用户对上述一级卡片的点击经由相应的应用接口获取上述内部卡片视图以作为二级卡片进行显示。

可选地，还包括：响应于用户经由上述UI界面的交互操作而采用插件化的形式动态地添加、插入、删除或移动卡片。

可选地，还包括：响应于上述多款应用的特定应用的程序包产生通知，将上述通知以卡片消息的形式发送至上述UI界面的悬浮窗口。

可选地，还包括：响应于用户读取完上述卡片消息，上述卡片消息动态地飞入相关联的卡槽区域。

本发明还提供了一种多应用管理装置，用于管理UI界面上的多款应用，包括：存储器；以及与上述存储器相耦合的处理器，上述处理器配置成：在上述UI界面上定义若干卡槽区域；为每个卡槽区域提供应用接口；以及在各个卡槽区域内加载卡片，每个卡片由上述多款应用中的至少一个应用通过所属卡槽区域的上述应用接口提供，以指示相应应用的业务操作的交互视图。

可选地，上述多款应用的每款应用的程序包设有相应的应用卡片盒子用于容纳该应用的卡片的各种卡片视图，每个卡片视图具有所属应用的程序包的包名和所属应用卡片盒子的类名，上述处理器进一步配置成：基于待加载的卡片的包名和类名定位应用卡片盒子并经由相应的应用接口获取上述卡片的卡片视图。

可选地，上述卡片视图包括封面卡片视图和内部卡片视图，上述处理器进一步配置成：经由相应的应用接口获取上述封面卡片视图以作为一级卡片进行显示，以及响应于用户对上述一级卡片的点击经由相应的应用接口获取上述内部卡片视图以作为二级卡片进行显示。

可选地，上述处理器进一步配置成：响应于用户经由上述UI界面的交互操作而采用插件化的形式动态地添加、插入、删除或移动卡片。

可选地，上述处理器进一步配置成：响应于上述多款应用的特定应用的程序包产生通知，将上述通知以卡片消息的形式发送至上述UI界面的悬浮窗口。

可选地，上述处理器进一步配置成：响应于用户读取完上述卡片消息，上述卡片消息动态地飞入相关联的卡槽区域。

本发明还提供了一种计算机可读介质，其上存储有计算机可执行指令，上述计算机可执行指令在由处理器执行时实施如上述方法的步骤。

根据本发明所提供的多应用管理方法，能够在UI界面上以滑动卡片的形式展片不同应用形式，使用户大多数情况下不去点击启动APP就可以完成大部分的交互体验。本发明提供的多应用管理方法操作简单、便捷，使用户的使用体验感较佳。

附图说明

在结合以下附图阅读本公开的实施例的详细描述之后，能够更好地理解本发明的上述特征和优点。在附图中，各组件不一定是按比例绘制，并且具有类似的相关特性或特征的组件可能具有相同或相近的附图标记。

图1示出了本发明提供的多应用管理方法所管理的UI界面的示意图。

图2示出了本发明提供的多应用管理方法的示意图。

图3示出了本发明提供的多应用管理方法应用与主界面交互的示意图。

图4示出了本发明提供的多应用管理方法应用与应用交互的示意图。

具体实施方式

以下结合附图和具体实施例对本发明作详细描述。注意，以下结合附图和具体实施例描述的诸方面仅是示例性的，而不应被理解为对本发明的保护范围进行任何限制。

为了达到上述目的，本发明提供了一种多应用管理方法，用于管理UI界面(Launcher)上的多款应用，包括，在UI界面上定义若干卡槽(Slot)区域，为每个卡槽区域提供应用接口，以及在各个卡槽区域内加载卡片，每个卡片由多款应用中的至少一款应用通过所述卡槽区域的应用接口提供，以指示相应应用的业务操作的交互视图。

图1示出了本发明提供的多应用管理方法所管理的UI界面的示意图。具体的，如图1所示，每一个卡槽区域定义了该卡槽区域内的卡片类型，因此，每一个卡槽区域的应用接口所连接的至少一款应用都是对应该卡槽区域定义的卡片类型。更具体的，如图1所示，卡槽区域可以定义卡槽内的卡片类型为日历及消息中心、出行、车辆、多媒体、通讯、航旅、钱包中的一者或者多者。

图2示出了本发明提供的多应用管理方法的示意图。如图2所示，每一张卡片都是由多款应用中每款应用的程序包设有相应的应用卡片盒子提供者(BoxProvider)提供，应用卡片盒(Box)用于容纳该应用的卡片的各种卡片视图(View)，每个卡片视图具有所属应用的程序包的包名(Package)和所属应用卡片盒子的类名(Class)，加载卡片包括基于待加载的卡片的包名和类名定位应用卡片盒子并经由相应的应用接口获取卡片的卡片视图。

如图2所示，上述的卡片视图包括封面卡片视图和内部卡片视图，卡片盒子中有作为盒子封面的封面卡片和盒子内部的盒内卡片。UI界面加载卡片的过程包括经由相应的应用接口获取封面卡片视图以作为一级卡片进行显示，以及响应于用户对一级卡片的点击经由相应的应用接口获取内部卡片视图以作为二级卡片进行显示。响应于用户经由UI界面的交互操作而采用插件化的形式动态地添加、插入、删除或移动卡片。

多款应用中的特定应用的程序包在运行过程中可以产生通知，所产生的通知以卡片消息的形式发送到UI界面的悬浮窗口，并且响应于用户读取完卡片消息，上述卡片消息动态地飞入相关联的卡槽区域。

每一个卡片的卡片视图包括Activity、Widget和反射View三种形式，具体的，卡片视图类型的选择由应用的程序包的开发人员和UI界面的开发人员决定。Activity、Widget和反射View三种形式分别有以下特点。

对于Activity形式，好处是应用的程序包的开发较为方便，对应用模块开发人员来说最容易实现。但需要注意Activity生命周期管理，Activity和UI界面的PID是一致的，Activity退出和崩溃都会造成UI界面崩溃，运行需要较大的内存支撑。

对于Widget形式：优点是较轻量，加载快，UI界面本身对其生命周期有管理机制，支持简单动画，即Widget形式，且可以独立开发和调试，不依赖UI界面应用。缺点是无法支持复杂动效如SurfaceView和复杂交互，同时控件支持有限。

对于反射View形式：反射View形式最轻量，是最推荐的一种方式，该反射View的代码可以自由地分散于各种APK代码中，后续也可以从JAR包中加载运行，包括自定义View、自定义Layout都是该种形式支持的。Views中可以支持除Surface以外的各种动画效果，并且本发明提供的多应用管理方法提供了一套对卡片操作管理的机制，使卡片的出现、消失有统一的动画效果，View可以根据开发场景，并且使得消息通知也能采用自定义卡片的形式。另外开发人员可以根据不同应用的场景决定View的实例是缓存着，还是释放以便在需要的时候再创建View，在兼顾性能的同时，也能对内存的占用有一定的控制。

基于Activity、Widget和反射View三种形式的优缺点，对于导航地图类应用类的高效动画卡片可以采用嵌入Activity的形式；大部分普通卡片如多媒体应用类的卡片使用View或Widget形式；通知卡片的卡片视图采用反射View形式。

根据下述的语句定义每个卡片的卡片视图，包括卡片所属卡片盒子的包名、类名、卡片TAG、产生时间，优先级、卡片视图及外带信息等信息。并允许UI界面可以设置卡片视图装载器，以加载处理如上所述的Activity、Widget、反射View这几种形式的卡片视图。

Public class QGBaseCard{

Public static final String TAG＝QGBaseCard.class.getSimpleName()；

Public enum CARD_TYPE{TYPE_ACTIVITY,TYPE_WIDGET,TYPE_REMOTEVIEW}

public static final int PRIORITY_LOW＝0；

public static final int PRIORITY_NORMAL＝1；

public static final int PRIORITY_HIGH＝2；

public staticfinal int PRIORITY_URGENT＝3；

protected String boxPackage；

protected String boxCiass；

protected String cardTag；

protected long timestamp＝0；

protected int priority＝PRIORITY_NORMAL；

protected View mCardView；

protected Parcelable data＝null；

protected IQGCardViewloader mViewloader＝null；

根据下述的语句定义了通知卡片的各种状态，是否保存进历史消息界面，是否飞卡槽，提供设置卡片状态的一套接口，以及根据状态和注册的回调通知相关接口，为UI界面(Launcher)管理卡片用。

public class QGNotificationCard extends QGBaseCard{

private static String TAG＝QGNotificationCard.class.getSimpleName()；

public static final int STATUS_BUILD＝1；

public static final int STATUS_PENDING＝2；//在通知队列待显示

public static final int STATUS_SHOWING＝3；//正在显示

public static final int STATUS_HISTORY＝4；//放入历史消息队列

public static final int STATUS_REMOVED＝5；//已删除

public static:final int MSG_ADD_PENDING_CARD＝0；

public static final int MSG_REMOVE_PENDING_CARD＝1；

public static:final int MSG_REMOVE_HISTORY_CARD＝2；

public static final int MSG_CHECK_CARD＝3；

protected int status＝STATU5_BUILD,

protected boolean isFiyToSiot＝false；

protected boolean needSave＝false；

*

private long timeoutStamp＝0；

private QGNotifyCardlistener mCardlistener；

private static Handler mNotifyCenterHandler＝null；

}

public long getTimeoutStamp(){

return timeoutStamp；

}

public void setTimeoutStamp(long timeoutStamp){

this.timeoutStamp＝timeoutStamp；

}

public void setCardlistener(QGNotifyCardlistener listener){

mCard listener＝listener；

}

public:boolean isFiyToSiotO{

return isFiyToSiot；

}

根据下述的语句定义了用于给BoxProvider产生通知卡片，通过sendCard接口发给launcher：

//用于给盒子提供这产生通知卡片

public class QGPushingCard extends QGNotificationCard{

private static String TAG＝QGPushingCard.class.getSimpleName()；

private QGBoxProvider provider＝null；

@Override

public void destroy(){

//TODO Auto-generated method stub

super.destory()；

Log.d{TAG,"destroy()cardTag＝"+cardTag)；

Log.d{TAG,"destroy()provider＝"+provider)；

if(provider！＝null){

provider.removeCard(cardTag,true)；

}

//通过盒子提供这推送通知卡片

public void sendCard(int delayMS){

Handler handler＝new Handler()；

handler.postDelayed(new Runnable(){

public void run(){

sendCard()；

}

},delayMS)；

}

根据下述的语句定义应用模块，应用模块实现自定义的BoxProvider需要继承QGBoxProvider，并实现IBoxBridge这个跨进程通信接口。

public class QGBoxProvider1extends QGBoxProvider implementsIBoxBridge{

private static String TAG＝QGBoxProvider1.class.getSimpleName()；

private final String tagCards[]＝new String[]{TAG+1,TAG+2,TAG+3,TAG+4,TAG+5,TAG+6}；//提供盒子封面TAG，函数声明不可改变

Provider的子类须实现构造方法和buildView方法在构造方法上添加默认的一级和二级卡片。

1.盒子卡片的初始化：

MyBoxCover和MyBoxCard都是自定义的Layout类，需要根据业务场景产生，在buildView()的时候构造放入ViewMap缓存中。

/*函数声明不可改变盒子在这里完成一些初始化，比如SERVICE绑定、图片库初始化、网络框架加载*/

public QGBoxProvider1(FINAL Context,Handler mHandler,final ContextlauncherContext){

super(context,mHandler,launcherContext)；

Log.e(TAG,*QGBoxProvider1()boxClass＝”+boxClass)；

(new BoxBridgeHelper(context)).registerBoxBridge((boxClass),this)；

(new PluginMsgProxy(context)).register Handler((boxClass),mAppMsgHandler)；

isBoxInited＝true；

setCover(activityTag(“com.qinggan.widget”,”com.qinggan.widget.activity.Ms gViewTestActivity”))；

getCard().add(tagCards[0])；

getCard().add(tagCards[1])；

getCard().add(tagCards[3])；

}

/*函数声明不可改变依据卡片TAG获取View*/

@Override

public View buildView(FINAL String strCardTag){

View mCardView＝null；

if(strCardTag.equals(TAG)){

mCardView＝new MyBoxCover(this,strCardTag)；

}else if(strCardTag.equals(tagCards[0])){

mCardView＝new MyBoxCover(this,strCardTag)；

}else if(strCardTag.equals(tagCards[1])){

mCardView＝new MyBoxCover(this,strCardTag)；

}else if(strCardTag.equals(tagCards[2])){

mCardView＝new MyBoxCover(this,strCardTag)；

}else if(strCardTag.equals(tagCards[3])){

mCardView＝new MyBoxCover(this,strCardTag)；

}else if(strCardTag.equals(tagCards[4])){

mCardView＝new MyBoxCover(this,strCardTag)；

}else if(strCardTag.equals(tagCards[5])){

}

2.盒子卡片运行时的创建和修改。

盒子开发者调用以下接口以通知Launcher卡片的变化

1).设置卡片封面

将盒子封面View对应的tag，不通知Launcher

public void setCover(String cardTag)

2).通知封面发生变化

以便launcher获取最新的盒子封面，Launcher会根据封面的优先级决定卡槽中哪个盒子的封面优先显示为1级卡片

public void notifyCoverChanged()

3).得到当前封面View对应的Tag

public String getCover()

4).得到盒子中卡片的TAG

public List<String>getCards()

5).在盒子中追加一张卡片，并通知Launcher，以便呈现添加动画,(tag对应的View存在的，并已加入ViewMap缓存中)

public boolean addCard(String cardTag)

6).在盒子中插入一张卡片，并通知Launcher，以便呈现添加动画,(tag对应的View存在的，并已加入ViewMap缓存中)

public boolean insertCard(String cardTag,int index)

7).在盒子中追加一张卡片，并通知Launcher，以便呈现添加动画,

public boolean addCard(String cardTag,View view)

8).在盒子中插入一张卡片，并通知Launcher，以便呈现添加动画

public boolean insertCard(String cardTag,View view,int index)

9).删除TAG标记的卡片，isRemoveViewCache说明是否释放卡片的View缓存，被释放的View在被getView中，会通过buildView()重新inflate构建

public void removeCard(String cardTag,boolean isRemoveViewCache)

10).根据卡片索引获取View,index对应二级卡片中本盒子的卡片顺序

public View getCardView(int index)

11).根据卡片索引获取Tag,index对应二级卡片中本盒子的卡片顺序

public String getViewTag(int index)

12).当通知卡片飞入盒子时的回调

public abstract void onNotificationCard(QGNotificationCard card)

13).当卡槽封面切换时通知盒子，盒子可以判断自己的封面是否在显示的状态，可以进行定时消失、除低显示优先级等操作，以便展示其它盒子的封面

public abstract void onBoxCoverDisplayed(String clzName,String tag)

可以通过下述方式定义发送通知卡片。

1.应用进程如果产生一张通知卡片请先通过IBoxBridge接口通知自己的BoxProvider

2.BoxProvider发送通知，通过new QGPushingCard并调用sendCard()方法来发送通知，可以设置卡片的优先级，是否飞卡槽等信息以及自定义data数据。

3.对于常用的通知View，也可以通过QGCardViewBuilder来产生，比如固定格式(标题、文字、左右按钮的).

可以通过下述方式定义卡片飞入盒子

当通知卡片需要在消失时有飞入盒子的请求时，如未接来电、微信回复消息，可以设置QGPushingCard的flyToSlot为true，在Launcher在左侧展示完通知卡片时，会有一个飞入卡槽的动画，动画结束时，会调用盒子的卡片飞入回调接口。boxProvider在收到此通知可以自行决定是否设为盒子封面还是加入二级卡片(当盒子调用设为盒子封面请求时，会触发Launcher的优先级判断逻辑，只有同一卡槽中高优先级的盒子的封面得到显示，请boxProvider注意高优先级卡片封面的显示时间，所有盒子可在onBoxCoverDisplayed()可以自己所在卡槽哪个盒子的封面正在显示)。

@Override

public void onNotificationCard(QGNotificationCard card){

Log.e{TAG,*onNotificationCard()＝+card)；

setCover(card.getCardTag()}；

notifyCoverChanged()；I

//addCard(card.getCardTag()}

}

*

case R.id.btnlowNotify.

{

QGCardViewBuilder cardViewBuilder＝new QGCardViewBuilder(mBoxProvider)；

cardViewBuilder.setTitle("卡片的标题")；

cardViewBuilder.setBackground(R.drawable.timg)；

cardViewBuilder.setMessage("卡片的消息文字；低优先级，不飞卡槽")；

cardViewBuilder.setPositiveButton("确定按钮"(view)→{

Toast.make Text(mContext,"您点击了确定！",Toast.LENGTH_

SHORT).show()；

cardViewBuilder.setNegativeButton("取消按钮"(view)→{

Toast.make Text(mContext,"您点击了取消！",Toast.LENGTH_

SHORT).show()；

})；

String viewTag＝cardViewBuilder.create(mlauncherContext)；

Log.e(TAG,"viewTag＝"+viewTag)；

QGPushingCard mPushingCard＝new QGPushingCard(mBoxProvider,view Tag)；

mPushingCard.setPriority(QGNotificationCard.PRIORITY_LOW)；

mPushingCard.setFlyToSlot(false)；

mPushingCard.sendCard(2000)；

}

消息机制的初衷来源于应用与BoxProvider之间的通信结构，图3示出了消息机制的示意图。如图3所示，BoxProvider作为一个的控制模块，通过BoxBridge承担着上与UI界面通信，下与应用程序通信的作用。为了使各个模块的控制逻辑与UI界面分开，应用程序编写时BoxProvider的代码是打包在应用中的，如图3所示的包含了BoxBridge的BoxProvider和APP应用系在一个实线框。但是运行时BoxProvider的代码又是运行在UI界面中，如图3所示的包含了BoxBridge的BoxProvider和UI界面以及界面的显示控制系在一个虚线框中。

组件之间的通信，究竟是同进程还是跨进程，对应用开发来说是一个困扰。写代码的时候需要转换思维来考虑这是跨进程的消息还是同进程的消息，消息分发机制的设计就是为了解决这样一个困扰应用开发人员发送消息的处理手段，组件只关心发送的消息，不需要关心到底是如何传送到目的地，对于开发人员进行本地开发view，提供了很好的通信支撑。

图4示出了不同组件之间可以互相发送消息的示意图。任何一个需要通信的组件，向通信服务注册自己的handler之后即拥有获得消息的“耳朵”，任何组件需要发送消息给其他组件只要通过定义好的发送接口，将目标对象的名称，信息(message)传递给通信服务，通信服务即可将消息分发到对应的“耳朵”中。通信的组件没有限制，可以是service，activity，view，provider以及任意包含handler的组件对象。

任意两个组件之间的沟通都可以使用该接口。建议与UI界面展现相关的消息使用，如果是与自己应用业务逻辑比较紧密且交互非常频繁的，应用的service端开发接口给界面使用。接口目前分为两类，一类是通用消息分发，一类是专门给客户端与BoxProvider通信使用。

PluginMsgProxy负责提供消息注册与分发接口：

(1)注册监听消息：

PluginMsgProxy pluginMsgProxy＝new

PluginMsgProxy(getApplicationContext())；

pluginMsgProxy.registerHandler(tag,handler)；//注册handler

应用加入以上两句代码，即拥有了获得消息的能力。

(2)分发消息：

public void sendMessage(String curTag,String tarTag,Message msg)；

例如：pluginMsgProxy.sendMessage("a",

"com.example.android_dragbutton.MyView",message)；

应用加入代码，即拥有了分发消息的能力。

BoxBridgeHelper负责提供接口,专门给客户端与BoxProvider通信使用，抽象出跟卡片行为相关的接口。

(1)注册接口

/**

*根据所属app的package登记消息接受端

*

*@param pkg//所属app的包名

*@param boxBridge

*/

public void registerBoxBridge(String pkg,IIBoxBridge boxBridge)

(2)发送消息接口

/**

*发送卡片通知消息

*

*@param pkg//目标Box的包名

*@param tag//目标实例的唯一标识

*@param level//卡片的优先级

*@param isNeedFlyToSlot//是否需要飞入卡槽中

*@param message//消息

*/

public void notifyMessage(String pkg,String tag,int level,boolean

isNeedFlyToSlot,Message message)

(3)增加显示卡片

/**

*当前展示页面，实时增加显示一个卡片

*

*@param pkg 目标Box的包名

*@param tag 目标实例的唯一标识

*@param message 消息

*/

public void addNewCard(String pkg,String tag,Message message)

(4)实时替换当前所有卡片

/**

*实时替换当前所有卡片

*

*@param pkg目标Box的包名

*@param tags目标实例的唯一标识列表

*/

public void refreshCards(String pkg,List<String>tags)

(5)关闭卡片

public void closeCards(String pkg,List<String>tags)

本发明提供的多应用管理方法采用了基于盒子和卡片的抽象模型来设计该多应用管理方法的框架，能够加载不同应用中的盒子对象，并建立了主界面与各个应用盒子模型，以及盒子模型与应用进程交互的消息机制。对于消息卡片，采用了通知卡片策略管理机制，使得具体卡片的内容与实现与主界面分离。主界面仅为和卡片承载的容器，并且卡片支持Activity、Widget和反射自定义View多种形式，提高了主界面的模块化和扩展性，对于减少Launcher APK资源占用，缩短开机时间，优化性能也能起到很大的帮助。通过在UI界面上以滑动卡片的形式展片不同应用形式，使用户大多数情况下不去点击启动APP就可以完成大部分的交互体验。

本发明还提供了一种多应用管理装置，用于管理UI界面上的多款应用，包括：存储器；以及与存储器相耦合的处理器，理器配置成：在UI界面上定义若干卡槽区域；为每个卡槽区域提供应用接口；以及在各个卡槽区域内加载卡片，每个卡片由多款应用中的至少一个应用通过所属卡槽区域的应用接口提供，以指示相应应用的业务操作的交互视图。

本发明还提供了一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现上述方法中的步骤。

其中，多应用管理装置以及计算机可读存储介质的具体实现方式和技术效果均可参见上述多应用管理方法的实施例，在此不再赘述。

本领域技术人员将进一步领会，结合本文中所公开的实施例来描述的各种解说性逻辑板块、模块、电路、和算法步骤可实现为电子硬件、计算机软件、或这两者的组合。为清楚地解说硬件与软件的这一可互换性，各种解说性组件、框、模块、电路、和步骤在上面是以其功能性的形式作一般化描述的。此类功能性是被实现为硬件还是软件取决于具体应用和施加于整体系统的设计约束。技术人员对于每种特定应用可用不同的方式来实现所描述的功能性，但这样的实现决策不应被解读成导致脱离了本发明的范围。

结合本文所公开的实施例描述的各种解说性逻辑模块、和电路可用通用处理器、数字信号处理器(DSP)、专用集成电路(ASIC)、现场可编程门阵列(FPGA)或其它可编程逻辑器件、分立的门或晶体管逻辑、分立的硬件组件、或其设计成执行本文所描述功能的任何组合来实现或执行。通用处理器可以是微处理器，但在替换方案中，该处理器可以是任何常规的处理器、控制器、微控制器、或状态机。处理器还可以被实现为计算设备的组合，例如DSP与微处理器的组合、多个微处理器、与DSP核心协作的一个或多个微处理器、或任何其他此类配置。

结合本文中公开的实施例描述的方法或算法的步骤可直接在硬件中、在由处理器执行的软件模块中、或在这两者的组合中体现。软件模块可驻留在RAM存储器、闪存、ROM存储器、EPROM存储器、EEPROM存储器、寄存器、硬盘、可移动盘、CD-ROM、或本领域中所知的任何其他形式的存储介质中。示例性存储介质耦合到处理器以使得该处理器能从/向该存储介质读取和写入信息。在替换方案中，存储介质可以被整合到处理器。处理器和存储介质可驻留在ASIC中。ASIC可驻留在用户终端中。在替换方案中，处理器和存储介质可作为分立组件驻留在用户终端中。

在一个或多个示例性实施例中，所描述的功能可在硬件、软件、固件或其任何组合中实现。如果在软件中实现为计算机程序产品，则各功能可以作为一条或更多条指令或代码存储在计算机可读介质上或藉其进行传送。计算机可读介质包括计算机存储介质和通信介质两者，其包括促成计算机程序从一地向另一地转移的任何介质。存储介质可以是能被计算机访问的任何可用介质。作为示例而非限定，这样的计算机可读介质可包括RAM、ROM、EEPROM、CD-ROM或其它光盘存储、磁盘存储或其它磁存储设备、或能被用来携带或存储指令或数据结构形式的合意程序代码且能被计算机访问的任何其它介质。任何连接也被正当地称为计算机可读介质。例如，如果软件是使用同轴电缆、光纤电缆、双绞线、数字订户线(DSL)、或诸如红外、无线电、以及微波之类的无线技术从web网站、服务器、或其它远程源传送而来，则该同轴电缆、光纤电缆、双绞线、DSL、或诸如红外、无线电、以及微波之类的无线技术就被包括在介质的定义之中。如本文中所使用的盘(disk)和碟(disc)包括压缩碟(CD)、激光碟、光碟、数字多用碟(DVD)、软盘和蓝光碟，其中盘(disk)往往以磁的方式再现数据，而碟(disc)用激光以光学方式再现数据。上述的组合也应被包括在计算机可读介质的范围内。

提供对本公开的先前描述是为使得本领域任何技术人员皆能够制作或使用本公开。对本公开的各种修改对本领域技术人员来说都将是显而易见的，且本文中所定义的普适原理可被应用到其他变体而不会脱离本公开的精神或范围。由此，本公开并非旨在被限定于本文中所描述的示例和设计，而是应被授予与本文中所公开的原理和新颖性特征相一致的最广范围。

Claims

1.一种多应用管理方法，用于管理UI界面上的多款应用，包括：

在所述UI界面上定义若干卡槽区域；

为每个卡槽区域提供应用接口；以及

在各个卡槽区域内加载卡片，每个卡片由所述多款应用中的至少一款应用通过所属卡槽区域的所述应用接口提供，以指示相应应用的业务操作的交互视图。

2.如权利要求1所述的多应用管理方法，其特征在于，每个卡槽区域的所述应用接口所连接的所述至少一款应用皆对应所述卡槽区域的卡片类型。

3.如权利要求2所述的多应用管理方法，其特征在于，所述卡片类型包括以下一项或多项：

日历及消息中心、出行、车辆、多媒体、通讯、航旅、钱包。

4.如权利要求1所述的多应用管理方法，其特征在于，所述多款应用的每款应用的程序包设有相应的应用卡片盒子用于容纳该应用的卡片的各种卡片视图，每个卡片视图具有所属应用的程序包的包名和所属应用卡片盒子的类名，所述加载卡片包括基于待加载的卡片的包名和类名定位应用卡片盒子并经由相应的应用接口获取所述卡片的卡片视图。

5.如权利要求4所述的多应用管理方法，其特征在于，所述卡片视图包括以下形式：Activity、Widget、反射View。

6.如权利要求5所述的多应用管理方法，其特征在于，对应导航类应用的卡片视图采用Activity形式，对应多媒体类应用的卡片视图采用Widget形式，对应通知卡片的卡片视图采用反射view形式。

7.如权利要求4所述的多应用管理方法，其特征在于，所述卡片视图包括封面卡片视图和内部卡片视图，所述加载卡片包括经由相应的应用接口获取所述封面卡片视图以作为一级卡片进行显示，以及响应于用户对所述一级卡片的点击经由相应的应用接口获取所述内部卡片视图以作为二级卡片进行显示。

8.如权利要求1所述的多应用管理方法，其特征在于，还包括：

响应于用户经由所述UI界面的交互操作而采用插件化的形式动态地添加、插入、删除或移动卡片。

9.如权利要求1所述的多应用管理方法，其特征在于，还包括：

响应于所述多款应用的特定应用的程序包产生通知，将所述通知以卡片消息的形式发送至所述UI界面的悬浮窗口。

10.如权利要求9所述的多应用管理方法，其特征在于，还包括：

响应于用户读取完所述卡片消息，所述卡片消息动态地飞入相关联的卡槽区域。

11.一种多应用管理装置，用于管理UI界面上的多款应用，包括：

存储器；以及

与所述存储器相耦合的处理器，所述处理器配置成：

在所述UI界面上定义若干卡槽区域；

为每个卡槽区域提供应用接口；以及

在各个卡槽区域内加载卡片，每个卡片由所述多款应用中的至少一个应用通过所属卡槽区域的所述应用接口提供，以指示相应应用的业务操作的交互视图。

12.如权利要求11所述的多应用管理装置，其特征在于，每个卡槽区域的所述应用接口所连接的所述至少一款应用皆对应所述卡槽区域的卡片类型。

13.如权利要求12所述的多应用管理装置，其特征在于，所述卡片类型包括以下一项或多项：

14.如权利要求11所述的多应用管理装置，其特征在于，所述多款应用的每款应用的程序包设有相应的应用卡片盒子用于容纳该应用的卡片的各种卡片视图，每个卡片视图具有所属应用的程序包的包名和所属应用卡片盒子的类名，所述处理器进一步配置成：

基于待加载的卡片的包名和类名定位应用卡片盒子并经由相应的应用接口获取所述卡片的卡片视图。

15.如权利要求14所述的多应用管理装置，其特征在于，所述卡片视图包括以下形式：Activity、Widget、反射View。

16.如权利要求15所述的多应用管理装置，其特征在于，对应导航类应用的卡片视图采用Activity形式，对应多媒体类应用的卡片视图采用Widget形式，对应通知卡片的卡片视图采用反射view形式。

17.如权利要求14所述的多应用管理装置，其特征在于，所述卡片视图包括封面卡片视图和内部卡片视图，所述处理器进一步配置成：

经由相应的应用接口获取所述封面卡片视图以作为一级卡片进行显示，以及响应于用户对所述一级卡片的点击经由相应的应用接口获取所述内部卡片视图以作为二级卡片进行显示。

18.如权利要求11所述的多应用管理装置，其特征在于，所述处理器进一步配置成：

19.如权利要求11所述的多应用管理装置，其特征在于，所述处理器进一步配置成：

20.如权利要求19所述的多应用管理装置，其特征在于，所述处理器进一步配置成：

21.一种计算机可读介质，其上存储有计算机可执行指令，所述计算机可执行指令在由处理器执行时实施如权利要求1-10中任一项所述方法的步骤。