JP2018055183A

JP2018055183A - 画像形成装置及びプログラム

Info

Publication number: JP2018055183A
Application number: JP2016187283A
Authority: JP
Inventors: 道村　唯夫; Tadao Michimura; 唯夫道村; 雅紀佐竹; Masaki Satake; 森田　雅夫; Masao Morita; 雅夫森田
Original assignee: Fuji Xerox Co Ltd
Current assignee: Fujifilm Business Innovation Corp
Priority date: 2016-09-26
Filing date: 2016-09-26
Publication date: 2018-04-05
Anticipated expiration: 2036-09-26
Also published as: JP6876232B2; US20180091679A1; US10097717B2; CN107870767A; CN107870767B

Abstract

【課題】アプリケーション相互の依存関係を抑制し、アプリケーションの追加や削除を容易化し得る画像形成装置及びプログラムを提供する。【解決手段】画像形成装置は、基本処理を担うコアロジック部、描画処理を担うＵＩフレーム部、及びアプリケーションの静的情報を規定するマニフェストファイル部に分離され、フレームワーク上で動作するアプリケーションと、アプリケーション及びフレームワークを実行する制御手段を備える。コアロジック部はフレームワークが定義するインターフェイス（Ｉ／Ｆ）を実装する。インターフェイスには、アプリケーションが表示しているウィンドウが削除されたことの通知が含まれる。【選択図】図１５

Description

本発明は、画像形成装置及びプログラムに関する。

コピー、プリンタ、ファックス等の機能を備える複合機は、さらに多機能化しており、各種のアプリケーション（アプリ）を含む全体システムを効率的に構築することが要求されている。

特許文献１には、アプリ一覧画面に表示されるアイコンのアプリが実行中であるか否かを、ユーザが容易に把握できるようにする画像形成装置が記載されている。アプリケーション及びアプリケーションの動作設定を登録したマクロを呼び出すためのアイコンに対し、アイコンの位置、アイコン画像、アプリケーションの識別情報、マクロの識別情報を含む一覧画面情報を記憶する画面情報記憶手段と、ジョブの状態が待機から実行に変化したアプリケーションの状態情報を取得し、識別情報を出力するとともに画面更新要求を行う画面制御手段と、一覧画面情報に基づき作成したアプリケーションの一覧画面に対して画面更新要求を受けた場合、取得された識別情報が示すアプリケーションのアイコンの表示形態を、他のアプリケーションのアイコンとは異なる表示形態に更新する画面作成手段と、更新されたアイコンを含む一覧画面を表示する表示手段を備えることが記載されている。

特許文献２には、多機能化する複合機において、ユーザの操作性を向上させることが記載されている。標準アプリケーションと、拡張アプリケーションと、標準及び拡張アプリケーションを識別するアプリ識別情報を、それぞれのアイコンの座標情報及びアイコンの画像情報に対応付けたアイコン配置情報を記憶する配置情報記憶手段と、アイコン配置情報に基づき、標準及び拡張アプリケーションに対応するアイコンが表示されるアプリ一覧画面を作成する一覧画面作成手段と、作成された前記アプリ一覧作成画面を表示する表示手段と、押下されたアイコンに対応する標準又は拡張アプリケーションをアイコン配置情報から特定し、特定された標準又は拡張アプリケーションに対し、操作画面の表示要求を行う画面制御手段を備えることが記載されている。

特開２０１２−２４８１０２号公報特開２０１２−２７６６２号公報

ところで、従来においては、画像形成装置のシステムとして、巨大なルートアプリケーションを用意して各アプリケーションから利用される種々の機能を提供しており、全てのアプリケーションはこのルートアプリケーションに依存している。

また、画像形成装置の各種のデバイス状態を専門に扱うデバイスアプリケーションも別個に存在しており、ほぼ全てのアプリケーションがこのデバイスアプリケーションに依存している。

さらに、アプリケーション間での実装共通化が進んでおり、アプリケーション間での依存関係も生じている。

従って、アプリケーションを追加する場合や削除する場合でも、その都度アプリケーション間で調整が必要となり、これと同時に、ルートアプリケーションの修正も常に必要となることから、容易にアプリケーションの追加や削除ができない問題があった。

本発明の目的は、アプリケーション相互の依存関係を抑制し、アプリケーションの追加や削除を容易化し得る画像形成装置及びプログラムを提供することにある。

請求項１に記載の発明は、基本処理を担うコアロジック部、及び描画処理を担うＵＩフレーム部に分離され、フレームワーク上で動作するアプリケーションと、アプリケーション及びフレームワークを実行する制御手段とを備え、コアロジック部はフレームワークが定義するインターフェイス（Ｉ／Ｆ）を実装し、インターフェイス（Ｉ／Ｆ）には、アプリケーションが表示しているウィンドウが削除されたことの通知が含まれる画像形成装置である。

請求項２に記載の発明は、ウィンドウが削除されたことの通知には、プロパティとして削除理由が含まれる請求項１に記載の画面形成装置である。

請求項３に記載の発明は、画像形成装置を制御するプロセッサに実行させるプログラムであって、基本処理を担うコアロジック部と、描画処理を担うＵＩフレーム部に分離されており、コアロジック部は、フレームワークが定義するインターフェイス（Ｉ／Ｆ）を実装し、インターフェイス（Ｉ／Ｆ）には、アプリケーションが表示しているウィンドウが削除されたことの通知が含まれるプログラムである。

請求項１，３に記載の発明によれば、アプリケーション相互の依存関係を抑制し、アプリケーションの追加や削除を容易化できるとともに、アプリケーションが表示しているウィンドウを削除する処理を効率化できる。

請求項２に記載の発明によれば、さらに、削除理由に応じた事後処理が可能となる。

画像形成装置の機能ブロック図である。システムの論理構成図である。ホーム画面の一例を示す説明図である。アプリケーションの論理構成図である。従来システムの論理構成図である。フレームワーク上のアプリケーションの構成図である。アプリケーションの具体的構成例を示す説明図である。アプリケーションリストの具体的構成例を示す説明図である。コアロジックとＵＩフレームのパターンを示す説明図である。ＵＩ及びロジック変更時の説明図である。フレームワーク上のアプリケーションのパターンを示す説明図である。ブータ及びスタータを含むライフサイクル管理のシステム構成図である。ライフサイクル管理のフローチャートである。システム起動からホーム画面が表示されるまでの時間を示すグラフ図である。ウィンドウ削除処理の動作フローチャートである。画面遷移説明図である。

以下、図面に基づき本発明の実施形態について説明する。

＜システム全体構成＞
図１は、本実施形態における画像形成装置を含む画像形成システムの構成ブロック図である。画像形成システムは、端末装置１０及び画像形成装置１２を備える。端末装置１０と画像形成装置１２は、通信手段１４を介して接続される。通信手段１４は、例えばＬＡＮ（ローカルエリアネットワーク）等のデータ通信ネットワークが用いられる。

端末装置１０は、通信手段１４を介して画像形成装置１２に接続され、利用者の指示に従い、文書の印刷命令を含む印刷ジョブ等を送信する。

画像形成装置１２は、ＲＯＭ１６、ＲＡＭ１８、ＨＤＤ２０、１つ又は複数のＣＰＵで構成される制御部２２、入出力インターフェイスＩ／Ｆ２４、タッチパネル等の操作部２６、画像形成部２８を備える。

１又は複数のＣＰＵで構成される制御部２２は、ＲＯＭ１６に記憶された処理プログラムに従い、入出力インターフェイスＩ／Ｆ２４を介して端末装置１０から印刷ジョブ命令等を受け付け、ＰＤＬデータを解釈して中間データを生成し、生成した中間データからさらに描画データ（ラスターデータ）を生成する。また、制御部２２は、操作部２６から受け付けたコピー（Copy）、スキャン（Scan）、ファックス(Fax)等の各種命令を実行する。

画像形成部２８は、プリントモジュール、スキャナモジュール、ファックスモジュール、用紙給紙モジュール、原稿給紙モジュール、及び画像処理アクセラレータを備える。

プリントモジュールは、画像を用紙に出力する機能を有するモジュールである。例えば、公知のインクジェット方式の構成を備え、描画データを用紙に印刷する。ノズル等から液体あるいは溶融固体インクを吐出し、紙、フィルム等に記録を行う。インクを吐出する方法には、静電誘引力を利用してインクを吐出させるドロップオンデマンド方式（圧力パルス方式）、高熱により気泡を形成・成長させることで生じる圧力を利用してインクを吐出させる熱インクジェット方式等がある。記録ヘッドは、例えば、シアンインクを吐出するヘッド、マゼンタインクを吐出するヘッド、イエローインクを吐出するヘッド、ブラックインクを吐出するヘッドを備え、各ヘッドが用紙の幅と少なくとも同等の幅を有するラインヘッドが用いられる。記録ヘッドにより各色のインク滴を中間転写体に吐出して記録し、その後に用紙に転写して印刷する。

スキャナモジュールは、用紙から画像を読み取って電子データに変換するモジュールである。

ファックス(Fax)モジュールは、モデムやファックス用画像処理モジュールを備え、ファックス機能を実行するモジュールである。

用紙給紙モジュールは、用紙トレイからプリントモジュールに用紙を搬送するモジュールである。

原稿給紙モジュールは、原稿トレイからスキャナモジュールに用紙を搬送するモジュールである。

画像処理アクセラレータは、スキャナモジュール等と連動して圧縮／伸長処理を行うモジュールである。この画像処理アクセラレータは必須ではなく、付加的モジュールとしてもよい。

なお、画像形成装置１２は、これら以外にも、用紙のパンチやソート等を行うフィニッシャ、ＵＳＢ、ＩＣカードリーダ等から構成され利用者の認証を行う認証部、課金部、人感センサや顔カメラ等を備えていてもよい。

また、画像形成装置１２は、通信手段１４を介してインターネットに接続されていてもよく、イーサネット（登録商標）やＷｉ−Ｆｉ（登録商標）を備えていてもよい。

＜プログラムの論理構成＞
図２は、制御部２２で実行されるシステムの論理構成を示す。システムは、大別して、プレゼンテーション層３０とデバイスサービス層３２の２つの層に分離される。

プレゼンテーション層３０は、各種アプリケーションを実装する層であり、フレームワーク３１と、各種アプリケーションを含む。フレームワーク３１は、コンピュータシステム上でJavaScript（登録商標）アプリケーションを動かせるようにする実行環境ソフトウェア群である。より具体的には、JavaScriptは、Ｗｅｂブラウザ上で実行され、Base FrameとUI FrameはHTMLのiframeとしてロードする。また、アプリケーションは、フレームワーク３１が提供するＩ／Ｆを実装したJavaScriptソフトウェアである。フレームワーク３１は、各種アプリケーションのライフサイクルを管理する。すなわち、フレームワーク３１は、各種アプリケーションに対して、ベースフレーム（Base Frame）を作成して各種アプリケーションのコアロジック（Core Logic）を読み込み、コアロジック(Core Logic)に対してイニシャライズ（初期化）を指示する。また、システム終了時には、各種アプリケーションのコアロジック（Core Logic）に対してファイナライズを指示し、ベースフレーム（Base Frame）を破棄する。各種アプリケーションのコアロジック（Core Logic）及びライフサイクル管理については、さらに後述する。

デバイスサービス層３２は、各種ハードウェアデバイスを管理する層であり、各種ハードウェアデバイスには、上記の画像形成部２８のプリントモジュール等が含まれる。

図３は、画像形成装置１２の操作部２６に表示される画面（ホーム画面）の一例を示す。ホーム画面には、コピー（Copy）ボタン３４、ＩＤカードコピー（ID Copy）ボタン３６、スキャン(Scan)ボタン３８、ファックス(Fax)ボタン４０、マイコピー(MyCopy)ボタン４２、ウェブアプリ(Web App1)ボタン４４、簡単コピーボタン４６の各アイコンが表示される。利用者がいずれかのボタンにタッチして選択すると、各ボタンに割り当てられたアプリケーションが起動し、アプリケーションの画面に遷移する。利用者は、各ボタンに各アプリケーションが対応していると認識し得る。

アプリケーションは、既述したように、フレームワーク３１が提供するＩ／Ｆを実装したJavaScriptソフトウェアであり、利用者に対して直接的に機能を提供するコンポーネントである。フレームワーク３１によって定義された共通の構成を有する。また、各アプリケーションは、他のアプリケーションとの間の結合度合いが低くなるように構成される。アプリケーションには、ユーザインターフェイス(UI)を介して利用者と協働して動作するものと、利用者と協働しないものがある。利用者と協働するアプリケーションは、主体的にプレゼンテーション層３０を通じて表示や入力を実行する。

なお、図には利用者がログインするためのログイン(Login)ボタン４８も表示されているが、このボタンにもアプリケーションが対応している。

＜アプリケーションの実装構造＞
図４は、アプリケーションの構造を示す。アプリケーション５０は、大別して、３つのコンポーネントに分離される。すなわち、コアロジック(Core Logic)５２、ＵＩフレーム(UI Frame)５４、及びマニフェストファイル(Manifest file)５６に分離される。ここで、「分離」とは、物理的に分離されることを意味するものではなく、論理的に分離されることを意味する。

コアロジック(Core Logic)５２は、アプリケーションとしての基本処理（基本的な振る舞いやアプリ間連携）を行うコンポーネントであり、各アプリケーションに必ず存在する。コアロジック(Core Logic)は、フレームワーク３１によって定義されたＩ／Ｆを提供する。

ＵＩフレーム(UI Frame)５４は、アプリケーションとして描画表示するためのコンポーネントであり、具体的には表示ウィンドウとして管理される。

マニフェストファイル５６は、各アプリケーションの静的な情報のリストである。静的な情報は、アプリケーションの識別子（ＩＤ）、表示名称、アイコン画像、バージョン、作成日等である。マニフェストファイル５６には、コアロジック用マニフェストファイル５６−１と、ＵＩフレーム用マニフェストファイル５６−２がある。マニフェストファイル５６が記述する情報の一つは、isLaunchable属性である。この属性により、ホーム画面上にアイコン（ボタン）として表示されるか否かが決定され、
isLaunchable=trueで表示
isLaunchable=falseで非表示
となる。

このような構成において、コアロジック(Core Logic)５２とＵＩフレーム(UI Frame)５４との間の通信のルールは以下の通りである。
（１）コアロジック(Core Logic)５２は、他のコアロジック(Core Logic)５２と通信する。
（２）ＵＩフレーム(UI Frame)５４は、コアロジック(Core Logic)５２のみと通信する。

従って、ＵＩフレーム(UI Frame)５４は、他のＵＩフレーム(UI Frame)５４と通信することはない。

図５は、従来のプログラム構成を示す。従来においては、巨大なルートアプリケーション(RootApp)６０を用意して各アプリケーションから利用される種々の機能を提供しており、全てのアプリケーションはこのルートアプリケーション６０に依存している。また、各種のデバイス状態を専門に扱うデバイスアプリケーション(Device App)６２も別個に存在しており、ほぼ全てのアプリケーションがこのデバイスアプリケーション６２に依存している。さらに、アプリケーション間での実装共通化が進んでおり、アプリケーション間での依存関係も生じている。従って、アプリケーションを追加する場合や削除する場合でも、その都度アプリケーション間で調整が必要となり、また、ルートアプリケーション６０の修正も常に必要となることから、容易にアプリケーションの追加や削除ができない。

他方、図６は、本実施形態のプログラム構成を示す。各アプリケーションは、コアロジック(Core Logic)５２、ＵＩフレーム(UI Frame)５４、及びマニフェストファイル(Manifest file)５６に分離されており、各アプリケーションのコアロジック(Core Logic)５２がフレームワーク３１に接続され、各アプリケーションのＵＩフレーム(UI Frame)５４は当該アプリケーションのコアロジック(Core Logic)５２に接続される構成である。

例えば、コピー(Copy)アプリケーションを例にとると、コピーアプリケーションは、コアロジック(Core Logic)５２、ＵＩフレーム(UI Frame)５４、及びマニフェストファイル(Manifest file)５６に分離され、そのコアロジック(Core Logic)５２はフレームワーク３１に接続され、そのＵＩフレーム(UI Frame)５４はそのコアロジック(Core Logic)５２に接続される。各アプリケーション間の結合は限定的であって従来のように依存関係になく、各アプリケーション間の連携は、コアロジック(Core Logic)５２を介してフレームワーク３１により実行される。各アプリケーションのコアロジック(Core Logic)５２は、フレームワーク３１によって定義されたＩ／Ｆを提供するから、新たにアプリケーションを追加する場合でも、フレームワーク３１によって定義されたＩ／Ｆを提供することで容易に追加できる。また、アプリケーション間の結合も限定的であるため、アプリケーションの削除も容易である。

図７は、コピーアプリケーションの例を示す。図において、baseframe.htmlがコアロジック(Core Logic)５２であり、base_manifest.jsonがコアロジック(Core Logic)５２のマニフェストファイル５６−１である。また、uiframe.htmlがＵＩフレーム(UI Frame)５４であり、app_manifest.jsonがＵＩフレーム(UI Frame)５４のマニフェストファイル５６−２である。

図８は、アプリケーションリストの例を示す。図において、”base”がコアロジック(Core Logic)５２のマニフェストファイル５６−１を示し、”app”がＵＩフレーム(UI Frame)５４のマニフェストファイル５６−２を示す。マニフェストファイル５６−２の中の”type”は、アプリケーションの種類を示す。アプリケーションの種類については以下の通りである。

すなわち、アプリケーションには、
ＳＴＤ：標準搭載されるアプリケーション
ＯＴ：標準搭載されるアプリケーション（ＳＴＤ）のショートカット
ＥＸＴ：追加可能なアプリケーション（その１）
ＣＳ：追加可能なアプリケーション（その２）
の４つの種類がある。標準搭載されるアプリケーションは、図３に示されるコピー(Copy)やスキャン(Scan)、ファックス(Fax)等に対応するアプリケーションである。また、ＯＴ、ＥＸＴ、ＣＳの各アプリケーションには、それぞれ特別なコンパニオンアプリケーションが割り当てられ、各コンパニオンアプリケーションがそれぞれの機能を担う。各コンパニオンアプリケーションも、ＳＴＤアプリケーションと同様にコアロジック(Core Logic)５２を有する。マニフェストファイル５６にアプリケーションの種類を含めることで、各アプリケーションの内部実装を互いに区別することができる。

また、マニフェストファイル５６−２の中の”isLaunchable”は既述したように、アイコンをホーム画面上に表示するか否かを決定する属性情報である。図では、
isLaunchable=true
となっており、これはコピーのボタンを表示することを意味する。

アプリケーションは、コアロジック(Core Logic)５２とＵＩフレーム(UI frame)５４に分離されているから、アプリケーションリストは、両者の対応関係が記述されていると言うことができる。

マニフェストファイル５６は、アプリケーション毎に作成されるから、アプリケーション毎の種別を示す識別子と、種別内で一意の識別子を設定することが望ましい。例えば、コピーアプリケーションのマニフェストファイルには、
type:STD
ID:copy
等である。typeは種別を示す識別子であり（標準搭載されるアプリケーション）、IDは一意の識別子である。

さらに、マニフェストファイル５６には、静的情報として、起動時に必要とされる情報及びホーム画面描画に必要な情報も含まれる。起動時に必要とされる情報は、コアロジック(Core Logic)５２の格納先情報及びＵＩフレーム(UI frame)５４の格納先情報であり、フレームワーク３１はコアロジック(Core Logic)５２の格納先情報を参照してコアロジック(Core Logic)５２をロードする。また、コアロジック(Core Logic)５２は、ＵＩフレーム(UI frame)５４の格納先情報を参照してＵＩフレーム(UI frame)５４を必要に応じてロードする。ホーム画面描画に必要とされる情報は、アイコンボタン格納先情報及びボタンの表示順序である。

マニフェストファイル５６は、後述するようにデバイスサービス層のアプリケーション管理コンポーネントで参照され、アプリケーションリストの作成に供される。

図９は、アプリケーションの実装構造のパターンを示す。

図９（ａ）は、コアロジック(Core Logic)５２は存在するが、ＵＩフレーム(UI Frame)５４が存在しないパターンである。標準搭載されるアプリケーションではなく、コンパニオンアプリケーション等が該当する。図９（ｄ）は、図９（ａ）に対応するアプリケーションリストである。

図９（ｂ）は、コアロジック(Core Logic)５２及びＵＩフレーム(UI frame)５４が存在するパターンであり、それぞれ１対１に対応するパターンである。図９（ｅ）は、図９（ｂ）に対応するアプリケーションリストである。

他方、図９（ｃ）は、コアロジック(Core Logic)５２及びＵＩフレーム(UI frame)５４が存在するものの、複数のＵＩフレーム(UI Frame)５４が共通のコアロジック(Core Logic)５２を有する場合である。ＵＩフレーム(UI Frame)５４はホーム画面にボタンを表示する際の表示形態を決定するが、複数のボタンを表示する際にもそのコアロジック(Core Logic)５２を共通化することで実装が効率化される。また、複数のアプリケーションでコアロジック(Core Logic)５２を共通化することでメンテナンス性が向上する。コアロジック(Core Logic)５２を共通に持つＵＩフレーム(UI Frame)５４の数に制限はない。図９（ｆ）は、図９（ｃ）に対応するアプリケーションリストである。マニフェストファイル５６−１の具体例は、例えば、
{
"id": "appId.std.copy",
"url": "app/copy/baseframe/baseframe.html"
}
であり、マニフェストファイル５６−２の具体例は、例えば、
{
"subId": "copy",
"type": "STD",
"appUrl": "app/copy/copy/uiframe.html",
"isLaunchable": true,
"orderWeight": 100,
"largeIcon": "common/img/preset/app/app_copy_120.png",
"smallIcon": "common/img/preset/app/app_copy_48.png",
"displayName": "Copy",
"displayNameId": "001"
}
あるいは、
{
"subId": "idcopy",
"type": "STD",
"appUrl": "app/copy/idcopy/uiframe.html",
"isLaunchable": true,
"orderWeight": 900,
"largeIcon": "common/img/preset/app/app_idcardcopy_120.png",
"smallIcon": "common/img/preset/app/app_idcardcopy_48.png",
"displayName": "IDCardCopy",
"displayNameId": "002"
}
である。

なお、図９（ｂ）及び図９（ｃ）において、ＵＩフレーム(UI Frame)５４のマニフェストファイル５６−２のisLaunchable属性値を設定することで、実際にホーム画面上にボタンを表示するか否かが決定される。例えば、図９（ｃ）において、コアロジック(Core Logic)５２を共通に持つ、第１のＵＩフレーム(UI Frame)５４と第２のＵＩフレーム(UI Frame)５４が存在し、第１のＵＩフレーム(UI Frame)５４のマニフェストファイルのisLaunchable=trueであるのに対し、第２のＵＩフレーム(UI Frame)５４のマニフェストファイルのisLaunchable=falseである場合、前者はボタンとして表示されるが後者は表示されない。

アプリケーションの実行構造として、コアロジック(Core Logic)５２とＵＩフレーム(UI Frame)５４を分離しているので、コアロジック(Core Logic)５２を変更することなくＵＩフレーム(UI Frame)５４のみを変更し、アプリケーションの画面上の表示形態を容易にカスタマイズすることが可能である。

図１０は、画面上の表示形態をカスタマイズする場合の例を示す。

図１０（ａ）は、当初の表示形態である。ＩＤカードコピーのアプリケーションに着目すると、そのＵＩフレーム(UI Frame)５４はidcopy/uiframe.htmlであり、そのマニフェストファイル５６−２はidcopy/app_manifest.jsonである。

図１０（ｂ）は、表示形態をカスタマイズする場合である。ＩＤコピーのアプリケーションにおいて、そのＵＩフレーム(UI frame)５４とマニフェストファイル５６−２を新しい表示形態用のidcopy_for_xxx/uiframe.htmlとidcopy_for_xxx/app_manifest.jsonに入れ替える。勿論、マニフェストファイル５６−２のみを入れ替えることも可能である。

他方、図１０（ｃ）は、表示形態ではなくアプリケーションのロジックを変更する場合である。この場合には、コアロジック(Core Logic)５２、ＵＩフレーム(UI Frame)５４，マニフェストファイル５６を全て新しいものに入れ替える。すなわち、copy以下をcopy_for_xxxに入れ替える。

図１１は、フレームワーク３１を含めた具体的なアプリケーションの実装構造のパターンを示す。

図１１（ａ）は、コピーアプリケーションとＩＤコピーアプリケーションを実装する場合のパターンの例である。コピーアプリケーションは、コアロジック(Core Logic)５２とＵＩフレーム(UI frame)５４に分離され、コアロジック(Core Logic)５２がフレームワーク３１と通信する。ＵＩフレーム(UI frame)５４はコアロジック(Core Logic)５２のみと通信する。また、ＩＤコピーも同様にコアロジック(Core Logic)５２とＵＩフレーム(UI frame)５４に分離され、コアロジック(Core Logic)５２がフレームワーク３１と通信する。ＵＩフレーム(UI frame)５４はコアロジック(Core Logic)５２のみと通信する。

図１１（ｂ）は、コピーアプリケーションとＩＤコピーアプリケーションに加え、プリントアプリケーションを実装する場合の他の例である。コピーアプリケーションとＩＤコピーアプリケーションは、共通のコアロジック(Core Logic)５２とそれぞれのＵＩフレーム(UI frame)５４に分離される。すなわち、コピーアプリケーション及びＩＤコピーアプリケーションは、共通のコアロジック(Core Logic)５２を介してフレームワーク３１と通信する。また、プリントアプリケーションは、コアロジック(Core Logic)５２は存在するもののＵＩフレーム(UI frame)５４はない。図１１には、図９に示す全てのパターンが含まれている。

従来のアプリケーション実装構造では、このようにコアロジック(Core Logic)５２とＵＩフレーム(UI frame)５４とが分離しておらず、処理と画面描画とが混在して分かり難い構造であった。また、アプリケーションの共通Ｉ／Ｆも存在せず、各アプリケーションはいわば勝手にＩ／Ｆを公開し、勝手にこれを参照していた。これに対し、実施形態では、フレームワーク３１がアプリケーションＩ／Ｆとして定義し、各アプリケーションのコアロジック(Core Logic)５２がこのアプリケーションＩ／Ｆを必ず実装する構造であるため、従来とはＩ／Ｆの向きが相違するといえる。また、フレームワーク３１とアプリケーション間の通信のみならず、アプリケーション間の通信Ｉ／Ｆについてもフレームワーク３１が提供するＩ／Ｆ公開機能とＩ／Ｆ参照機能で実現され得る。

なお、理論上は、複数のアプリケーションでＵＩフレーム(UI frame)５４を共通化し、コアロジック(Core Logic)５２をそれぞれ個別に設けるパターンも存在し得る。但し、この場合にはフレームワーク３１から見ると構造が複雑化するため、実施形態では特に言及していない。勿論、このことは当該パターンの排除を必ずしも意味するものではない。

＜アプリケーションのライフサイクル管理＞
図１２は、フレームワーク３１による各アプリケーションのライフサイクル管理を行う際の基本構成を示す。ここで、フレームワーク３１は、アプリケーションの実行環境である。

プレゼンテーション層に、フレームワーク３１及び各種アプリケーション５０が存在するとともに、ブータ（Booter）６０及びスタータアプリケーション６４が存在する。また、デバイスサービス層に、アプリケーション管理コンポーネント６２が存在する。

ブータ（Booter）６０は、プレゼンテーション層全体の起動終了管理を行うコンポーネントである。フレームワーク３１は、ブータ(Booter)６０により初期化され起動される。

アプリケーション管理コンポーネント６２は、各種アプリケーション５０のマニフェストファイル５６に基づきアプリケーションのリストをフレームワーク３１に提供する。

スタータアプリケーション６４は、フレームワーク３１が定義するスタータＩ／Ｆ７０を実装するアプリケーションである。このスタータアプリケーション６４は、システムで唯一つ存在するアプリケーションであり、全アプリケーション５０の初期化完了時にフレームワーク３１から呼び出される。

各種アプリケーション５０は、既述したようにコピーアプリケーションやＩＤコピーアプリケーション、ファックスアプリケーション等であり、コアロジック(Core Logic)５２を備える。各種アプリケーション５０のコアロジック(Core Logic)５２は、フレームワーク３１が定義するアプリケーションＩ／Ｆ７２を実装する。

各アプリケーション５０が実装するアプリケーションＩ／Ｆは、具体的には、
・初期化時処理(initialize)
・終了時処理(finalize)
・ウィンドウ押し出し処理(windowPushedOut)
・ウィンドウ露出時処理(windowPrepareExposed)
・ウィンドウ削除処理(windowTerminated)
である。各アプリケーション５０は、これらのイベントに対するハンドラを実装する。

フレームワーク３１は、各種アプリケーション５０のコアロジック(Core Logic)５２の間で、メソッドの公開／呼び出し、イベントの公開／購読／発行を可能にするためのJavaScriptコンポーネント（これを通信制御コンポーネントと称する）を備える。メソッドは任意の引数をとり、任意の戻り値を返す定義が可能である。公開したメソッドは、アプリケーション毎に独立して管理される。メソッド呼び出し側のアプリケーションは、メソッドの処理完了をコールバック呼出により確認できる。また、イベントは、各アプリケーションが任意のデータを伴って定義可能である。公開したイベントは、アプリケーション毎に独立して管理される。より詳細には、通信制御コンポーネントはコアロジック(Core Logic)５２によるメソッドの公開及び呼び出し、イベントの定義と発行及びリスナの登録を可能とし、「ON」によりメソッドを公開し、「OFF」によりメソッドの公開を停止する。公開されたメソッドはcallにより呼び出し可能である。例えば、第１のアプリケーションがあるＩ／Ｆを「on」してフレームワーク３１に対して公開し、第２のアプリケーションが第１のアプリケーションの公開されたＩ／Ｆを対象としてフレームワーク３１に対して「call」する等である。

図１３は、フレームワーク３１による各種アプリケーションのライフサイクル管理のフローチャートを示す。

ブータ(Booter)６０がフレームワーク３１を起動すると、フレームワーク３１は、デバイスサービス層のアプリケーション管理コンポーネント６２に対してアプリケーションリストを要求し、アプリケーション管理コンポーネント６２からアプリケーションリストを取得する。

フレームワーク３１は、アプリケーションリストを取得すると、このリストに従ってアプリケーション毎のベースフレーム（Base frame）を作成し、スタータアプリケーション６４を含む各種アプリケーション５０のロードを行う（ロードフェーズ）。すなわち、各アプリケーションのコアロジック(Core Logic)５２の読み込みを行う。具体的には、フレームワーク３１は、マニフェストファイル５６に規定されたコアロジック(Core Logic)５２の格納先情報を参照してコアロジック(Core Logic)５２をロードする。ベースフレーム(Base Frame)は、各アプリケーションのコアロジック(Core Logic)５２を実行するためのフレームであり、このフレームが表示されることはない。各アプリケーションのコアロジック(Core Logic)５２のロード順序は任意であり順不同である。全てのアプリケーションが、アプリケーションＩ／Ｆ実装を登録完了した時点で次のフェーズに移行する。

なお、アプリケーションＩ／Ｆ実装の登録処理よりも前に、各アプリケーション自身のメソッド及びイベントは公開されているものとする。

次に、フレームワーク３１は、アプリケーションＩ／Ｆを通じて、各アプリケーションにイニシャライズ（初期化）を指示する（イニシャライズフェーズ）。具体的には、フレームワーク３１は、各アプリケーションに対して”app”イベント、”initialize”メソッドを発行する。全アプリケーションが、初期化指示に対する完了時呼び出しコールバックを呼び出した時点で、フレームワーク３１はブータ(Booter)６０に対して初期化処理の完了を通知し、次のフェーズに移行する。各アプリケーションの初期化順序も任意である。この初期化処理において、各アプリケーションはデバイスサービス層に対するデータ取得を実行する。

次に、ブータ(Booter)６０は、フレームワーク３１に対してアプリケーションによる機能提供の開始指示を行い、フレームワーク３１は、これを受けてスタータアプリケーション６４に対して開始指示を行う（開始フェーズ）。スタータアプリケーション６４は、デバイスサービス層で管理されている初期起動アプリケーションの情報を取得し、初期画面を表示する。スタータアプリケーション６４が、開始指示に対する完了時呼び出しコールバックを呼び出した時点でこのフェーズが完了する。

なお、システム終了時には、フレームワーク３１は各アプリケーションのコアロジック(Core Logic)５２に対してファイナライズ（終了）を指示する。また、アプリケーション毎のベースフレーム（Base frame）を破棄する。

ロードフェーズでは、順不同で各アプリケーションのコアロジック(Core Logic)５２を読み込むので、アプリケーションを追加したとしてもこのロードフェーズを変更する必要がない。また、イニシャライズフェーズでは、全アプリケーションの初期化を行うので他のアプリケーションを呼び出すことが保証されており、個別の待ち合わせは不要である。このように、アプリケーション間の待ち合わせが無くなり、かつ、比較的小さいサイズのコアロジック(Core Logic)５２のみをロードするので、システム起動時間及びアプリケーション起動時間が短縮される。

各アプリケーションが独自にＩ／Ｆを公開している場合、アプリケーション毎に起動、初期化前処理、初期化、初期化後処理、停止、一時停止等が異なるためアプリケーション毎に初期化レベルに相違が生じ、アプリケーションを呼び出すことができるタイミングもばらついてしまう。特に、アプリケーションを呼び出す前に、相手を呼び出せる状態であるか否かを確認する必要が生じ、制御が複雑化してしまう。これに対し、実施形態では、上記のように初期化時間が短縮されるとともに、初期化後のホーム画面の起動時間も短縮され得る。

図１４は、従来及び実施形態におけるシステム起動からホーム画面が表示されるまでの時間を比較して示す。

従来においては、アプリ初期化時間は、純粋な初期化時間に加えて待ち時間を要しており、ホーム画面の起動時間も同様に純粋な起動時間に加えて待ち時間を要していたところ、実施形態では純粋な初期化時間を短縮できるとともに待ち時間を削減することもできる。ホーム起動時間についても同様である。従来においては、アプリケーション間で依存関係がある場合にはデッドロックが生じないような調整が必要であるところ、実施形態ではこのような依存関係がないためデッドロック用調整も不要化される。

各アプリケーション５０が実装するアプリケーションＩ／Ｆのうち、ウィンドウ削除処理(windowTerminated)について、さらに説明する。

ウィンドウ削除処理(windowTerminated)は、アプリケーション５０のウィンドウが削除（破棄）されたことを通知するＩ／Ｆである。

従来、外部アプリケーション、例えば外部ブラウザ等を実行した場合に、画面の一番上（上位レイヤー）に外部アプリケーションを表示し、外部アプリケーションの正常終了を待ち続ける処理を行っており、外部アプリケーションの異常が生じると、予め確保しておいたシステム再起動画面を表示し、システムを再起動していた。

これに対し、本実施形態では、外部アプリケーションに何らかの要因で異常が生じると、フレームワーク３１が当該外部アプリケーションのウィンドウを削除（破棄）し、これとともに当該アプリケーションに対してウィンドウを削除（破棄）したことを通知する。当該外部アプリケーションは、この通知によりウィンドウが削除（破棄）されたことを知ることができ、削除に伴う処理、例えば自ら停止する、あるいは自ら再起動する等の処理を行うことができる。

なお、要因としては、ブラウザ個数上限への到達、アプリケーションによる外部ブラウザの停止、外部ブラウザにおける例外の発生等がある。

また、ウィンドウの削除を当該外部アプリケーションに通知する場合に、そのプロパティとして、ウィンドウが削除された理由を含めることもできる。例えば、プロパティとして、
Requested: 他のアプリケーションからの削除要求
limitExceeded:ブラウザ個数上限への到達
とする等である。これにより、通知を受け取った外部ブラウザは、削除（破棄）の理由に応じた事後処理を行い得る。

図１５は、フレームワーク３１とアプリケーション５０間のウィンドウ削除処理(windowTerminated)を用いた動作を示す。アプリケーション５０として、アプリ１を示す。

ロードフェーズ及びイニシャライズフェーズが終了した後、アプリ１は、フレームワーク３１に対してcreateWindowを要求し、この要求に対してフレームワーク３１はウィンドウのＩＤ（画面番号）を返す。例えば、ＩＤとして画面番号１（以下、これをＧ１とする）を返す。なお、createWindowのオブジェクトのプロパティには、ＵＲＬやタイプ等が含まれる。ＵＲＬは、ウィンドウに読み込むリソースのＵＲＬであり、タイプは作成するウィンドウのタイプであり、ホームアプリ用のウィンドウ、通常のアプリ用のウィンドウ、バナー用ウィンドウ、ポップアップ用のウィンドウ等を指定できる。アプリ１は、受け取った画面番号を用いてフレームワーク３１に表示依頼showWindowを要求する。フレームワーク３１は、この要求に応じてＧ１を表示する。

アプリ１がＧ１の非表示依頼hideWindowを要求すると、フレームワーク３１は、この要求に応じてＧ１を非表示とする。

次に、何らかの要因によりアプリ１のＧ１を削除（破棄）する必要が生じた場合、フレームワーク３１は、アプリ１に対してＧ１の削除（破棄）予告を通知する。その後、アプリ１から予告の応答を受信したフレームワーク３１は、Ｇ１を削除（破棄）し、これとともにアプリ１に対して削除通知であるwindowTerminatedを通知する。アプリ１は、この通知を受け取ることで、自身のウィンドウが削除（破棄）されたことを知ることができ、例えば自ら停止する処理を行う。

図１６は、表示画面の遷移状態を示す。図１６（ａ）は、イニシャライズフェーズが終了して初期画面（デフォルト画面）が表示されている状態を示す。デフォルト画面をＧ０として示す。

図１６（ｂ）は、アプリ１からshowWindowが要求され、これに応じてフレームワーク３１が画面上にアプリ１の画面Ｇ１を表示した状態を示す。

図１６（ｃ）は、何らかの要因でＧ１が削除（破棄）された状態を破線で示す。このとき、フレームワーク３１は、アプリ１に対して削除を通知する。

図１６（ｄ）は、Ｇ１削除後の状態である。表示するウィンドウが存在しないので、フレームワーク３１は再びデフォルト画面Ｇ０を表示する。

以上説明したように、本実施形態では、アプリケーションをコアロジック(Core Logic)５２とＵＩフレーム(UI frame)５４に分離し、フレームワーク３１が定義するＩ／Ｆをコアロジック(Core Logic)５２が実装する構成とし、コアロジック(Core Logic)５２がフレームワーク３１を介して他のアプリケーションのコアロジック(Core Logic)５２と通信し、他方でＵＩフレーム(UI frame)５４はそのアプリケーションのコアロジック(Core Logic)５２のみと通信する構成とすることで、各アプリケーションは、フレームワーク３１によって定義された共通の構成を有すると同時に、他のアプリケーションとの間の結合度合いが低くなるように構成することが可能となり、追加や削除が容易化される。

また、アプリケーション５０は、自分のウィンドウが削除（破棄）されたことをフレームワーク３１からの通知により知ることができるので、これに応じた処理を速やかに実行できる。

なお、本実施形態における「コンポーネント」とは、論理的に分離可能なソフトウェアの部品を意味する。コンポーネントは１つ又は複数のプロセッサによって実行され得る。本実施形態では、JavaScriptを用いているが、勿論これ以外のプログラミング言語を用いることもできる。

また、本発明は上記の実施形態に限定されるものではなく、種々の変形例が可能である。以下に、変形例について説明する。

＜変形例＞
実施形態では、画像形成装置１２の制御部（プロセッサ）２２が、プレゼンテーション層３０のフレームワーク３１及び各種アプリケーション５０を実行するものとしているが、図２に示すように、プレゼンテーション層３０とデバイスサービス層３２は分離しているから、プレゼンテーション層３０のフレームワーク及び各種アプリケーション５０を画像形成装置１２と異なる別個の装置、例えば画像形成装置１２を制御するためのスマートフォンやタブレット端末等の携帯端末のプロセッサが実行する構成としてもよい。また、図１における操作部２６も携帯端末に搭載されることが望ましい。この場合、携帯端末と画像形成装置１２とを併せて画像形成装置ないし画像形成システムと言うことができる。

１０端末装置、１２画像形成装置、１６ＲＯＭ、１８ＲＡＭ、２０ＨＤＤ、２４入出力インターフェイスＩ／Ｆ、２６操作部、２８画像形成部、３０プレゼンテーション層、３１フレームワーク、３２デバイスサービス層、５０アプリケーション、５２コアロジック(Core Logic)、５４ＵＩフレーム(UI frame)、５６マニフェストファイル。

Claims

基本処理を担うコアロジック部、及び描画処理を担うＵＩフレーム部に分離され、フレームワーク上で動作するアプリケーションと、
アプリケーション及びフレームワークを実行する制御手段と、
を備え、コアロジック部はフレームワークが定義するインターフェイス（Ｉ／Ｆ）を実装し、インターフェイス（Ｉ／Ｆ）には、アプリケーションが表示しているウィンドウが削除されたことの通知が含まれる
画像形成装置。
ウィンドウが削除されたことの通知には、プロパティとして削除理由が含まれる
請求項１に記載の画面形成装置。
画像形成装置を制御するプロセッサに実行させるプログラムであって、
基本処理を担うコアロジック部と、描画処理を担うＵＩフレーム部に分離されており、
コアロジック部は、フレームワークが定義するインターフェイス（Ｉ／Ｆ）を実装し、
インターフェイス（Ｉ／Ｆ）には、アプリケーションが表示しているウィンドウが削除されたことの通知が含まれる
プログラム。