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

文档序号：19127945发布日期：2019-11-13 02:19阅读：174来源：国知局

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

背景技术：

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

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

技术实现要素：

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

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

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

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

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

可选地，上述卡片视图包括以下形式：activity、widget、反射view。

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

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

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

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

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

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

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

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

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

可选地，上述卡片视图包括以下形式：activity、widget、反射view。

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

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

可选地，上述处理器进一步配置成：响应于用户经由上述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这几种形式的卡片视图。

publicclassqgbasecard{

publicstaticfinalstringtag＝qgbasecard.class.getsimplename()；

publicenumcard_type{type_activity,type_widget,type_remoteview}

publicstaticfinalintpriority_low＝0；

publicstaticfinalintpriority_normal＝1；

publicstaticfinalintpriority_high＝2；

publicstaticfinalintpriority_urgent＝3；

protectedstringboxpackage；

protectedstringboxciass；

protectedstringcardtag；

protectedlongtimestamp＝0；

protectedintpriority＝priority_normal；

protectedviewmcardview；

protectedparcelabledata＝null；

protectediqgcardviewloadermviewloader＝null；

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

publicclassqgnotificationcardextendsqgbasecard{

privatestaticstringtag＝qgnotificationcard.class.getsimplename()；

publicstaticfinalintstatus_build＝1；

publicstaticfinalintstatus_pending＝2；//在通知队列待显示

publicstaticfinalintstatus_showing＝3；//正在显示

publicstaticfinalintstatus_history＝4；//放入历史消息队列

publicstaticfinalintstatus_removed＝5；//已删除

publicstatic:finalintmsg_add_pending_card＝0；

publicstaticfinalintmsg_remove_pending_card＝1；

publicstatic:finalintmsg_remove_history_card＝2；

publicstaticfinalintmsg_check_card＝3；

protectedintstatus＝statu5_build,

protectedbooleanisfiytosiot＝false；

protectedbooleanneedsave＝false；

privatelongtimeoutstamp＝0；

privateqgnotifycardlistenermcardlistener；

privatestatichandlermnotifycenterhandler＝null；

}

publiclonggettimeoutstamp(){

returntimeoutstamp；

}

publicvoidsettimeoutstamp(longtimeoutstamp){

this.timeoutstamp＝timeoutstamp；

}

publicvoidsetcardlistener(qgnotifycardlistenerlistener){

mcardlistener＝listener；

}

public:booleanisfiytosioto{

returnisfiytosiot；

}

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

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

publicclassqgpushingcardextendsqgnotificationcard{

privatestaticstringtag＝qgpushingcard.class.getsimplename()；

privateqgboxproviderprovider＝null；

@override

publicvoiddestroy(){

//todoauto-generatedmethodstub

super.destory()；

log.d{tag,"destroy()cardtag＝"+cardtag)；

log.d{tag,"destroy()provider＝"+provider)；

if(provider！＝null){

provider.removecard(cardtag,true)；

}

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

publicvoidsendcard(intdelayms){

handlerhandler＝newhandler()；

handler.postdelayed(newrunnable(){

publicvoidrun(){

sendcard()；

}

},delayms)；

}

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

publicclassqgboxprovider1extendsqgboxproviderimplementsiboxbridge{

privatestaticstringtag＝qgboxprovider1.class.getsimplename()；

privatefinalstringtagcards[]＝newstring[]{tag+1,tag+2,tag+3,tag+4,tag+5,tag+6}；//提供盒子封面tag，函数声明不可改变

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

1.盒子卡片的初始化：

myboxcover和myboxcard都是自定义的layout类，需要根据业务场景产生，在buildview()的时候构造放入viewmap缓存中。

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

publicqgboxprovider1(finalcontext,handlermhandler,finalcontextlaunchercontext){

super(context,mhandler,launchercontext)；

log.e(tag,*qgboxprovider1()boxclass＝”+boxclass)；

(newboxbridgehelper(context)).registerboxbridge((boxclass),this)；

(newpluginmsgproxy(context)).registerhandler((boxclass),mappmsghandler)；

isboxinited＝true；

setcover(activitytag(“com.qinggan.widget”,”com.qinggan.widget.activity.msgviewtestactivity”))；

getcard().add(tagcards[0])；

getcard().add(tagcards[1])；

getcard().add(tagcards[3])；

}

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

@override

publicviewbuildview(finalstringstrcardtag){

viewmcardview＝null；

if(strcardtag.equals(tag)){