| Oracle Enterprise Pack for Eclipse Oracle Mobile Application Framework (OEPE Edition)でのモバイル・アプリケーションの開発 リリース2.2.1 E72511-01 |
|
 前 |
 次 |
| Oracle Enterprise Pack for Eclipse Oracle Mobile Application Framework (OEPE Edition)でのモバイル・アプリケーションの開発 リリース2.2.1 E72511-01 |
|
前 |
次 |
この章では、MAFアプリケーションでデータ・キャッシュを有効にする方法を説明します。
この章の内容は次のとおりです。
データ・キャッシュは、モバイル・アプリケーションのユーザーに優れたユーザー操作性を提供するための重要な要素です。ユーザーは、モバイル・アプリケーションがいつでも使用でき、機能することを期待します。実際には、モバイル・アプリケーションの接続の信頼性が低いことはよく知られており、ネットワーク接続を使用できなかったり、接続の確立時につながったり切れたりを繰り返し、最終的に切断されることがあります。モバイル・アプリケーションで最適なユーザー操作性を実現するため、MAFには、オフライン時でも継続して機能するアプリケーションを開発できるAPIが用意されているので、モバイル・アプリケーションでの最適なユーザー操作性が保証されます。ネットワーク接続が使用できない場合、モバイル・アプリケーションではローカルに格納されているキャッシュ・データにアクセスして、シームレスなユーザー操作を確保します。
図26-1に、MAFでのキャッシュの動作を示します。キャッシュ・レイヤーは、ビジネス・ロジック・レイヤーで発生したRESTコールをインターセプトします。キャッシュ・レイヤーは、sync-config.xmlファイルを読み取り、ファイルのエントリに基づいて、RESTサービスからのレスポンスをキャッシュ・データ・ストアに格納します。sync-config.xmlファイルでは、キャッシュするURI (エンド・ポイント)とURIのキャッシュ・ポリシーを指定します。キャッシュ・レイヤーでは、指定したURIがキャッシュ内の特定のリソースを識別するキーとして使用されます。
オフライン・データ格納の中心にあるのは、ユーザー操作性を向上するポリシーのセットであり、このポリシーでは、ローカル・キャッシュに格納されているRESTリソースをモバイル・アプリケーションでどのようにリフレッシュするかを記述します。アプリケーションでは、サーバーからデータを取得するよりも、デバイスに格納されているデータをオフライン読取りを使用してフェッチする方がすばやく実行できるため、これらのポリシーでは、リクエストの処理方法を同期クライアントSDKに指示し、アプリケーションのパフォーマンスを向上できます。これらのポリシーでは、インターネットに接続できなくなった場合にオフライン読取りを有効にすることで、アプリケーション・キャッシュで最適なユーザー操作性を維持することもできます。
MAFには、キャッシュ内のデータのリフレッシュ頻度および有効期限を決定するために適用および構成できるポリシーのセットが用意されています。これらのポリシーは、リクエストの処理方法をキャッシュ・レイヤーに指示します。その結果、アプリケーションがオフライン読取りを使用してデバイスに格納されているデータをフェッチする方がサーバーからデータを取得するよりも速いため、アプリケーション・パフォーマンスを向上させることができます。これらのポリシーでは、インターネットに接続できなくなった場合にオフライン読取りを有効にすることで、アプリケーション・キャッシュで最適なユーザー操作性を維持することもできます。
説明されている機能をMAFアプリケーションで実装するには、次のことが必要です。
|
注意: MAFアプリケーションでは、JSONペイロードでRESTサービスによって取得されるデータのキャッシュのみサポートされます。 |
データ・キャッシュを有効にするには、maf.propertiesファイルで次の行のコメントを外します。
#java.commandline.argument=-DsyncEnabled=true
|
注意: データ・キャッシュを有効にすると、ネットワーク上で渡されるデータがキャッシュされます。キャッシングを有効にしてアプリケーションをデプロイした後、実行時にオフにする方法はありません。 |
キャッシュするリソースと使用するキャッシュ・ポリシーの構成の詳細は、sync-config.xmlファイルのキャッシュ・リソースとキャッシュ・ポリシーの指定に関する説明を参照してください。
OEPEは、MAFアプリケーションの作成時に、デフォルトでトップレベルまたはアセンブリ・プロジェクトの/adf/META-INFディレクトリにsync-config.xmlファイルを作成します。このファイルを使用して、指定したエンド・ポイント(URI)をMAFアプリケーションがコールする際に適用するキャッシュ・ポリシーを指定します。デフォルトでは、sync-config.xmlファイルには、キャッシュを有効にするときに適用されるデフォルト・ポリシーが含まれます。このデフォルト・キャッシュ・ポリシーは、sync-config.xmlファイルで指定するエンド・ポイント以外のすべてのエンド・ポイントに適用されます。
例26-1に、同じサーバーから発生した2つの異なるエンド・ポイント(URI)に対して2つの異なるポリシー(policy1とpolicy2)を定義する方法を示します。例では、policy1およびpolicy2に対して指定したURI以外のすべてのURIに対してMAFアプリケーションがRESTコールを行うときに適用されるデフォルト・ポリシーも示しています。最後に、例では暗号化を有効にする方法を示します。
WorkBetterサンプル・アプリケーションのsync-config.xmlファイルで使用しているキャッシュ・ポリシーの別の例も参照できます。サンプル・アプリケーションの詳細は、付録G「サンプルのMAFアプリケーション」を参照してください。
次の例26-1では、sync-config.xmlのBaseURI要素のTaskConnはMAFアプリケーションのconnections.xmlファイルで定義されている接続への参照です。
<Reference name="TaskConn" className="oracle.adf.model.connection.url.HttpURLConnection" xmlns="">
<Factory className="oracle.adf.model.connection.url.URLConnectionFactory"/>
<RefAddresses>
<XmlRefAddr addrType="TaskConn">
<Contents>
<urlconnection name="TaskConn" url="http://localhost:7101/TaskService/rest/v1"/>
</Contents>
</XmlRefAddr>
</RefAddresses>
</Reference>
この構成の利点は、接続詳細が変更された場合(たとえばホスト名の変更など)に、connections.xmlファイルの変更のみ必要なことです。sync-config.xmlファイルを変更する必要はありません。
例26-1 2つのポリシーを定義しているサンプルsync-config.xmlファイル
<Settings xmlns="http://xmlns.oracle.com/sync/config">
<!-- The connection.xml file defines the URL that the value of the BaseURI element references. -->
<BaseUri>TaskConn</BaseUri>
...
<EnableEncryption>true</EnableEncryption>
<Policies>
<ServerGroup id="tasklist" baseUri="TaskConn">
<Policy id="policy1">
<Path>/taskservice1/rest/v1/TaskList/*</Path>
<!-- This caching policy applies to a REST service accessed by a call to an end point constructed from
a concatenation of the baseURI value for TaskConn and the <Path> element's value. That is,
http://localhost:7101/TaskService/rest/v1/taskservice1/rest/v1/TaskList/*
When the end point above is used by the business logic layer in the MAF application, the cache layer checks sync-config.xml
to see if there is a cache policy defined for the end point. If it finds the policy, it applies the policy. -->
<FetchPolicy>FETCH_FROM_SERVICE_ON_CACHE_MISS_OR_EXPIRY</FetchPolicy>
<UpdatePolicy>QUEUE_IF_OFFLINE</UpdatePolicy>
<ExpirationPolicy>EXPIRE_AFTER</ExpirationPolicy>
<ExpireAfter>30</ExpireAfter>
<EvictionPolicy>EVICT_ON_EXPIRY_AT_STARTUP</EvictionPolicy>
</Policy>
</ServerGroup>
<ServerGroup id="taskdetail" baseUri="TaskConn">
<Policy id="policy2">
<Path>/taskservice1/rest/v1/TaskDetail/*</Path>
<!-- This caching policy applies to a different REST service accessed by a call to an end point constructed from
a concatenation of the baseURI value for TaskConn and the <Path> element's value. That is,
http://localhost:7101/TaskService/rest/v1/taskservice1/rest/v1/TaskDetail/*
When the end point above is used by the business logic layer in the MAF app, the cache layer checks sync-config.xml
to see if there is a cache policy defined for the end point. If it finds the policy, it applies the policy. -->
<FetchPolicy>FETCH_FROM_SERVICE_IF_ONLINE</FetchPolicy>
<UpdatePolicy>UPDATE_IF_ONLINE</UpdatePolicy>
<ExpirationPolicy>EXPIRE_AFTER</ExpirationPolicy>
<ExpireAfter>30</ExpireAfter>
<EvictionPolicy>EVICT_ON_EXPIRY_AT_STARTUP</EvictionPolicy>
</Policy>
</ServerGroup>
<DefaultPolicy>
<FetchPolicy>FETCH_FROM_SERVICE_IF_ONLINE</FetchPolicy>
<UpdatePolicy>UPDATE_IF_ONLINE</UpdatePolicy>
<ExpirationPolicy>NEVER_EXPIRE</ExpirationPolicy>
<EvictionPolicy>MANUAL_EVICTION</EvictionPolicy>
</DefaultPolicy>
</Policies>
</Settings>
モバイル・アプリケーションのキャッシュ・ポリシーは、sync-config.xmlファイルで定義します。ポリシーを結合して、モバイル・アプリケーションに適した内容を提供します。
データ・ストレージ・ポリシー設定の構成の詳細は、第26.3項「sync-config.xmlファイルでのキャッシュ・リソースおよびキャッシュ・ポリシーの指定」を参照してください。
アプリケーションのキャッシング動作の構成を可能にするポリシーは、次のグループに分類されます。
フェッチ・ポリシー: リソースをフェッチすることをキャッシュ・レイヤーに指示します(サーバーから、ローカル・キャッシュから、2つの組合せなど)。これらのポリシーのリストは、表26-1を参照してください。
有効期限ポリシー: キャッシュ・レイヤーがローカル・キャッシュに格納されているリソースを古いまたは失効したポリシーとみなすため、更新ポリシーに従った更新(表26-4を参照)または削除ポリシーによるローカル・キャッシュからの削除(表26-3を参照)が必要になるまでの期間(秒単位)を設定します。有効期限ポリシーの詳細は、表26-2を参照してください。
削除ポリシー: ローカル・キャッシュに格納されているリソースをキャッシュ・レイヤーがいつ削除するかを指定します。削除ポリシーは、サーバー側のリソースではなく、ローカル・キャッシュのデータのみに適用されます。ポリシーのリストは、表26-3を参照してください。
更新ポリシー — ローカル・キャッシュに格納されている期限切れのポリシーの更新のタイミングを定義します。ポリシーのリストは、表26-4を参照してください。
表26-1 フェッチ・ポリシー
| ポリシー | 説明 |
|---|---|
|
キャッシュからフェッチ |
キャッシュ・レイヤーに、サーバーからではなくキャッシュからのみデータをフェッチするよう指示します。キャッシュ・レイヤーは、キャッシュにデータが見つからない場合に、エラーまたはnullオブジェクトを返します。キャッシュ・レイヤーは、このポリシーを適用するときにキャッシュから直接データを取得するため、このポリシーは、クライアント・アプリケーションがオンラインまたはオフラインのときに実行できます。 |
|
サービスからフェッチ |
キャッシュ・レイヤーに、キャッシュからではなくサーバーのみからデータを直接フェッチするよう指示します。キャッシュ・レイヤーは、クライアント・アプリケーションがオンラインの場合にのみこのポリシーを適用できます。それ以外の場合は、エラーまたはNULLオブジェクトがクライアント・アプリケーションに返されます。 |
|
サービスからフェッチ(オンラインの場合) |
キャッシュ・レイヤーに、クライアント・アプリケーションがオンラインの場合にサーバーからデータをフェッチするか、アプリケーションがオフラインの場合にキャッシュからデータをフェッチするよう指示します。 |
|
サービスからフェッチ(キャッシュミス) |
キャッシュ・レイヤーに、キャッシュからデータをフェッチするよう指示します。リクエストされたデータが見つからない場合、キャッシュ・レイヤーはサーバーからフェッチします。 |
|
サービスからフェッチ(キャッシュミスまたは有効期限) |
キャッシュ・レイヤーに、キャッシュに存在し、失効していない(有効期限切れでない)場合にキャッシュ内のデータをフェッチするよう指示します。それ以外の場合、キャッシュ・レイヤーはリクエスト・データをサーバーからフェッチします。 |
|
キャッシュからフェッチ(更新をスケジュール) |
キャッシュ・レイヤーに、キャッシュからデータをフェッチし、サーバーの最新コピーからキャッシュを更新するバックグラウンド・リフレッシュをスケジュールするよう指示します。キャッシュミスがある(キャッシュにリクエストされたデータがない)場合、キャッシュ・レイヤーはクライアント・アプリケーションにnullオブジェクトを返します。 |
|
更新でフェッチ |
キャッシュ・レイヤーに次のことを指示します。
キャッシュミスがある(リクエストされたデータがキャッシュにない)場合、またはデータが有効期限切れの場合、キャッシュ・レイヤーはサービスからフェッチ・ポリシーと同様にデータをサーバーから直接フェッチします。 |
表26-2 有効期限ポリシー
| ポリシー | 説明 |
|---|---|
|
再起動時に期限切れ |
キャッシュ・レイヤーに、クライアント・アプリケーションの再起動時にURIのデータを期限切れとみなすか、クライアント・アプリケーションによって次回コールされたときにサーバー・コピーでローカル・データを更新するかを指示します。 |
|
期限切れまでの時間 |
キャッシュ・レイヤーに、期限切れにするまでの時間ポリシーで設定された指定時間(秒単位)の経過後にデータを期限切れにするよう指示します。このポリシーは、定期的に更新されるデータに使用されます。 |
|
期限切れにするまでの時間 |
キャッシュ・レイヤーがキャッシュ内のデータを有効期限切れとみなすまでの秒数。 |
|
期限切れなし |
キャッシュ・レイヤーに、ローカル・データを有効期限切れとして指定できないことを指示します。 |
sync-config.xmlのBaseUri要素およびServerGroup要素のbaseUri属性は、connections.xmlで定義されたエンド・ポイントを参照できます。この機能を利用するには、次のように、URL以外の有効な接続参照を指すように値を置換します。
baseUri="<connection_reference_name_in_connections_xml>"
エンド・ポイントが接続オーバーライドを使用して実行時に変更された場合、キャッシュ・ポリシーは新規URLに対しても同じになります。詳細は、第18章「MAFアプリケーションで使用されるエンド・ポイントの構成」を参照してください。WorkBetterサンプル・アプリケーションは、この構成の実装を示しています。このサンプルおよびその他のサンプル・アプリケーションにアクセスする方法は、付録G「サンプルのMAFアプリケーション」を参照してください。
MAFには、MAFアプリケーションがキャッシュするデータを暗号化する機能が用意されています。
有効にすると、MAFアプリケーションでキャッシュされたすべてのデータが暗号化されます。このオプションはデフォルトでは無効にされています。次の例に示すように、暗号化を有効にするようにsync-config.xmlファイルを構成します。
<?xml version="1.0" encoding="UTF-8"?> <Settings xmlns="http://xmlns.oracle.com/sync/config"> <BaseUri>TaskConn</BaseUri> ... <EnableEncryption>true</EnableEncryption> <Policies> ... </Settings>
ビュー・コントローラ・プロジェクトがFARとしてデプロイされると、sync-config.xmlファイルは機能アーカイブ・ファイルに含まれます。connections.xmlファイルと同様に、FARをアプリケーションに追加すると、MAFではFAR (jar-sync-config.xml)内のsync-config.xmlファイルの内容と、使用するアプリケーションのsync-config.xmlファイルの内容をマージします。sync-config.xmlファイルは、モバイル・アプリケーションによって使用されるWebサービスのエンドポイントを記述するため、モバイル・アプリケーションを構成するアプリケーション機能によって使用されるすべてのWebサービスのエンドポイントを、FARを追加することで更新できます(第9.2項「FARのビュー・コントローラ・プロジェクトとしての追加時に行われる処理」を参照)。
FARをアプリケーションに追加すると、MAFでは、アプリケーションのsync-config.xmlファイルおよびconnections.xmlファイルを確認し、必要に応じて変更するように求めるメッセージがログに記録されます。これらのメッセージは、使用するアプリケーションのsync-config.xmlファイルの状態を反映します。
使用するアプリケーションにsync-config.xmlファイルがない場合、MAFではこのファイルをアプリケーションに追加し、次のようなメッセージを書き込みます。
oracle.adfmf.framework.dt.deploy.features.deployers.SyncConfigMerger _logNoSyncConfigInAppUsingFar WARNING: The application does not contain a synchronization file, "sync-config.xml". Creating one containing the synchronization configuration in the Feaure Archive.
sync-config.xmlファイルの<ServerGroup>要素に、使用するアプリケーションのconnections.xmlファイルで定義された対応する<Reference>要素がない場合、MAFでは接続の確認(または作成)をリクエストする次のようなログ・メッセージを書き込みます。
oracle.adfmf.framework.dt.deploy.features.deployers.SyncConfigMerger _logAddedServerGroups
WARNING: The following server groups were added sync-config.xml by the Add to Application
operation:
{
ServerGroup1 - there is no existing application connection defined for this server group.
Please create the connection.
ServerGroup2 - verify its configuration.
}
使用するアプリケーションのsync-config.xmlファイルの<ServerGroup>定義が、FAR内の対応するsync-config.xmlファイルの定義を複製する場合、MAFでは次のSEVEREレベルのメッセージをログに書き込みます。
oracle.adfmf.framework.dt.deploy.features.deployers.SyncConfigMerger _logDuplicateServerGroups SEVERE: Cannot merge the server groups from the Feature Archive because the following definitions already exist: ServerGroup1 ServerGroup2
