本发明涉及一种图像处理装置。
背景技术：
具有诸如复印、打印和传真的功能的多功能机器的功能被进一步扩展，因此要求有效地构造包括各种应用的整个系统。
日本未审专利申请公开no.2012-248102描述了一种图像处理装置，其允许用户容易地识别应用列表画面上显示的图标的应用是否在执行期间。配置包括：画面信息存储单元，针对用于调用其中注册了应用和应用的操作设置的宏的图标，所述画面信息存储单元存储包括图标位置、图标图像、应用识别信息和宏识别信息的列表画面信息；画面控制单元，其获取与作业状态从待机变为执行的应用有关的状态信息，输出识别信息，并且作出画面更新请求；画面创建单元，如果接收到对基于列表画面信息所创建的应用的列表画面的画面更新请求，则所述画面创建单元将由获取的识别信息指示的应用的图标的显示风格更新为不同于另一应用的图标的显示风格；显示单元，其显示包括更新的图标的列表画面。
日本未审专利申请公开no.2012-27662描述了在具有扩展功能的多功能机器中改进用户的可操作性。配置包括：布置信息存储单元，其存储图标布置信息，在图标布置信息中，标准应用、扩展应用、以及用于标准应用和扩展应用之间的识别的应用识别信息与关于对应图标的坐标信息和关于图标的图像信息相关联；列表画面创建单元，其创建其中基于图标布置信息显示与标准应用和扩展应用对应的图标的应用列表画面；显示单元，其显示创建的应用列表创建画面；画面控制单元，其根据图标布置信息指定与按下的图标对应的标准应用或扩展应用，并且对指定的标准应用或扩展应用做出操作画面显示请求。
在现有技术中，作为图像处理装置的系统，准备大的根应用并且提供将从各应用使用的各种功能。所有应用取决于根应用。
而且，专门负责(handle)图像处理装置中的各种设备的状态的设备应用独立地存在。实质上，所有应用取决于设备应用。
另外，应用之间的公共实现在发展，并且应用也彼此依赖。
因此，每次添加或删除应用时，要求在应用之间进行调整，同时，时常要求修正(correct)根应用。因此，可能不能容易地添加或删除应用。
技术实现要素：
本发明的目的是提供一种图像处理装置，其限制应用之间的依赖性(dependence)并且允许容易地添加或删除应用。
根据本发明的第一方面，提供了一种图像处理装置，包括：架构上的应用，所述应用分离为负责基本处理的核心逻辑部和负责渲染处理的用户接口框架部并且进行操作；以及控制器，所述控制器执行所述应用和所述架构。所述核心逻辑部安装有由所述架构定义的应用编程接口。核心逻辑部公布用于与另一应用的核心逻辑部进行通信的方法和事件。
根据本发明的第二方面，基于第一方面中描述的图像处理装置，核心逻辑部可以停止公布所公布的方法和事件。
根据本发明的第三方面，基于第一或第二方面中描述的图像处理装置，核心逻辑部可以执行所公布的方法的调用、所公布的事件的监听器(listener)的注册、以及事件的触发(fire)中的至少一个。
根据本发明的第四方面，基于第一方面中描述的图像处理装置，图像处理装置还可以包括外部应用；以及设置在架构与外部应用之间的配套(companion)应用。配套应用可以指示架构响应于来自用户的指令来激活外部应用。架构可以响应于来自配套应用的激活外部应用的指令激活外部应用，并且在比应用的窗口的层低的层中设置和显示外部应用的窗口。
根据本发明的第五方面，基于第四方面中描述的图像处理装置，架构响应于激活外部应用的指令可以将外部应用的窗口设置在比应用的窗口的层低的层中并且暂时不显示外部应用的窗口，并且架构可以响应于来自配套应用的显示外部应用的指令不显示应用的窗口而显示外部应用的窗口。
根据本发明的第六方面，基于第五方面中描述的图像处理装置，如果横幅(banner)或故障被显示，则架构可以响应于来自配套应用的显示外部应用的指令显示应用的窗口。
根据本发明的第七方面，基于第四至第六方面中的任一方面描述的图像处理装置，架构可以响应于激活外部应用的指令将用于管理外部应用的窗口的虚拟管理元素嵌入到应用的窗口中，显示外部应用的窗口，并以透明的方式显示虚拟管理元素。
根据本发明的第八方面，基于第七方面中描述的图像处理装置，架构可以在识别对以透明方式显示的虚拟管理元素的操作的同时操作外部应用，作为对外部应用的操作。
根据本发明的第九方面，基于第四方面中描述的图像处理装置，架构可以响应于来自用户的终止外部应用的指令，指示配套应用终止外部应用。配套应用可以响应于终止外部应用的指令删除关于外部应用的管理信息，并指示架构显示初始画面。架构可以响应于显示初始画面的指令显示初始画面而不是外部应用。
根据本发明的第十方面，基于第四方面中描述的图像处理装置，如果外部应用异常终止，则架构可以指示配套应用终止外部应用。配套应用可以响应于终止外部应用的指令删除关于外部应用的管理信息，并指示架构显示初始画面。架构可以响应于显示初始画面的指令显示初始画面而不是外部应用。
根据本发明的第十一方面，基于第四方面中描述的图像处理装置，在显示外部应用的窗口的状态下，当架构响应于来自用户的操作显示初始画面时，架构可以不显示外部应用的窗口，并向配套应用通知不显示外部应用的窗口。配套应用可以响应于关于不显示外部应用的窗口的通知更新关于外部应用的管理信息。
利用本发明的第一方面，可以限制应用之间的依赖性，可以容易地添加或删除应用，并且可以提供应用之间的通信。
利用本发明的第二方面，已经公布了一次的方法和事件可以在此之后被停止公布。
利用本发明的第三方面，可以在应用之间调用所公布的方法，可以注册所公布的事件的监听器，并且可以触发事件。
另外，利用本发明的第四或第五方面，即使在添加外部应用时，也可以通过架构来控制外部应用的激活。
另外，利用本发明的第六方面，可以在外部应用上以层叠的方式显示横幅或故障。
另外，根据本发明的第七方面，可以与普通应用类似地控制外部应用。
另外，利用本发明的第八方面，即使在以层叠的方式显示横幅等的状态下，也可以操作外部应用。
另外，利用本发明的第九或第十方面，可以通过架构来控制外部应用的终止。
另外，利用本发明的第十一方面，可以通过架构来控制对所提供的初始画面(而不是外部应用)的显示和管理。
附图说明
将基于以下附图详细描述本发明的示例性实施方式，其中：
图1是图像处理装置的功能框图；
图2是系统的逻辑配置图；
图3是示出主页画面的示例的说明图；
图4是应用的逻辑配置图；
图5是现有技术的系统的逻辑配置图；
图6是架构上的应用的配置图；
图7是示出应用的特定配置示例的说明图；
图8是示出应用列表的特定配置示例的说明图；
图9提供示出核心逻辑和ui框架的模式的说明图；
图10a至10c是ui和逻辑改变时的说明图；
图11a和11b是均示出架构上的应用的模式的说明图；
图12是包括引导器(booter)和启动器(starter)的生命周期管理的系统配置图；
图13是生命周期管理的时序图；
图14是示出从系统激活到主页画面显示的时间的图表；
图15是实现外部应用时的逻辑配置图；
图16是实现外部应用时的另一逻辑配置图；
图17是配套应用的配置图；
图18是示出关于配套应用的清单信息的说明图；
图19是架构的配置图；
图20是窗口管理信息的配置图；
图21是外部应用的激活时序图；
图22是外部应用的窗口推出时序图；
图23是外部应用的再显示时序图；
图24是外部应用正常终止时的时序图；
图25是外部应用异常终止时的时序图；
图26是外部应用从外部终止时的时序图；
图27是内部浏览器和外部应用的层结构的说明图；以及
图28a和图28b是外部应用和横幅的层叠显示状态的说明图。
具体实施方式
下面参照附图描述本发明的示例性实施方式。
总体系统配置
图1是包括根据此示例性实施方式的图像处理装置的图像处理系统的配置框图。图像处理系统包括终端装置10和图像处理装置12。终端装置10和图像处理装置12通过通信单元14彼此连接。通信单元14例如使用诸如局域网(lan)的数据通信网络。
终端装置10通过通信单元14与图像处理装置12连接，并且根据用户的指令发送例如包括文档的打印命令的打印作业。
图像处理装置12包括只读存储器(rom)16、随机存取存储器(ram)18、硬盘驱动器(hdd)20、由一个或多个中央处理单元(cpu)构成的控制器22、输入/输出接口(i/f)24、诸如触摸面板的操作单元26、和图像处理单元28。
由一个或多个cpu构成的控制器22通过输入/输出i/f24从终端装置10接收例如打印作业命令，解释页面描述语言(pdl)数据并且创建中间数据，并且根据rom16中存储的处理程序从创建的中间数据进一步创建渲染数据(光栅数据)。而且，控制器22执行从操作单元26接收的诸如复印、扫描和传真的各种命令。
图像处理单元28包括打印模块、扫描模块、传真模块、纸馈送模块、原稿馈送模块和图像处理加速器。
打印模块具有在纸上输出图像的功能。例如，打印模块包括已知喷墨方法的配置，并且在纸上打印渲染数据。打印模块从喷嘴等排出液体或溶融固体墨，并且在纸、膜或另一材料上执行记录。排出墨的方法包括利用静电引力排出墨的按需喷墨方法(压力脉冲法)，以及利用通过在高温下用热形成和生长气泡而生成的压力来排出墨的热喷墨方法。要使用的记录头包括例如排出青色墨的头、排出品红色墨的头、排出黄色墨的头和排出黑色墨的头。每个头使用至少宽度等于纸宽度的线头。各色的墨滴通过用于记录的记录头排出在中间转印体上，然后转印在纸上用于打印。
扫描模块从纸读取图像并且将图像转换为电子数据。
传真模块包括调制解调器和传真图像处理模块，并且执行传真功能。
纸馈送模块将纸从纸盘传送到打印模块。
原稿馈送模块将纸从原稿盘传送到扫描模块。
图像处理加速器是与例如扫描模块关联地执行压缩/扩展处理的模块。图像处理加速器不一定要提供并且可以是附加模块。
除了前述模块以外，图像处理装置12还可以包括提供例如纸的穿孔和分类的装订器；通用串行总线(usb)；由集成电路(ic)卡读取器等配置并且对用户进行认证的认证单元；计费单元；和/或人体传感器、面部相机等。
而且，图像处理装置12可通过通信单元14与互联网连接，或者可包括以太网(注册商标)和/或wi-fi(注册商标)。
程序的逻辑配置
图2示出由控制器22执行的系统的逻辑配置。系统被大致分离成两层，所述两层包括表示层30和设备服务层32。
表示层30是实现各种应用的层，包括架构31和各种应用。架构31是允许javascript(注册商标)应用在计算机系统上可操作的执行环境软件组。更具体地，javascript在网页浏览器上执行，并且基本框架和ui框架作为超文本标记语言(html)的iframe被加载。而且，这种应用是利用由架构31提供的应用编程接口实现的javascript软件。架构31管理各种应用的生命周期。即，对于各种应用中的每个，架构31创建基本框架，读取应用的核心逻辑，并且向核心逻辑给出初始化指令。而且，在系统停用(deactivation)时，架构31向各种应用中的每个的核心逻辑给出终止化指令，并且删除基本框架。稍后更详细地描述各种应用中的每个的核心逻辑和生命周期管理。
设备服务层32是管理各种硬件设备的层。硬件设备例如包括上面描述的图像处理单元28的打印模块。
图3示出图像处理装置12的操作单元26上显示的画面(主页画面)的示例。主页画面包括显示在上面的图标。图标包括复印按钮34、id卡复印(id复印)按钮36、扫描按钮38、传真按钮40、我的复印按钮42、网络应用(网络应用1)按钮44和简单复印按钮46。当用户触摸并选择按钮之一时，分配给按钮的应用被激活，并且画面转变为应用画面。用户可意识到按钮对应于应用。
每个应用是提供由架构31定义的应用编程接口的javascript软件，并且是直接向用户提供功能的组件。每个应用具有由架构31定义的通用配置。而且，每个应用被配置为针对另一应用具有低链接度(linkdegree)。应用包括通过用户接口(ui)与用户协作的应用以及不与用户协作的应用。与用户协作的应用通过表示层30主观地执行显示和输入。
图还示出使用户进行登录的登录按钮48。此按钮也对应于应用。
应用的实现结构
图4示出应用的结构。应用50被大致分离成三个组件。即，应用50被分离成核心逻辑52、ui框架54、清单(manifest)文件56。在这种情况下，“分离”不表示物理分离，而是表示逻辑分离。
核心逻辑52是作为应用执行基本处理(基本行为和应用间关联)的组件，并且必须存在于每个应用中。核心逻辑提供由架构31定义的应用编程接口。
ui框架54是作为应用提供渲染和显示的组件，或者更具体地，作为显示窗口被管理。
清单文件56是关于每个应用的静态信息的列表。静态信息可包括应用的标识符(id)、显示名称、图标图像、版本、创建日期等。清单文件56包括核心逻辑清单文件56-1和ui框架清单文件56-2。要由清单文件56写入的一条信息是islaunchable属性。利用此属性，确定应用是否被显示为主页画面上的图标(按钮)。属性如下：
如果islaunchable＝true则选择显示；并且
如果islaunchable＝false则选择不显示。
利用此配置，核心逻辑52与ui框架54之间的通信规则如下：
(1)核心逻辑52与另一核心逻辑52通信；
(2)ui框架54仅与核心逻辑52通信。
因此，ui框架54不与另一ui框架54通信。
图5示出现有技术的程序配置。在现有技术中，准备大的根应用(rootapp)600，并且提供要从各个应用使用的各种功能。所有应用取决于此根应用600。而且，专门负责各种设备的状态的设备应用(deviceapp)620也独立地存在。基本上所有应用取决于此设备应用620。另外，应用之间的公共实现在发展，而且应用彼此依赖。因此，即使在添加或删除应用的情况下，这种情况每次发生时要求在应用之间进行调整，并且时常要求修正根应用600。不能容易地添加或删除应用。
相比之下，图6示出此示例性实施方式的程序配置。每个应用分离为核心逻辑52、ui框架54、清单文件56。每个应用的核心逻辑52与架构31连接。每个应用的ui框架54与应用的核心逻辑52连接。
例如，示例性描述复印应用，复印应用分离为核心逻辑52、ui框架54、清单文件56。核心逻辑52与架构31连接。ui框架54与核心逻辑52连接。不同于现有技术，在不存在依赖性的情况下限制各个应用之间的链接，因此由架构31通过核心逻辑52执行应用之间的关联。每个应用的核心逻辑52提供由架构31定义的应用编程接口。因此，当新添加应用时，可通过提供由架构31定义的应用编程接口容易地执行添加。而且，因为应用之间的链接被限制，所以可容易地删除应用。
图7示出复印应用的示例。在图中，baseframe.html是核心逻辑52，base_manifest.json是核心逻辑52的清单文件56-1。而且，uiframe.html是ui框架54，app_manifest.json是ui框架54的清单文件56-2。
图8示出应用列表的示例。在图中，“base”表示核心逻辑52的清单文件56-1，“app”表示ui框架54的清单文件56-2。在清单文件56-2中，“type”表示应用的类型。应用的类型如下。
具体地，应用包括四种类型。
std：预安装的应用
ot：预安装的应用(std)的快捷方式
ext：可添加的应用(类型i应用)
cs：可添加的应用(类型ii应用)
预安装的应用是图3中示出的对应于复印、扫描、传真等的应用。而且，ot、ext、cs的每个应用分配有特定的配套应用。每个配套应用负责对应的功能。与std应用类似，每个配套应用也包括核心逻辑52。因为清单文件56包括应用的类型，所以每个应用的内部实现可与另一应用的内部实现区分开。
而且，清单文件56-2中的“islaunchable”是如上所述的确定图标是否被显示在主页画面上的属性信息。在图中，显示如下。
islaunchable＝true
这表示复印按钮被显示。
因为应用被分离为核心逻辑52和ui框架54，所以应用列表描述二者之间的对应关系。
针对每个应用创建清单文件56。因此，期望设置表示每个应用的类型的标识符和类型中的唯一标识符。例如，复印应用的清单文件具有如下的标识符。
type：std
id：copy
在这些标识符中，type是表示类型(预安装的应用)的标识符，id是唯一标识符。
另外，清单文件56包括激活时需要的信息和渲染主页画面需要的信息，作为静态信息。激活时需要的信息是关于核心逻辑52的存储位置信息和关于ui框架54的存储位置信息。架构31参照关于核心逻辑52的存储位置信息加载核心逻辑52。而且，如果需要，核心逻辑52参照关于ui框架54的存储位置信息加载ui框架54。
渲染主页画面需要的信息是关于图标按钮的存储位置信息和按钮的显示顺序。
清单文件56被设备服务层中的应用管理组件参照，并且用于创建应用列表(稍后描述)。
图9示出应用的实现结构的模式。
图9中的部分(a)符合存在核心逻辑52但不存在ui框架54的模式。这不对应于预安装的应用，而是对应于例如配套应用。图9中的部分(d)是对应于图9中的部分(a)的应用列表。
图9中的部分(b)符合核心逻辑52和ui框架54通过一一对应关系存在的模式。图9中的部分(e)是对应于图9中的部分(b)的应用列表。
相比之下，图9中的部分(c)示出存在核心逻辑52和多个ui框架54并且多个ui框架54共享公共核心逻辑52的情况。ui框架54确定当按钮显示在主页画面上时的显示风格。即使当显示多个按钮时，通过共享公共核心逻辑52，来提高实现效率。而且，如果多个应用共享公共核心逻辑52，则提高了维护性能。共享公共核心逻辑52的ui框架54的数量不受限制。图9中的部分(f)是对应于图9中的部分(c)的应用列表。清单文件56-1的特定示例例如如下。
清单文件56-2的特定示例例如如下。
另一示例如下。
在图9中的部分(b)和部分(c)中，通过设置ui框架54的清单文件56-2的islaunchable属性值，来确定按钮是否实际显示在主页画面上。例如，在图9中的部分(c)中，在存在共享公共核心逻辑52的第一ui框架54和第二ui框架54的情况下，第一ui框架54的清单文件是islaunchable＝true，第二ui框架54的清单文件是islaunchable＝false，前一个被显示为按钮，而后一个没有被显示。
作为应用的执行结构，核心逻辑52与ui框架54分离。因此，可仅改变ui框架54而不改变核心逻辑52，并且可容易地定制应用在画面上的显示风格。
图10a至10c均示出定制画面上的显示风格的示例。
图10a是初始显示风格。关注id卡复印的应用，它的ui框架54是idcopy/uiframe.html，它的清单文件56-2是idcopy/app_manifest.json。
图10b示出定制显示风格的情况。在id复印的应用中，针对新的显示风格，用idcopy_for_xxx/uiframe.html和idcopy_for_xxx/app_manifest.json替换ui框架54和清单文件56-2。当然，也可仅替换清单文件56-2。
相比之下，图10c示出不改变显示风格而改变应用的逻辑的情况。在这种情况下，核心逻辑52、ui框架54、清单文件56都被新组件替换。即，copy/所指示的部分被copy_for_xxx/替换。
图11a和11b均示出包括架构31的特定应用的实现结构的模式。
图11a示出实现复印应用和id复印应用的情况下模式的示例。复印应用被分离为核心逻辑52和ui框架54。核心逻辑52与架构31通信。ui框架54仅与核心逻辑52通信。类似地，id复印应用被分离为核心逻辑52和ui框架54。核心逻辑52与架构31通信。ui框架54仅与核心逻辑52通信。
图11b是除了复印应用和id复印应用以外实现打印应用的情况下的另一示例。复印应用和id复印应用被分离为公共核心逻辑52和相应的ui框架54。即，复印应用和id复印应用通过公共核心逻辑52与架构31通信。而且，打印应用具有核心逻辑52，但不具有ui框架54。图11a和11b包括图9中示出的所有模式。
在现有技术的应用实现结构中，不同于上述结构，核心逻辑52和ui框架54彼此不分离，并且处理和画面渲染混合，导致复杂的结构。而且，不存在应用的公共编程接口，每个应用自由地公布(publish)编程接口并且自由地参照编程接口。相比之下，在此示例性实施方式中，架构31定义应用编程接口，每个应用的核心逻辑52必须用应用编程接口实现。因此，此示例性实施方式中的应用编程接口的方向不同于现有技术中的应用编程接口的方向。而且，除了架构31与每个应用之间的通信以外，应用之间的通信编程接口也可通过由架构31提供的编程接口公布功能和应用编程接口参照功能来实现。
理论上，多个应用可共享公共ui框架54并且可分别具有各个核心逻辑52。然而，在这种情况下，从架构31的观点看，结构可能复杂，因此在此示例性实施方式中这种情况没有被具体描述。当然，不一定意在排除这种模式。
应用的生命周期管理
图12示出当架构31对于每个应用执行生命周期管理时的基本配置。在这种情况下，架构31是应用的执行环境。
架构31和各种应用50以及引导器60和启动器应用64存在于表示层中。而且，应用管理组件62存在于设备服务层中。
引导器60是执行整个表示层的激活/停用管理的组件。架构31通过引导器60被初始化和激活。
应用管理组件62基于各种应用50的清单文件56向架构31提供应用列表。
启动器应用64是利用由架构31定义的启动器i/f66实现的应用。启动器应用64是系统中仅存在的一个应用，当所有应用50的初始化完成时被从架构31调用。
各种应用50包括复印应用、id复印应用、传真应用等，并且包括如上所述的核心逻辑52。各种应用50的核心逻辑52均利用由架构31定义的应用i/f68实现。
具体地，每个应用50中实现的应用编程接口如下。
·初始化处理(initialize)
·终止化处理(finalize)
·窗口推出处理(windowpushedout)
·窗口准备露出处理(windowprepareexposed)
·窗口准备终止处理(windowprepareterminated)
利用这些事件的句柄(handler)实现每个应用50。
架构31包括用于启用方法的公布/调用的javascript组件(称为通信控制组件)、以及各种应用50的核心逻辑52之间的事件的公布/购买/发布(issue)。方法可定义为取得期望参数并且返回期望返回值。以应用为基础独立地管理公布的方法。调用方法的应用可通过回调来检查方法的处理的完成。而且，可由每个应用利用期望数据定义事件。以应用为基础独立地管理公布的事件。更具体地，通信控制组件通过核心逻辑52启用方法的公布和调用，启用事件的定义和发布以及监听器的注册，通过“on”(开)公布方法，并且通过“off”(关)停止方法的公布。公布的方法能够通过调用而被调用。例如，类型i应用设置特定应用编程接口“开”用于向架构31公布，类型ii应用针对类型i应用的公布的编程接口向架构31作出“调用”。
下面根据更具体的规范(应用编程接口或api)来描述方法的公布/调用、以及事件的公布/购买/发布。
作为javascript组件的对象arenacom是arenacom，并且方法通过arenacom.on(methodname，methodfunc)公布。参数methodname是要公布的方法的名称，methodfunc是要公布的方法处理的实体。公布的方法能够通过调用而被调用。
通过isnacom.off(methodname)停止方法的公布。methodname是要停止公布的方法的名称。
所公布的方法通过arenacom.call(appid，methodname，args，callbacl)被调用。appid是方法公布源的应用id，methodname是用于调用的公布方法名称，args是参数，callback是在方法处理完成时要调用的回调函数。
通过arenacom.publishevent(eventname)公布事件。eventname是要公布的事件的名称。监听器能够在事件公布后立即被注册。而且，事件通过isnacom.unpublishevent(eventname)取消公布。eventname是要取消公布的事件的名称。
对于所公布的事件通过arenacom.addlistener(appid，eventname，listenerfunction，completecallback)注册监听器。appid是公布的事件的应用id，eventname是要接收的事件的名称，listenerfunction是在事件发生时要调用的处理的实体，completecallback是在完成监听器的注册时要调用的回调函数。
通过arenacom.fireevent(eventname，data，completecallback)触发事件。eventname是要触发的事件的名称，data是伴随事件的数据，completecallback是在完成针对事件的所有监听器的触发时要调用的回调函数。
通过isnacom.fireeventto(listenerid，eventname，data，completecallback)针对特定的监听器触发事件。listenerid是事件通知目标的应用id，completecallback是在完成针对事件的特定监听器的触发时调用的回调函数。
图13是架构31对于各种应用中的每个的生命周期管理的时序图。
当引导器60激活架构31时，架构31从设备服务层中的应用管理组件62请求应用列表，并且从应用管理组件62获取应用列表。
当架构31获取了应用列表时，架构31根据列表以应用为基础创建基本框架，并且加载包括启动器应用64的各种应用50(加载阶段)。即，架构31读取每个应用的核心逻辑52。具体地，架构31参照清单文件56中定义的关于核心逻辑52的存储位置信息加载核心逻辑52。基本框架是用于执行每个应用的核心逻辑52的框架，并且此框架不被显示。期望确定各个应用的核心逻辑的加载顺序并且顺序没有被具体限制。在所有应用已完成应用编程接口实现的注册的时间点处，此阶段进入下一阶段。
要注意，每个应用的方法和事件在应用编程接口实现的注册处理之前公布。
接下来，架构31通过应用编程接口向每个应用给出初始化指令(初始化阶段)。具体地，架构31向每个应用发布“app”事件和“initialize”方法。在响应于初始化指令的处理完成后所有应用回调的时间点，架构31通知引导器60初始化处理的完成，并且阶段进入下一阶段。也可期望地确定各应用的初始化的顺序。在此初始化处理中，每个应用执行从设备服务层的数据获取。
然后，引导器60向架构31给出用于通过应用提供功能的启动指令，并且架构31响应于给出的指令向启动器应用64给出启动指令(启动阶段)。启动器应用64获取关于在设备服务层中管理的初始激活应用的信息，并且显示初始画面。在响应于启动指令的处理完成后启动器应用64回调的时间点，此阶段完成。
在系统停用时，架构31向每个应用的核心逻辑52给出终止化的指令。而且，架构31删除每个应用的基本框架。
在加载阶段中，各个应用的核心逻辑52被读取，而没有特别限制的顺序。因此，即使当添加应用时，加载阶段也不必被改变。而且，在初始化阶段中，所有应用被初始化。因此，确保调用其它应用，并且不需要个体同步。如上所述，因为不再要求应用之间的同步并且仅加载大小相对小的核心逻辑52，所以系统激活时间和应用激活时间缩短。
如果每个应用独立地公布应用编程接口，则激活、初始化前处理、初始化处理、初始化后处理、停止、暂时停止等在应用的基础上是不同的。在每个应用的初始化级别产生差异，并且应用能够被调用的时间也变化。特别地，在调用主题应用之前要求检查该应用是否能够被调用。控制可能复杂。相比之下，在示例性实施方式中，初始化时间可如上所述缩短，并且初始化之后的主页画面的激活时间可缩短。
图14示出根据现有技术和示例性实施方式的从系统激活到主页画面显示的时间。
在现有技术中应用初始化时间除了要求纯初始化时间之外，还要求同步，类似地，主页画面的激活时间除了要求纯激活时间之外还要求同步。相比之下，在此示例性实施方式中，可缩短纯初始化时间，并且可消除同步。而且，对于主页画面激活时间，可提供类似的效果。在现有技术中，如果应用彼此依赖，则需要调整以防止产生死锁。然而，在此示例性实施方式中，不存在这种依赖，因此不再需要死锁调整。
如上所述，在此示例性实施方式中，应用被分离为核心逻辑52和ui框架54，通过架构31定义的应用编程接口在核心逻辑52中实现，核心逻辑52通过架构31与另一应用的核心逻辑52通信，ui框架54仅与应用的核心逻辑52通信。因此，每个应用具有通过框架31定义的通用配置，并且可配置为与另一应用具有低链接度。可容易地添加或删除应用。
接下来描述实现可以添加的应用的情况。如上所述，应用包括预先安装的应用和可以添加的应用。预先安装的应用是提供由架构31定义的应用编程接口的软件，可以称为内部应用。相比之下，可以添加的应用可以是现有应用，或者可以是由第三方提供的应用。因此，可以添加的应用是外部应用，该应用不一定提供由架构31定义的应用编程接口。关于此，期望实现可以在稍后阶段中添加的应用(在下文中，称为“外部应用”)，而不添加大的修正，并且防止外部应用影响另一内部应用的操作，即使外部应用的操作不稳定或异常。
因此，如上所述，根据外部应用的类型将特别的配套应用分配给外部应用，并且在配套应用被设置在架构31与外部应用之间时执行外部应用。
图15示出包括外部应用和配套应用的系统的逻辑配置。图15对应于图2。表示层30利用主页应用(homeapplication)70、控制异常情况下的画面的故障应用72以及配套应用74、76和78(作为内部应用)来实现。表示层30也利用外部应用a80、外部应用b82以及外部应用c84(作为外部应用)来实现。配套应用74是对应于外部应用a80的配套应用。配套应用76是对应于外部应用b82的配套应用。配套应用78是对应于外部应用c84的配套应用。配套应用74、76和78均是设置在架构31与外部应用a80、外部应用b82以及外部应用c84中的对应的一个之间的软件。架构31具有吸收对外部应用a80、b82和c84请求的条件的功能。当用户操作配套应用74、76和78中的任何一个的主页画面上的按钮时，响应于来自主页应用70的请求激活外部应用a80、b82和c84中对应的一个。因为配套应用74、76和78作为内部应用吸收请求，所以配套应用74、76和78可以作为内部应用满足需求而无需修正外部应用a80、b82和c84。
图16示出另一逻辑配置。在此配置中，不是针对外部应用中的每个实现配套应用，而是单个配套应用75管理多个外部应用。配套应用75是对应于外部应用a80、b82和c84的配套应用。配套应用75是设置在架构31与外部应用a80、b82和c84之间的软件。架构31具有吸收对外部应用a80、b82和c84请求的条件的功能。
当激活外部应用时，期望保持与内部应用的画面过渡和画面的可操作性类似的画面过渡和画面的可操作性，以无缝地构建整个系统。因此，应用分别由不同的浏览器激活，使得内部应用由内部浏览器激活，并且外部应用由外部浏览器激活。即使外部浏览器发生异常，该异常也不会影响内部浏览器。架构31统一管理内部浏览器和外部浏览器。更具体地，架构31通常将外部浏览器作为除了正常的iframe-base窗口之外的一种类型的窗口来管理。以这种方式，内部浏览器和外部浏览器作为窗口被统一管理和控制，并因此关于内部应用的画面控制信息和关于外部应用的画面控制信息被整合。因此，简化了控制。
在此示例性实施方式中，虽然架构31统一管理内部浏览器和外部浏览器，并且通常将外部浏览器作为除了正常的iframe-base窗口之外的一种类型的窗口来管理，但可以根据情况构建其中配套应用具有内部浏览器与外部浏览器之间的切换的监督功能的系统。
图17是配套应用74的功能框图。此功能框图可以类似地应用于配套应用75、76和78中的每个。
配套应用74包括外部应用元信息管理单元741、操作条件检查单元742、外部应用激活指示单元743、外部应用进程管理单元744和事件检测单元745作为功能模块。
外部应用激活指示单元743通过架构31向主页应用70提供外部应用按钮信息，并且响应于用户对外部应用按钮的操作，通过架构31接收来自主页应用70的启动命令。当外部应用激活指示单元743接收到启动命令时，外部应用激活指示单元743向架构31提供窗口的创建命令和窗口的显示命令，并且更新关于外部应用进程管理单元744的信息。
外部应用元信息管理单元741存储关于配套应用74的清单信息。
操作条件检查单元742在接收到激活命令时检查权限的存在。
外部应用进程管理单元744存储由窗口的创建命令创建的外部应用进程。
事件检测单元745接收外部应用终止请求命令。
配套应用74可以包括：异常终止检测器，该异常终止检测器在外部进程异常终止时接收关于外部进程的异常终止的通知，并且更新关于外部应用进程管理单元744的管理信息；以及上下文变化检测器，该上下文变化检测器检测注销等，终止操作中的外部应用，并清除缓存。
图18示出存储在外部应用元信息管理单元741中的清单信息的示例。在图18中，“type”指示应用的类型，“ext”指示应用是外部应用。而且，“subid”指示类型中的id。而且，“appurl”指示url，利用该url打开外部浏览器。另外，“toolsicon”和“displayname”指示要在主页画面上显示的图标及其名称。
图19是架构31的功能框图。架构31包括事件发送/接收单元311、画面控制器312、应用区分单元313、窗口管理单元314、层管理单元315以及应用管理单元316作为功能模块。
画面控制器312控制整个流程。即，画面控制器312执行从自外部接收到窗口的创建请求到返回结果的整个控制。而且，画面控制器312创建窗口管理信息，并将该信息添加到窗口管理单元314。
应用区分单元313通过使用应用的类型来区分对要调用的功能的调用。即，应用区分单元313根据该功能是内部应用的功能还是外部应用的功能来区分调用。具体地，应用区分单元313存储确定应用的类型与功能之间的对应关系的表，并且通过使用此表来区分调用。
层管理单元315管理层结构。层管理单元315管理每个层中的活动窗口。具体地，层管理单元315以应用层、弹出层、横幅层、警报(低级)层、警报(高级)层和故障层的顺序来管理层结构，并且将用于外部应用的窗口插入到内部应用的应用层下面的层中。
窗口管理单元314通过使用窗口id来管理关于每个窗口的信息。窗口信息包括内部窗口信息和外部应用窗口信息。
图20示出由窗口管理单元314管理的窗口管理信息的示例。窗口管理信息由公共管理信息314a和内部窗口管理信息314b或外部应用窗口管理信息314c构成。在内部应用的情况下，窗口管理信息由公共管理信息314a和内部窗口管理信息314b构成。在外部应用的情况下，窗口管理信息由公共管理信息314a和外部应用窗口管理信息314c构成。公共管理信息314a包括窗口id、显示状态和确定层的层id。内部窗口管理信息314b包括用于内部窗口的html的div元素和html的iframe元素。外部应用窗口管理信息314c包括用于外部窗口的html的div元素和设备服务层(d层)的进程id。在这种情况下，用于外部窗口的html的div元素是用于将外部窗口嵌入到内部窗口中的div元素。用于外部窗口的html的div元素是只有透明架构的空div元素，即，该div元素充当虚拟div元素。通过以与处理用于内部应用的iframe相同的方式将虚拟div元素插入到画面层中，可以执行无缝画面控制。
更详细地描述配套应用74的各功能模块和架构31的各功能模块的操作。
图21示出从用户操作主页画面上的外部应用的按钮的时候到显示外部应用的时候的顺序。该顺序对应于用户进行的处理、主页应用70进行的处理、配套应用74(或配套应用75、76或78)进行的处理、架构31进行的处理、以及设备服务层(设备层)32进行的处理。
当用户按下外部应用按钮时，主页应用70将针对由用户按下的按钮的启动命令及其伴随信息发送至配套应用74。伴随信息包括外部应用的id，即，清单信息的subid。
配套应用74的外部应用激活指示单元743从主页应用70接收启动命令，并且基于外部应用id从外部应用元信息管理单元741获取外部应用元信息。而且，外部应用激活指示单元743命令操作条件检查单元742来检查是否满足指定的外部应用的激活条件。配套应用74的操作条件检查单元742从架构31获取当前用户，从设备服务层32的权限信息管理单元获取当前用户拥有的权限，并且检查当前用户是否具有激活指定的外部应用的权限。配套应用74的外部应用激活指示单元743向架构31发布用于窗口的创建命令(createwindow)。在这种情况下，提供关于外部应用的具体信息，或者更具体地提供外部应用的类型和id。
当架构31的画面控制器312从配套应用74接收到用于窗口的创建命令(createwindow)时，应用区分单元313确定由应用区分单元313用于创建窗口信息的功能。画面控制器312执行由应用区分单元313确定的用于外部应用的窗口创建功能，并且创建窗口管理信息。窗口管理信息由公共管理信息314a和外部应用窗口管理信息314c来配置。外部应用窗口管理信息314c可以包括如上所述的在内侧用于嵌入的虚拟div元素。画面控制器312将创建的窗口管理信息添加到窗口管理单元314。画面控制器312基于管理信息命令设备服务层32激活外部应用。具体地，画面控制器312给出外部浏览器激活请求的命令以及外部应用的类型和id。
设备服务层32激活指定的外部应用并将其进程id返回到架构31。设备服务层32不显示创建的外部应用窗口，并将创建的外部应用窗口设置在低于内部浏览器窗口的层的层中。
当架构31接收到进程id时，作为窗口创建命令(createwindow)的结果，架构31将外部应用的窗口id返回给配套应用74。
配套应用74向架构31发布外部应用显示请求(showwindow)。
当架构31的画面控制器312接收到外部应用显示请求(showwindow)时，画面控制器312开始针对指定窗口的显示处理，并且如果存在在相同层中显示的另一个不同的窗口，则画面控制器312开始针对该不同的窗口的不显示处理(推出处理)。如果指定的窗口是外部应用窗口，则显示在内侧作为虚拟或别名(alias)被创建的div，并显示外部应用窗口。然后，由层管理单元315指定的窗口被注册为最下层中的窗口。而且，画面控制器312确定是否显示内部浏览器窗口。即，画面控制器312对层管理单元315进行查询，检查每个层中显示的窗口，如果在除最下层以外的层的内侧显示诸如横幅或故障的窗口，则显示内部浏览器，如果不是，则不显示内部浏览器(在图中，内侧缩写为lui)。
图22示出用于推出处理的顺序。
期望在画面上显示外部应用窗口，并且用户从该状态按下主页键。
当设备服务层32检测到用户按下主页键时，设备服务层32将主页键的按下提供至架构31。
当架构31的事件发送/接收单元311接收到主页键的按下事件时，事件发送/接收单元311通知主页应用70该主页键按下事件。
当主页应用70接收到主页键按下事件时，主页应用70将所创建的主页画面的窗口id指定到架构31，并调用窗口显示(showwindow)。
当架构31的画面控制器312接收到窗口显示(showwindow)时，画面控制器312开始针对指定的窗口的显示处理，并且如果存在在相同层中显示的另一个不同的窗口，则画面控制器312开始针对该不同的窗口的不显示处理。如果不显示的窗口是外部应用窗口，则不显示在内侧作为虚拟或别名创建的div，并且不显示外部应用窗口。然后，画面控制器312通知配套应用74推出事件(windowpushedout)。此推出事件通知是不显示外部应用窗口的通知。因此，通过针对主页画面的显示命令不显示外部应用窗口。
当配套应用74接收到推出事件(windowpushedout)时，事件检测单元745检测推出事件，并且执行必要的处理，或更具体地，更新内部窗口状态管理信息。
图23是当用户按下主页画面上的外部应用按钮时已经存在被激活的外部应用并且外部应用不被显示的时序图。
当用户按下主页画面上的外部应用按钮时，主页应用70通知配套应用74针对被按下的按钮的启动命令及其伴随信息，即，外部应用id(清单信息中的subid)。
当配套应用74的外部应用激活指示单元743接收到启动命令时，外部应用激活指示单元743关于是否已经激活了指定的外部应用对外部应用进程管理单元744进行查询。如果指定的外部应用已被激活，则外部应用激活指示单元743从外部应用进程管理单元744获取与外部应用id相对应的窗口id，并向架构31发布外部应用显示请求(showwindow)。
当架构31的画面控制器312接收到外部应用显示请求(showwindow)时，画面控制器312开始针对指定的窗口的显示处理，并且如果存在在相同层中显示的另一个不同的窗口，则画面控制器312开始针对该不同的窗口的不显示处理(推出处理)。如果指定的窗口是外部应用窗口，则显示在内侧作为虚拟或别名创建的div，并显示外部应用窗口。然后，由层管理单元315指定的窗口被注册为最下层中的显示窗口。而且，画面控制器312确定是否显示内部浏览器窗口。即，画面控制器312对层管理单元315进行查询，检查每个层中显示的窗口，如果在除最下层以外的层中的内侧显示诸如横幅或故障的窗口，则显示内部浏览器，并且如果不是，则不显示内部浏览器。
图24是外部应用正常终止时的时序图。换句话说，图24是用户按下外部应用中的终止按钮时的时序图。
当用户按下外部应用的终止按钮时，外部应用将终止请求通知给设备服务层32。
当设备服务层32从外部应用接收到终止请求时，设备服务层32将终止请求通知给架构31。
当架构31的事件发送/接收单元311接收到包括进程id的终止请求时，事件发送/接收单元311指示窗口管理单元314将该进程id转换成窗口id。然后，事件发送/接收单元311向配套应用74发布窗口准备终止事件(windowprepareterminated)。
配套应用74的事件检测单元745从架构31接收窗口准备终止事件，并准备终止外部应用。即，准备包括清除浏览器的历史和缓存，并从认证应用中删除监听器。事件检测单元745将窗口终止准备完成通知给架构31。
当架构31的事件发送/接收单元311从配套应用74接收到窗口终止准备完成通知时，事件发送/接收单元311向设备服务层32发布进程终止请求，并删除所显示的层管理单元315的窗口。而且，事件发送/接收单元311从窗口管理单元314删除窗口信息。另外，事件发送/接收单元311向配套应用74发布窗口终止事件(windowterminated)。
当配套应用74的事件检测单元745从架构31接收到窗口终止事件时，事件检测单元745指示外部应用进程管理单元744删除关于进程的管理信息，并向架构31发布初始画面显示请求。
当架构31的应用管理单元316从配套应用74接收到初始画面显示请求时，应用管理单元316向主页应用70(初始激活应用)发布初始画面显示请求。因此，主页画面被显示为初始画面。或者，可以将除主页画面之外的画面设置为初始画面。
图25是外部应用异常终止时的时序图。换句话说，图25是当由于诸如内存不足或分段故障的某一原因而导致外部应用的进程异常终止时的时序图。用户可以查看操作中的外部应用，或者外部应用可以通过推出处理存在于背景中。
当操作系统(os)检测到外部应用的异常终止时，设备服务层32将外部应用异常终止通知给架构31。
当架构31的事件发送/接收单元311接收到包括进程id的外部应用异常终止通知时，事件发送/接收单元311指示窗口管理单元314将进程id转换成窗口id，并且如果正在显示外部应用窗口，则事件发送/接收单元311删除所显示的层管理单元315的窗口。而且，事件发送/接收单元311从窗口管理单元删除窗口信息，并向配套应用74发布窗口终止事件(windowterminated)。
当配套应用74的事件检测单元745从架构31接收到窗口终止事件时，事件检测单元745指示外部应用进程管理单元744删除关于进程的管理信息，并执行其它所需的后处理。另外，如果正在显示外部应用，则事件检测单元745向架构31发布初始画面显示请求。
当架构31的应用管理单元316接收到初始画面显示请求时，应用管理单元316向主页应用70(初始激活应用)发布初始画面显示请求。如果外部应用异常终止，则可以通过横幅或故障(而不是主页画面作为初始画面)进行故障通知。
图26是从外部进行终止的情况下的时序图。换句话说，图26是当用户从图像处理装置的网络ui进行外部应用使用禁止设置时的时序图。
用户进行设置用于禁止在网络ui上使用外部应用。网络ui将外部应用使用禁止设置通知给设备服务层32。
当配套应用74的事件检测单元745从设备服务层32接收到禁止外部应用使用设置的通知时，事件检测单元745指示外部应用进程管理单元744检查是否存在正在运行的外部应用。如果存在并且正在显示正在运行的外部应用，则事件检测单元745向架构31发布初始画面显示请求，并发布窗口终止事件(terminatewindow)。参数是窗口id。
当架构31的画面控制器312接收到窗口终止事件(terminatewindow)时，并且当正在显示外部应用时，画面控制器312删除所显示的层管理单元315的窗口，并从窗口管理单元314删除窗口信息。而且，画面控制器312向设备服务层32发布进程终止请求。设备服务层32响应于进程终止请求终止外部应用。另外，应用管理单元316从配套应用74接收初始画面显示请求，并向作为初始画面激活应用的主页应用70发布初始画面显示请求。因此，外部应用被终止，主页画面被显示为初始画面。
图27示意性地示出由配套应用74和架构31控制和管理的窗口的层结构。
当架构31从配套应用74接收到外部应用激活请求时，架构31创建公共信息和外部窗口管理信息作为窗口管理信息，并且创建div元素作为用于嵌入到内部浏览器的外部窗口管理信息。此div元素用作虚拟或别名，并且是透明的div元素。架构31请求设备服务层32激活外部应用。设备服务层32不显示外部应用窗口，并将外部应用窗口设置在低于内部浏览器的层的层中。内部浏览器按应用层、弹出层、横幅层、警报(低级)层、警报(高级)层和故障层的顺序进行管理。为了简化图，该图仅显示应用层和故障层。应用层具有作为虚拟或别名的嵌入在内部浏览器中的div元素。div元素是仅具有透明框架的窗口。
当架构31从配套应用74接收到外部应用显示请求时，架构31显示div元素，显示外部应用窗口，并且不显示内部浏览器。因此，用户可以在视觉上识别外部应用窗口，并操作外部应用。嵌入的div元素被显示，但为透明的，从而不会影响用户的视觉识别。同时，因为div元素被显示，所以架构31可以容易地识别出外部应用被显示。架构31负责作为除了内部应用的窗口(iframebase)之外的一种类型的窗口的外部浏览器，并因此可以与内部应用类似地无缝管理外部浏览器。如果由于发生某种异常而显示故障层，则架构31显示外部应用窗口，显示内部浏览器，并将故障显示在最上层。因此，可以以层叠在外部应用窗口上的方式来显示故障。可以以与故障类似的方式显示横幅。在这种情况下，如果系统中发生异常，则显示“故障”，并且如果作出关于与作业有关的信息的通知，则显示“横幅”。一般来说，故障具有比横幅的优先级或紧迫度更高的优先级或更高的紧迫度。因为横幅的要告知的功能和信息与故障的要告知的功能和信息不同，所以横幅或故障可能不会被选择性地显示，横幅和故障可能以层叠的方式显示。
当在外部应用窗口上以层叠的方式显示横幅时，设置在低于横幅层并对应于横幅显示区域的层中的外部应用窗口被隐藏并且未示出。横幅显示区域以外的系统不是异常的，外部应用窗口可以被示出，并且外部应用可能有必要被操作。在这种情况下，如上所述，用于管理外部应用窗口的虚拟透明div元素存在于应用层中。因此，除了横幅显示区域之外的外部应用窗口可以通过透明div元素在视觉上被识别。
图28a示出外部应用被激活并且显示外部应用窗口的状态。图28b示出在外部应用窗口上以层叠的方式显示横幅的状态。
在图28a中，不显示内部浏览器，显示外部应用窗口，并因此用户可以视觉上识别外部应用。虽然不显示内部浏览器，但是显示虚拟透明div元素。在这种状态下，如果发生某种异常，例如图像处理装置的盖子或门打开，则架构31的画面控制器312在画面的预定位置(例如，在画面的下部)处在外部应用窗口上以层叠的方式显示横幅90。横幅90的显示区域下的外部应用窗口的部分被隐藏并且未示出。然而，因为透明div元素存在于横幅90的显示区域以外的区域中，所以示出了外部应用窗口92。当用户在除了横幅90的显示区域以外的示出外部应用窗口92的区域中操作该外部应用时，用户根据逻辑配置操作透明div元素。架构31的事件检测单元745检测用户对div元素的操作，向设备服务层32通知由操作引起的事件，并且设备服务层32向外部应用通知操作事件。如上所述，即使当显示比外部应用窗口的层高的层时，只要在其间设置透明div元素，就可以操作外部应用。即，作为虚拟的透明div元素具有无缝地管理和控制内部应用窗口和外部应用窗口的功能，以及允许外部应用在横幅以层叠的方式显示在外部应用上的情况下在未因横幅而被隐藏的区域中进行操作的功能。
此示例性实施方式中的“组件”表示可逻辑上分离的软件的组件。组件可由一个或多个处理器执行。在此示例性实施方式中，使用javascript。然而，当然，可使用其它编程语言中的任一种。
而且，本发明不限于上述示例性实施方式，可按各种方式变形。下面描述变型。
第一变型
在示例性实施方式中，图像处理设备12的控制器(处理器)22执行表示层30中的架构31和各种应用50。然而，由于如图2所示表示层30和设备服务层32彼此分离，所以用于控制图像处理装置12的不同于图像处理装置12的个体装置(例如诸如智能电话或平板终端的移动终端中的处理器)可执行表示层30中的架构31和各种程序50。而且，图1中的操作单元26期望安装在移动终端上。在这种情况下，移动终端和图像处理装置12可统称为图像处理装置或图像处理系统。
第二变型
在示例性实施方式中，虽然示例性地描述了故障和横幅，但示例并不限于故障和横幅。如果窗口满足外部应用窗口能通过窗口查看的条件，只要窗口可能隐藏外部应用窗口并且窗口为半透明，则就可以应用要在高于应用层的层中显示的所有窗口中的任何一个。
出于例示和描述的目的提供了对本发明的示例性实施方式的前述描述。不意图穷举或将本发明限制为所公开的精确形式。明显地，很多修改和变形将对于本领域技术人员而言显而易见。选择和描述实施方式以便最优地解释本发明的原理和其实践应用，从而使本领域的其它技术人员能够理解本发明的各种实施方式、以及适合于所预期的特定使用的各种修改。意图由所附权利要求和它们的等同物定义本发明的范围。