一种用户参与的Android APP流个性化定制方法
技术领域
[0001] 本
发明涉及Android应用开发技术领域，特别是涉及一种在Android平台下的APP流(APPs)定制方法。
背景技术
[0002] 随着移动终端设备计算能
力的提高，除了随时随地可以使用移动终端提供的内置功能外，还可以利用众多的移动应用APP
访问Internet完成在一些原来PC端的事务，这使得移动终端设备成为随身携带的互联网入口。APP的高速发展使其呈现出明显的碎片化特征，即应用市场中众多APP都只专注于特定功能需求，而用户需求往往需要多个APP所提供的服务。通常一部智能手机中安装了数十或上百个APP，当用户想要使用某个APP时，必须以滑动屏幕的方式在整个APP图标列表中查找该APP。更接近用户真实使用需要的是能够以组合和协作的方式协同执行多个APP的APP流个性化定制功能。
[0003] APP流个性化定制是以用户为主导，由用户根据自身的业务需要
指定APP之间的集成顺序，在实际使用中，按照预先定制的规则运行APP或获取服务。目前，已有较为成熟的面向移动终端用户提供应用集成服务的工具和产品，其中典型代表有Tasker、IFTTT等。Tasker产品在使用时，由Android系统根据用户定制的“配置文件(Profiles)”，在特定的“背景(Contexts)”下，执行指定“任务(Tasks)”的应用(IEEE，2011：685-690)。IFTTT产品(IF THIS THEN THAT)在使用时，首先由用户创建自己的流程(Recipes)，Recipes包括两个网络服务(Channels)，前者被称为触发器频道，后者为动作频道，如果触发器频道满足触
发条件，那么就会执行动作频道指定的动作(Macuser，2013，4(9):4-9)。然而Tasker产品的任务仅仅涉及改变手机的系统设置以及启动手机中的某个APP，且配置文件的编写类似编程语言，普通用户难以轻松驾驭；IFTTT产品以服务提供商合作参与为前提，故IFTTT的使用受到服务数量、语言地区等限制。
[0004] 还有其他的已有APP流定制技术方案，或是仅涉及对系统级的APP进行操作，或是用户使用
门槛较高，再或是支持范围有限等。因此需要对现有的APP流定制方法进行改进，以更接近用户的真实使用需要。例如以组合和协作的方式协同多个APP，从而满足用户需求。
发明内容
[0005] 针对以上
现有技术存在的
缺陷，本发明提出了一种用户参与的AndroidAPP流个性化定制方法，实现了常用APP进行应用流的定制
原型，并依据此定制原型按照用户参与的自定义流程进行APP流个性化定制方法。
[0006] 因此，针对该需求，提供一种用户参与的AndroidAPP流个性化定制方法，以提升用户体验。
[0007] 本发明的一种用户参与的AndroidAPP流个性化定制方法，存储有多条指令，适于在
手持设备上实现的多个APP构成的个性化APP流的定制与执行，该方法包括以下步骤：
[0008] 步骤一、安装需进行个性化定制所要选择的APP列表中的所有APP；
[0009] 步骤二、实现APP流定制和APP
流管理，其中，APP流定制是由用户根据自身业务需求选择手机内APP列表中合适的APP进行集成实现定制，将APP流存储于本地的SQLite
数据库中，采用SharedPreferences方式对定制APP流的首个APP进行存储，其余APP按定制顺序进行执行；APP流管理包括对APP流进行编辑以及对APP流进行删除两种操作；
[0010] 步骤三、实现APP流执行，初始时，APP流处于等待状态，位于列首的APP的启动事件，是整个APP流的触发事件，被触发的APP流从本地数据库中被激活，切换到执行状态；执行状态中，APP流中的每一个APP按顺序执行，并且完成APP流内数据信息的重用和共享，执行状态持续直到用户退出位于APP流的最末一个APP，在此之后，APP流重新返回等待状态；除非用户主动终止，整个APP流的状态不被外界打扰直到执行结束。
[0011] 所述步骤二中的APP流满足以下条件：
[0012] 条件一、APP流中若包含重复的APP，则重复的APP应不相邻；
[0013] 条件二、与已经存在的APP流不重复，即不能保存完全相同的APP流。
[0014] 所述步骤三的APP流执行步骤中，还包括实时监控APP流中包含的每一个APP的启动、运行及退出，通过设置Android中的AlarmManager每5秒钟启动一个查询服务，该查询服务利用ActivityManager获取处于可见状态的Activity，也就是用户当前所交互的界面，，判断该Activity来源于哪一个Package，即是属于哪一个APP；若本次查询结果与前一次发生变化，则用户在最近的5秒内进行了启动或退出APP的操作。该查询服务利用ActivityManager获取处于可见状态的Activity，也就是用户当前所交互的界面。
[0015] 所述步骤三的APP流执行步骤中，还包括利用Android
进程间通信Messenger对象来实现不同APP间的消息交互，通过消息总线实现各APP间的消息共享；并采用多线程技术来实现APP间交互内容的相似性计算。
[0016] 所述步骤三的APP流执行步骤中，还包括若有多条定制APP流共享同一触发事件，根据用户选择执行具体的APP流，；将APP流的当前状态表示为{APP0,APP1,…,APPi-1,APPi}，若APP流处于执行状态，则将应用退出消息以广播形式发送出去，广播接收者会对当前APP流中的上一个状态APPi-1内可获取数据进行收集，并对当前APP流中的下一个状态APPi进行数据注入后，再启动APPi。
[0017] 与现有技术相比，本发明通过对现有技术进行改进，根据用户的使用习惯，提出了用户参与的AndroidAPP流定制方法，提供了预期的有益效果包括：
[0018] 1、用户在执行复杂的业务需求时，可以通过本发明提供的方法及原型定制个性化的AndroidAPP流，从而执行APP时，不需要分别启动各自需要的APP，而能够实现连续的流式执行。
[0019] 2、本发明提供的APP流定制方法对用户的专业要求很低，用户只需要在提供的APP列表中根据APP的图标和名称进行拖拽选择，并且能够方便地对已经存在的APP流进行管理，简化用户操作。
附图说明
[0020] 图1为APP流个性化定制
实施例示意图；
[0021] 图2、3为基于某一旅游场景实现用户参与的AndroidAPP流个性化定制客户端原型示意图；
[0022] 图4为本发明的一种用户参与的AndroidAPP流个性化定制方法整体
流程图。
具体实施方式
[0023] 下面将结合附图对本发明的具体实施方式作进一步的详细描述。
[0024] 本发明所提到的用户参与的AndroidAPP流个性化定制中的APP流是已知且不需要通过复杂的计算获得的，将APP流的当前状态表示为{APP0,APP1,…,APPi-1,APPi}。
[0025] 如图1所示为APP流个性化定制实施例示意图，用户首先选择并连接APP，通过定制流程建立以构成固定的APP流101，APP流101被存储在数据库102中；在定制流程执行阶段，定制好的APP流中的用户输入支持注入操作和提取操作，在APP流开始阶段是等待状态，中间阶段是执行状态，直至执行完成后再次恢复等待状态；触发事件的发生使得APP流从等待状态过渡至执行状态；终止事件的发生使得APP流从执行状态过渡至等待状态。
[0026] 以上述的实施例为例，具体说明本发明的实现流程，主要包含APP流定制和APP流执行。
[0027] 第一步、APP流定制，由用户根据自身业务需求选择手机内APP列表中合适的APP进行集成实现定制；在本发明实现的Android客户端中，为普通用户提供了APP流定制界面和APP流管理界面。
[0028] 在APP流定制界面中，显示可供用户选择的进行混搭的APP的名称和图标，用户可以采用拖拽图标的方式，将选择的APP图标拖至APP流定制区域，并通过图标的先后
位置确定APP流的协同执行顺序，在确定好顺序以后提交该APP流。客户端对提交的APP进行检查，合规的APP流应该满足以下条件：
[0029] 条件一、出于对移动业务复杂度的分析和APP流执行效果的考虑，APP流所包含的APP不超过5个，不少于2个；
[0030] 条件二、APP流中可以包含重复的APP，但重复的APP应不相邻；
[0031] 条件三、与已经存在的APP流不重复，即不能保存完全相同的APP流；
[0032] APP流存储于本地的SQLite数据库中，并采用Android中的SharedPreferences方式对APP流中位于列首的APP进行存储。列首的APP作为APP流的触发器，其启动将促使后续APP依序启动，即在列首的APP启动时，从数据库中读取完整APP流进行后续APP的执行。
[0033] APP流管理界面作为客户端入口，用来显示当前设备中已经存在的APP流，如图2所示。用户可以对已经存在的APP流进行管理，包括编辑和删除。除此之外，用户可以选择该界面上的“Add”按钮，跳转到应用流定制界面进行新的APP流构建。在首次安装客户端时，使用Android的PackageManager获取手机中的所有应用的基本信息，包括应用名称、版本号、包名、图标等，并保存在本地数据库中。
[0034] 第二步、APP流执行
[0035] 初始时，APP流处于等待状态。位于列首的APP的启动事件，是整个APP流的触发事件，被触发的APP流从本地数据库中被激活，切换到执行状态。执行状态中，APP流中的每一个APP按顺序执行，并且通过APP交互模
块完成流内数据信息的重用和共享，执行状态持续直到用户退出位于APP流的最末一个APP，这是整个APP流的终止事件，在此之后，APP流重新返回等待状态。除非用户主动终止，整个APP流的状态不被外界打扰直到执行结束。
[0036] APP流执行的关键问题在于监控APP的启动和退出，本发明采用了后台轮询获取前台界面的方式。首先，通过设置Android中的AlarmManager每5秒钟启动一个查询服务，该查询服务利用ActivityManager获取处于可见状态的Activity，也就是用户当前所交互的界面，之后判断该Activity来源于哪一个Package，即是属于哪一个APP。由于用户连续启动两个APP的间隔基本上不会短于5秒，因而有理由相信，若本次查询结果与前一次发生变化，则用户在最近的5秒内进行了启动或退出APP的操作。可以按照前后两次的具体变化划分启动或退出事件，例如若前一次为系统主界面，后一次为某一第三方APP的界面，则用户在5秒内触发启动事件，反之亦然。
[0037] 若系统中所有APP流都处于等待状态，则将启动消息以广播形式发送出去，广播接收者判断该应用启动事件是否为某条流的触发事件，若是，则将该APP流的完整信息从数据库中读出，APP流将进入执行状态。若有多条流程共享同一触发事件，则由用户选择执行具体的某条流程。若系统中已有APP流处于执行状态，则将应用退出消息以广播形式发送出去，广播接收者会启动APP交互模块对上一个APP内可获取数据进行收集，并
对流程中的下一个APP进行数据注入后启动。
[0038] 由于在APP流执行时，会涉及到对信息的提取和注入，本发明使用Messenger对象实现Android中的
进程间通信，它可以处理Message对象，根据APP流的执行情况对Messenger的消息处理执行不同的操作(提取/注入)。使用Messenger方式进行进程间通信，内部维护了一个Handler消息队列，它可以保证线程安全。并将本发明的Android原型实现作为客户端，而APP作为服务端，达到消息的传递与共享目的，从而使客户端作为“消息总线”完成APP间的数据共享，实现APP流的执行。
[0039] 如图2、3所示，为基于某一旅游场景实现用户参与的AndroidAPP流个性化定制客户端原型举例。
[0040] 首先是场景描述：
[0041] 假设某同学3天后要到北京参加学术论坛，在出发之前，需要做如下准备：
[0042] 查询并预定3天后“天津--北京”的高
铁车票；
[0043] 查询并预定北京市的某一酒店，入住时间是3天后；
[0044] 查询并浏览北京市的团购信息，包括推荐餐厅、特色周边等；
[0045] 查询北京市的天气情况；
[0046] 将订票信息、酒店预订信息、天气情况等保存到备忘录中。
[0047] 本场景中，为避免过多的APP影响展示效果，因而基于案例场景，在客户端安装了10个与旅游相关的APP，例如有携程旅行、钱友火车票、去哪儿旅行、同程旅行、百度糯米、美团团购、2345天气王、备忘录和乐记事。携程旅行和铁友火车票负责查询及预订火车票业务，去哪儿旅行和同城旅行提供酒店预订服务，百度糯米和美团团购属于团购业务领域，
2345天气王为用户提供天气预报信息，备忘录和乐记事便于用户记录琐碎信息。
[0048] 图2中(a)为本发明实现的Android客户端启动后的主界面。在该界面中，显示设备中已经存在的自定义集成的APP流。图2(a)中已存在一条APP流，协同加载和执行“携程旅行-铁友火车票-同程旅游-美团团购-乐记事”这五个APP，该APP流以“携程旅行”为触发条件，按照箭头所示方向顺序启动。实现的客户端在此过程中进行后台监控及APP调度，并作为消息中转站实现五个APP之间的数据通信。APP流程协同满足了用户“出行准备”的复杂需求，尽可能地避免了用户搜索应用和重复操作等交互障碍。
[0049] 选择“添加新流程”选项，跳转到交互式APP流定制界面，如图2中(b)所示。在流程定制过程中，用户首先选择应用图标，之后该应用以虚线框标记。在图3中的(c)的示例中，用户最后选择了“2345天气”，然后在“建立新流程”的区域内选择合适的空白图标位置，即表示将所选择的APP放置在新建流程的相应位置，图3的(c)所示，用户将“2345天气”放置在了新流程的最后一个位置。无论是APP列表中被选中的APP还是已经添加到流程定制中的APP，均以“长按应用图标”的方式取消该项选择。
[0050] 按照上述构建流程的方式，用户新建一条APP流，图3中(c)所示的该应用流以“铁友”为触发器，依序包含“携程”、“同程”、“美团”和“2345天气王”共5个APP。点击“确定”后，跳转回流程管理主界面，图3中(d)所示，此时流程已经添加到设备中，目前系统中共有两条应用流。
[0051] 以第一条APP流为例，当用户启动“携程旅行”APP时，APP流被触发，当用户退出携程时，客户端后台以系统弹窗的方式询问用户是否继续按照应用流顺序执行启动“铁友火车票”。若用户选择“Yes”，系统自动启动“铁友火车票”APP，并且通过重用用户在“携程”中输入的目的地等关键信息得到一个注入的界面。若用户选择“No”，系统视为用户主动终止了APP流的执行。对于后续的“同程旅游-美团团购-乐记事”，均以同样的方式与用户交互、注入并启动，直到用户完成信息备份并从“乐记事”中退出。
