用于应用程序和容器的集成的制作方法
【技术领域】
[0001]本公开内容一般涉及计算装置领域，并且更具体地说，涉及在计算环境中集成选择的应用程序和容器。
【背景技术】
[0002]最终用户具有比以前任何时候更多的媒体和通信选择。多种卓越的技术趋势当前在进展中(例如，更多计算装置，更多应用程序，更多在线视频服务，更多可定制特征)，并且这些趋势在更改媒体前景。关于移动性，诸如Apple，Inc.(及其移动产品系列(例如，iPhone?、iPad?、iPod?等))等公司已在应用程序模型中成功执行。自然地，操作系统(例如，Microsoft Windows 8/Metro ?)已更改以符合此突增的应用程序模型。
[0003]应用模型的一个缺点涉及应用程序不能在移动屏幕(S卩，计算装置的显示器上)同时共存。此缺点阻止了最终用户进行多任务的能力。换而言之，在当前移动上下文中，在最终用户启动应用程序时，应用程序将占用移动装置屏幕的全部空间(real estate)。为交换到另一应用程序，最终用户被迫切换回主屏幕以选择单独的应用程序，或者使用另一手势以便检索到在背景运行的应用程序列表，并且随后启动另一应用程序，该应用程序随后将出现在屏幕前台中。一旦新应用程序启动，以前的应用程序便从屏幕中被消除，并且新选择的应用程序再次占用移动装置屏幕的全部空间。
[0004]这些应用程序管理活动是麻烦的。同时访问不同类型信息的此愿望(例如，用户对在不同应用程序中发起的不同信息片段感兴趣)不能通过现有移动平台得到解决。
【附图说明】
[0005]为提供本公开内容及其特征和优点的更完整理解，将结合附图，参照以下描述，其中类似的标号表示类似的部分，其中:
图1是根据本公开内容的一个实施例，用于为集成应用程序和容器提供框架的通信系统的简化框图；
图2是示出用于主控面板(dashboard)配置的一个可能示例的简化示意图；
图3A-3B是示出根据本公开内容的一个实施例，涉及移动装置的可能共享活动的简化框图；
图4是示出与本公开内容相关联的可能活动的简化流程图；
图5是示出与移动装置相关联的示例体系结构的简化框图；
图6是与本公开内容的示例ARM生态系统芯片级系统(SOC)相关联的简化框图；以及图7是示出可用于执行与本公开内容相关联的活动的示例逻辑的简化框图。
【具体实施方式】
[0006]概述本文提供了一种用于组合一个或更多个应用程序的一个或更多个容器的计算装置，计算装置能够包括处理器、存储器和配置成访问包括多个第一容器的第一应用程序，访问包括多个第二容器的第二应用程序，并且至少部分基于第一应用程序和第二应用程序，生成主控面板(dashboard)的主控面板模块。容器映射模块也能够提供并且配置成将多个第一容器的一个特定容器映射到第一功能性，并且将多个第二容器的一个特定容器映射到第二功能性。主控面板能够包括多个第一容器的一个特定容器和多个第二容器的一个特定容器，其中，在计算装置的指派(即，指定)的显示位置提供主控面板。
[0007]在更具体的实施例中，计算装置能够包括屏幕空间(screen real estate)选择模块，该模块配置成接收与所述主控面板的所述指派的显示位置相关联的指令，并且指派用于所述主控面板的一个或更多个显示边界。计算装置配置成访问和编辑主控面板。计算装置能够配置成使用网络连接向远程位置公布主控面板。计算装置也能够配置成与至少一个其它计算装置共享主控面板。在某些情况下，计算装置配置成从第一应用程序中提取一个线容器，并且将它与来自第二应用程序的一个线容器组合。作为采用收到的另外主控面板的一部分，主控面板也能够配置成提示计算装置的最终用户下载缺失的应用程序。另外，主控面板模块能够配置成接收要用作模板的随后主控面板以创建另外主控面板。另外，主控面板模块配置成生成要分布到涉及一个或更多个雇员的分布列表的另外主控面板。另外主控面板能够被标记成只读，使得它不能由另外主控面板的接收者编辑。基于雇员职位，能够将另外主控面板分布到一个或更多个雇员。
[0008]一个或更多个实施例能够将可能的有利效应与能够提供此类效应的实施例特征相结合。例如，某些实施例允许最终用户通过使用几个不同应用程序的各种容器来个性化其主控面板。另外，某些实施例能够允许最终用户共享，公布，编辑等其主控面板创建。
[0009]示例实施例
转到图1，图1是示出与本公开内容的一个实施例，配置用于集成应用程序和容器的通信系统10的简化框图。通信系统10可包括最终用户12和可包括多个容器18a-18c的多个应用程序14。最终用户12可使用任何适合的接口(例如，有线，无线，经第三方应用程序商店等)与应用程序14连接。另外，图1可包括容器映射功能性模块20、屏幕空间选择模块25和主控面板模块30:所有这些模块均在下面讨论。
[0010]在详细讨论图1的平台的一些可能能力和特征前，重要的是理解在应用程序模型中遇到的一些操作系统难题。以下基本信息可视为从中可适当解释本公开内容的基础。考虑涉及简单社交媒体应用程序(例如，Facebook ?)的示例。如果最终用户打开Facebook ?应用程序，则她能够开始移动图片、新闻馈送等。在浏览器，此特定用户注意到朋友对本周末即将发生的事件的评论。因此，最终用户快速启动其天气应用程序以便检查周末的预报。在该天气应用程序加载时，用户通过检查股票价格，查看工作电子邮件等开始进行多任务。一旦天气应用程序完全运转，最终用户便查看信息，并且随后返回到Facebook应用程序。在工作日期间，用户能够继续使所有这些应用程序打开，这是因为她相对有规律地系统性保持到这些应用程序的宽松连接。
[0011]许多操作系统(诸如Linux?、Windows "*等OS)已形成窗口的概念，概念能够实现以便允许用户同时看到许多应用程序。虽然这可适用于一些有限的台式机情形，但由于不断减小的屏幕大小和交互模型原因，此类模型不适用于移动装置。提出的一种辩护能够是在许多情况下，最终用户不需要看到全部应用程序以便到达她寻求访问的信息。换而言之，最终用户可只寻求访问应用程序的某个组成、段或部分(例如，用于某个地区(zip-code)的一天天气预报而不是Weather Channel ?应用程序的整个主页)。
[0012]诸如Windows?和Linux ?等许多操作系统允许用户设置紧挨着的不同窗口，以尝试创建允许跨多个应用程序的多任务的视图。然而，对于移动OS，不存在此类范例。另外，虽然移动OS确实允许某些应用程序发送通知(例如，短消息服务(SMS)通知或推送通知)到主屏幕和可能到共享屏幕空间，但此共享是瞬间的，并且不能由用户修改。因此，今天的当前应用程序是孤立的(siloed)，并且此外它们包含在特定平台和/或装置内。这使得应用程序在用于用户的量身定制体验的上下文中不灵活。
[0013]另外，近年来也出现了几种移动主控面板实例。然而，这些解决方案均未向最终用户提供通过合成(composit1n)创建其自己的应用程序的选项，该选项提供了形成量身定制体验的能力。另外，现有主控面板一旦被创建，未能提供共享这些量身定制体验的能力。考虑用户开发了多个烹调应用程序，并且寻求将应用程序公布回到应用程序商店，与朋友共享，并且在社交媒体站点上发布应用程序等的情形。
[0014]其它应用程序策略尝试通过提供可对接任务栏来解决许多这些问题。这些机制是未有助于任何类型的个性化、量身定制或应用程序合成的程序的一部分。Android?框架通过意图(intent)支持一定程度的再使用性，但意图未向最终用户显露，并且它们不能在应用程序之间再使用。某些其它解决方案提供块片(tile)，块片能够伴有繁重的通知系统。然而，这些解决方案不允许最终用户开辟应用程序的一部分，并且随后将它用作块片以便共享该定制的体验。
[0015]根据本公开内容的教导，图1的框架能够允许创建更易控制(amenable)的主控面板以提供愉乐的移动装置体验。在一个特定实现中，最终用户能够创建在其单独屏幕上带有多个容器的个性化主控面板，其中，在任何适合的时间间隔期间(例如，在其日常活动期间)，能够轻松地编辑，保存，共享和系统性参考主控面板。本公开内容的一个实施例能够允许基于来自不同应用程序的任何数量的容器的即兴集成(ad hoc integrat1n)(即，混合，合并或混搭)，定制移动屏幕。如下面进一步详细描述的一样，容器集成允许最终用户个性化其自己的移动体验。这些容器也能够设置成基于上下文，以位置、日时间、周时间和其它参数的形式更改。
[0016]考虑最终用户12对其移动装置上的多个应用程序具有访问权的图1的示例。能够向最终用户12呈现用于将应用程序14划分成单独的容器18a-18c的框架。此一般活动在图1中标示为#1。随后，容器映射功能性模块20能够用于选取这些容器，并且将它们映射到不同功能性。此一般活动在#2指示。在#3，在映射活动期间能够采用屏幕空间选择模块25。因此，在开发人员开发其应用程序时，向他们呈现能够将其应用程序划分成容器的框架，这些容器映射到不