本发明涉及图像形成设备。
背景技术：
具有诸如复印、打印和传真的功能的多功能机器的功能进一步扩展，因此要求有效地构造包括各种应用的整个系统。
日本未审查专利申请公开no.2012-248102描述了一种图像形成设备，该图像形成设备允许用户容易地识别应用列表画面上显示的图标的应用是否是在执行期间。该构造包括：画面信息存储单元，其存储列表画面信息，列表画面信息包括用于调用在其中注册了应用和所述应用的操作设置的宏的图标的图标位置、图标图像、应用识别信息和宏识别信息；画面控制单元，其获取关于工作状态从备用变成执行的应用的状态信息，输出识别信息并且发出画面更新请求；画面创建单元，如果接收到对基于列表画面信息而创建的应用列表画面的画面更新请求，则画面创建单元将由所获取的识别信息所指示的应用的图标的显示样式更新成与另一个应用的图标不同的显示样式；以及显示单元，其显示包括更新的图标的列表画面。
日本未审查专利申请公开no.2012-27662描述了在具有扩展功能的多功能机器中改进了用户的可操作性。该构造包括：布置信息存储单元，其存储图标布置信息，在图标布置信息中，标准应用、扩展应用、以及用于标识标准应用和扩展应用的应用识别信息与关于对应图标的坐标信息和关于图标的图像信息相关联；列表画面创建单元，其创建应用列表画面，在应用列表画面中，基于图标布置信息显示与标准应用和扩展应用对应的图标；显示单元，其显示所创建的应用列表创建画面；以及画面控制单元，其根据图标布置信息指定与被按下的图标对应的标准应用或扩展应用，并且向指定的标准应用或扩展应用做出操作画面显示请求。
在相关技术中，作为图像形成设备的系统，准备大的根应用并且设置将从相应应用使用的各种功能。所有的应用都取决于根应用。
另外，专门管理图像形成设备中的各种装置的状态的装置应用是独立存在的。基本上所有的应用都取决于装置应用。
另外，应用之间的公共实现在进行，并且应用也相互依赖。
因此，每当添加或删除应用时，需要在应用之间进行调节，并且同时，时常需要校正根应用。因此，可能不能容易地添加或删除应用。
技术实现要素：
本发明的目的是提供一种图像形成设备，该图像形成设备限制了应用之间的依赖并且允许容易地添加或删除应用。
根据本发明的第一方面，一种图像形成设备包括：架构上的应用，所述应用被分离成管理基础处理的核心逻辑部分、以及管理渲染处理的用户接口框架部分，并且所述应用在所述架构上操作；以及控制器，所述控制器执行所述应用和所述架构。所述核心逻辑部分用由所述架构所限定的应用编程接口来实现。所述接口包括指示通过所述应用所显示的窗口被终止的事前通知。
根据本发明的第二方面，基于第一方面中描述的图像形成设备，如果完成了对终止的准备，则接收所述事前通知的所述核心逻辑部分可响应于所述事前通知返回回调，并且如果所述架构接收到所述回调，则所述架构可终止所述窗口。
利用本发明的第一方面，应用之间的依赖可被限制，可容易地添加或删除应用，并且可增加终止通过应用所显示的窗口的处理的效率。
利用本发明的第二方面，进一步地，可在完成对删除的准备之后，终止窗口。
附图说明
将基于以下附图详细地描述本发明的示例性实施方式，其中：
图1是图像形成设备的功能框图；
图2是系统的逻辑配置图；
图3是示出主画面的示例的说明视图；
图4是应用的逻辑配置图；
图5是相关技术的系统的逻辑配置图；
图6是架构上的应用的配置图；
图7是示出应用的特定配置示例的说明性视图；
图8是示出应用列表的特定配置示例的说明性视图；
图9提供示出核心逻辑和ui框架的模式(pattern)的说明性视图；
图10a至图10c是ui和逻辑改变时的说明性视图；
图11a和图11b是均示出框架上的应用的模式的说明性视图；
图12是包括启动器(booter)和起动器(starter)的生命周期管理的系统配置示图；
图13是生命周期管理的时序图；
图14是示出从系统激活到主画面显示的时间的曲线图；
图15是窗口准备终止处理的操作时序图；以及
图16a至图16d是画面转变的说明性视图。
具体实施方式
以下，参照附图来描述本发明的示例性实施方式。
系统总体构造
图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与互联网连接，或者可包括以太网(ethernet，注册商标)和/或wi-fi(注册商标)。
程序的逻辑配置
图2示出由控制器22执行的系统的逻辑配置。系统被大致分离成两层，所述两层包括呈现层30和装置服务层32。
呈现层30是在其中实现各种应用的层，并且包括架构31和各种应用。架构31是允许能在计算机系统上操作javascript(注册商标)应用的执行环境软件群组。更具体地，javascript在网络浏览器上执行，并且基础框架和ui框架作为超文本标记语言(html)的iframe被加载。另外，这样的应用是用由架构31所提供的应用编程接口实现的javascript软件。架构31管理各种应用的生命周期。也就是说，对于各种应用中的每个，架构31创建基础框架，读取应用的核心逻辑，并且向核心逻辑给出初始化指令。另外，在去激活系统时，架构31向各种应用中的每个的核心逻辑给出最终化指令，并且删除基础框架。随后更详细地描述各种应用中的每个的核心逻辑和生命周期管理。
装置服务层32是管理各种硬件装置的层。硬件装置包括例如上述图像形成单元28的打印模块。
图3示出在图像形成设备12的操作单元26上显示的画面(主画面)的示例。主画面包括在其上显示的图标。这些图标包括复印按钮34、id卡复印(id复印)按钮36、扫描按钮38、传真按钮40、我的复印按钮42、网络应用(网络应用1)按钮44和简单复印按钮46。当用户触摸并选择多个按钮中的一个时，激活分配给该按钮的应用，并且画面转变为应用画面。用户可认识到按钮对应于应用。
每个应用是由如上所述的架构31所提供的应用编程接口实现的javascript软件，并且是直接向用户提供功能的部件。每个应用具有由架构31所限定的公共配置。另外，每个应用被配置成具有相对于另一个应用的低链接度。应用包括通过用户接口(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＝真，则选择显示；以及
如果islaunchable＝假，则选择不显示。
用该配置，核心逻辑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的每个应用被分配特定配套应用。每个配套应用管理对应的功能。每个配套应用还包括核心逻辑52，与std应用类似。由于清单文件56包括应用的类型，因此可将每个应用的内部实现与另一个应用的内部实现区分开。
另外，清单文件56-2中的“islaunchable”是如上所述确定图标是否在主画面上显示的属性信息。在该图中，显示如下。
islaunchable＝真
这代表显示复印按钮。
由于应用被分离成核心逻辑52和ui框架54，因此应用列表描述了其间的对应。
针对每个应用创建清单文件56。因此，期望设置代表每个应用的类型的标识符和类型的唯一标识符。例如，复印应用的清单文件具有如下的标识符。
type(类型)：std
id：copy(复印)
在这些标识符中，type是代表类型(预先安装的应用)的标识符，并且id是唯一标识符。
另外，清单文件56包括在激活时所需的信息和将主画面渲染为静态信息所需的信息。在激活时所需的信息是关于核心逻辑52的存储位置信息和关于ui框架54的存储位置信息。架构31参照核心逻辑52的存储位置信息来加载核心逻辑52。另外，如有需要，核心逻辑52参照关于ui框架54的存储位置信息来加载ui框架54。
渲染主画面所需的信息是关于图标按钮的存储位置信息和按钮的显示次序。
装置服务层中的应用管理部件参考清单文件56并且使用清单文件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)和图9中的部分(c)中，通过设置ui框架54的清单文件56-2的islaunchable属性值，确定在主画面上是否实际显示按钮。例如，在图9中的部分(c)中，在存在共享公共核心逻辑52的第一ui框架54和第二ui框架54，第一ui框架54的清单文件是islaunchable＝真，并且第二ui框架54的清单文件是islaunchable＝假的情况下，前一个被显示为按钮，而后一个没有被显示。
作为应用的执行结构，核心逻辑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_for_xxx替换由copy和后面所指示的部分。
图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没有相互分离，并且处理和画面渲染混合，从而导致结构复杂。另外，不存在应用的公共编程接口，并且每个应用自由地公布编程接口并且自由地参考编程接口。相比之下，在本示例性实施方式中，架构31限定应用编程接口，并且每个应用的核心逻辑52必须用应用编程接口来实现。因此，本示例性实施方式中的应用编程接口的方向不同于相关技术的方向。另外，除了架构31和每个应用之间的通信之外，可通过由架构31所提供的编程接口公布功能和应用编程接口参考功能来实现应用之间的通信编程接口。
理论上，多个应用可共享公共ui框架54并且可分别地具有单个核心逻辑52。然而，在这种情况下，就架构31的观点而言，结构可能是复杂的，因此在本示例性实施方式中没有特别地描述这种情况。当然，不是必须旨在排除该模式。
应用的生命周期管理
图12示出当架构31针对每个应用执行生命周期管理时的基本配置。在这种情况下，架构31是应用的执行环境。
在呈现层中除了存在架构31和各种应用50之外，还存在启动器60和起动器应用64。另外，在装置服务层中存在应用管理部件62。
启动器60是执行整个呈现层的激活/去激活管理的部件。由启动器60来初始化和激活架构31。
应用管理部件62基于各种应用50的清单文件56向架构31提供应用列表。
起动器应用64是用由架构31所限定的起动器编程接口70实现的应用。起动器应用64只是该系统中存在的一个应用，并且当所有应用50的初始化完成时，从架构31调用起动器应用64。
各种应用50包括复印应用、id复印应用、传真应用等，并且包括如上所述的核心逻辑52。各种应用50的核心逻辑52均用由架构31所限定的应用编程接口72来实现。
具体地，每个应用50中实现的应用编程接口如下。
·初始化处理(initialize)
·最终化处理(finalize)
·窗口推出处理(windowpushedout)
·窗口准备暴露处理(windowprepareexposed)
·窗口准备终止处理(windowprepareterminated)
针对这些事件用处理程序(handler)来实现每个应用50。
架构31包括用于启用方法的公布/调用的javascript部件(被称为通信控制部件)和各种应用50的核心逻辑52之间的事件的公布/购买/发行。方法可被定义为采用所期望参数并且返回所期望的返回值。以应用为基础来独立地管理所公布的方法。调用方法的应用可通过回调来检查方法的处理的完成。另外，可由每个应用用所期望的数据来定义事件。以应用为基础来独立地管理所公布的事件。更具体地，通信控制部件通过核心逻辑52来启用方法的公布和调用，启用监听方的事件和注册的定义和发行，通过“on”来公布方法，并且通过“off”来停止方法的公布。所公布的方法能够通过调用(call)进行调用。例如，第一应用向架构31针对公布设置特定应用编程接口“on”，并且第二应用向架构31针对第一应用的所公布的编程接口进行“调用”。
图13是架构31对各种应用中的每个进行的生命周期管理的时序图。
当启动器60激活架构31时，架构31从装置服务层中的应用管理部件62请求应用列表，并且从应用管理部件62获取应用列表。
当架构31获取应用列表时，架构31根据该列表以应用为基础来创建基础框架，并且加载包括起动器应用64的各种应用50(加载阶段)。也就是说，架构31读取每个应用的核心逻辑52。具体地，架构31参照在清单文件56中限定的关于核心逻辑52的存储位置信息来加载核心逻辑52。基础框架是用于执行每个应用的核心逻辑52的框架，并且没有显示该框架。期望地确定相应应用的核心逻辑52的加载次序并且此次序不受特别限制。在所有应用已经完成了应用编程接口实现的注册的时间点，该阶段进行到下一个阶段。
要注意，在应用编程接口实现的注册处理之前公布每个应用的方法和事件。
接下来，架构31通过应用编程接口向每个应用给出初始化指令(初始化阶段)。具体地，架构31向每个应用发行“应用(app)”事件和“初始化(initialize)”方法。在响应于初始化指令而在处理完成之后所有应用回调的时间点，架构31将初始化处理的完成通知启动器60，并且该阶段进行到下一个阶段。还可期望地确定相应应用的初始化次序。在该初始化处理中，每个应用执行从装置服务层的获取数据。
然后，启动器60向架构31给出通过应用来提供功能的起动指令，并且架构31响应于所给出的指令而向起动器应用64给出起动指令(起动阶段)。起动器应用64获取关于在装置服务层中管理的初始激活应用的信息，并且显示初始画面。在起动器应用64响应于起动指令在处理完成之后进行回调的时间点，完成该阶段。
在系统去激活时，架构31向每个应用的核心逻辑52给出最终化的指令。另外，架构31删除每个应用的基础框架。
在加载阶段中，没有特定限制的次序来读取相应应用的核心逻辑52。因此，即使当添加应用时，加载阶段也不一定改变。另外，在初始化阶段中，所有应用被初始化。因此，确信调用其它应用，并且不需要进行单独的同步。如上所述，由于不再需要应用之间的同步并且只加载大小相对小的核心逻辑52，因此系统激活时间和应用激活时间减少。
如果每个应用独立地公布应用编程接口，则激活、预初始化处理、初始化处理、后初始化处理、停止、暂停等在应用的基础上是不同的。在每个应用的初始化级中产生差异，并且能够调用应用的定时也改变。特别地，需要在调用应用之前，检查是否能够调用主题应用。控制可能是复杂的。相比之下，在示例性实施方式中，如上所述可减少初始化时间，并且初始化之后的主画面的激活时间可减少。
图14示出根据相关技术和示例性实施方式的从系统激活到主画面显示的时间。
在相关技术中，除了单纯初始化时间之外，应用初始化时间还需要同步，并且类似地，除了单纯激活时间之外，主画面的激活时间也需要同步。相比之下，在本示例性实施方式中，单纯初始化时间可减少，并且可去除同步。另外，对于主画面激活时间，可提供类似的效果。在相关技术中，如果应用相互依赖，则需要进行调节以防止产生死锁。然而，在本示例性实施方式中，不存在这样的依赖，因此不再需要死锁调节。
进一步详细描述了每个应用50中实现的应用编程接口中包括的窗口准备终止处理(windowprepareterminated)。
窗口准备终止处理(windowprepareterminated)是做出指示应用50的窗口将在事前被终止(删除)的通知的应用编程接口。
在相关技术中，应用50不终止正显示的窗口，并且如果例如存储器容量不充足，则应用50显示诸如“请关闭应用”的消息。
相比之下，在本示例性实施方式中，在应用50的窗口被终止(删除)的情况下，架构31将事前终止(删除)通知给应用50。因此，既不需要应用50显示诸如“请关闭应用”的消息，也不需要应用50检查自身窗口是否将被终止(删除对象)。即使当添加新应用50时，也不需要改变架构31或其它应用。
另外，由于可确定将终止的窗口并且可根据架构31的情形确定将被保持的窗口的数量，因此可激活数量比相关技术中的数量大的应用。
图15示出在架构31和应用50之间使用窗口准备终止处理(windowprepareterminated)的操作。应用1和应用2被示出为应用50。提供以下示例：可创建两个窗口，并且鉴于对系统存储器容量的限制而保持一个窗口。
在加载阶段和初始化阶段结束之后，应用1向架构31请求createwindow，并且架构31响应于该请求返回窗口id(画面编号)。例如，架构31将画面编号1(下文中，被称为g1)作为id返回。要注意，createwindow对象的属性包括统一资源定位符(url)、类型等。url是窗口中将被读取的资源的url，并且类型(type)是将被创建的窗口的类型。可被指定的窗口的类型包括主应用画面、正常应用窗口、横幅(banner)窗口和弹出窗口。应用1通过使用接收到的画面编号来向架构31请求显示请求showwindow。架构31响应于该请求显示g1。类似地，应用2向架构31请求createwindow，并且架构31响应于该请求返回画面编号2(下文中，被称为g2)。应用2通过使用接收到的画面编号来向架构31请求显示请求showwindow。架构31响应于该请求显示g2。
当显示g2时，g1变成非显示状态。由于将被保持的窗口是1，因此架构31将终止(删除)在非显示状态下的g1。在这种情况下，架构31没有立即终止(删除)g1，而是事前将windowprepareterminated通知给作为应用g1的应用1。接收到该通知的应用1在终止(删除)之前执行工作。如果应用1变成没有任何问题就可终止(删除)应用1的状态，则应用1向架构31返回响应于该通知的回调。如果架构31从应用1接收到回调，则架构31终止(删除)g1。
当多个窗口处于非显示状态时，架构31可事前将windowprepareterminated通知给底部的应用50。
图16a至图16d示出显示画面的转变状态。图16a示出初始化阶段结束并且显示初始画面(默认画面)的状态。默认画面被指示为g0。
图16b示出以下状态：向应用1请求showwindow，并且架构31响应于该请求在画面上显示应用1的画面g1。
图16c示出以下状态：向应用2请求showwindow，并且架构31响应于该请求在画面上显示应用2的画面g2。由于g2显示在画面的顶部，因此g1被推出并且改变为非显示状态。在这种情况下，架构31通过使用windowprepareterminated事前将架构31将终止(删除)g1通知给g1的应用1。
图16d示出从接收通知的应用1接收回调的状态。用虚线来指示g1将被终止(删除)的情形。由于g1被终止(删除)，因此产生用于一个窗口的容量。例如，另一个应用3可重新创建窗口。
如上所述，在本示例性实施方式中，应用被分离成核心逻辑52和ui框架54，在核心逻辑52中实现由架构31所限定的应用编程接口，核心逻辑52通过架构31与另一个应用的核心逻辑52通信，并且ui框架54只与应用的核心逻辑52通信。因此，每个应用具有由架构31所限定的公共配置，并且可被配置成与另一个应用具有低链接度。可以容易地添加或删除应用。
另外，应用50可通过来自架构31的通知事前弄清自身窗口将被终止(删除)。因此，可在删除之前完成工作。
本示例性实施方式中的“部件”代表可逻辑上被分离的软件的部件。可由一个或多个处理器来执行部件。在本本示例性实施方式中，使用javascript。然而，当然，可使用其它编程语言中的任一种。
另外，本发明不限于上述示例性实施方式，并且可按各种方式进行修改。以下，描述修改形式。
修改形式
在示例性实施方式中，图像形成设备12的控制器(处理器)22执行呈现层30中的架构31和各种应用50。然而，由于如图2中所示呈现层30和装置服务层32相互分离，因此与图像形成设备12不同的用于控制图像形成设备12的单个设备(例如，诸如智能电话或平板终端的移动终端中的处理器)可执行呈现层30中的架构31和各种应用50。另外，图1中的操作单元26期望被安装在移动终端上。在这种情况下，移动终端和图像形成设备12可被统称为图像形成设备或图像形成系统。
出于例示和描述的目的已经提供了以上对本发明的示例性实施方式的描述。这不旨在是穷尽的或者将本发明限于所公开的精确形式。显而易见，对于本领域的技术人员而言，许多修改和变型将是清楚的。选择实施方式并进行了描述，以最佳地说明本发明的原理及其实际应用，由此使本领域的其它技术人员能够理解本发明的各种实施方式和适于预料中的特定使用的各种修改。本发明的范围旨在由以下权利要求书及其等同物来限定。