Oracle® Mobile Application Framework Oracle Mobile Application Frameworkでのモバイル・アプリケーションの開発 2.2.0 E69896-01 |
|
![]() 前 |
![]() 次 |
この章の内容は次のとおりです。
データ・キャッシュは、モバイル・アプリケーションのユーザーに優れたユーザー操作性を提供するための重要な要素です。ユーザーは、モバイル・アプリケーションがいつでも使用でき、機能することを期待します。残念なことに、モバイル・アプリケーションの接続性は信頼できない場合もあり、ネットワーク接続を使用できなかったり、接続の確立時につながったり切れたりを繰り返し、最終的に切断されることがあります。MAFでは、エンド・ユーザーのデバイスがオフラインのときも作業を継続できるMAFアプリケーションの開発を可能とする、いくつかの機能が提供されています。ネットワーク接続が使用できない場合、MAFアプリケーションではローカルに格納されているキャッシュ・データにアクセスして、シームレスなユーザー操作を確保します。
図25-1は、MAFのキャッシュの仕組みを示しています。キャッシュ・レイヤーでは、ビジネス・ロジック・レイヤーから生成されるRESTコールがインターセプトされます。キャッシュ・レイヤーでは、sync-config.xml
ファイルが読み取られ、ファイルのエントリに基づいて、RESTサービスからのレスポンスがキャッシュ・データ・ストアに格納されます。sync-config.xml
ファイルで、キャッシュするURI(エンド・ポイント)リソースを指定し、そのURIのキャッシュ・ポリシーを指定します。キャッシュ・レイヤーでは、指定したURIがキャッシュ内で特定のリソースを識別するためのキーとして使用されます。
図25-1 MAFアプリケーションでのデータのキャッシュ
MAFでは、キャッシュ内のデータのリフレッシュおよび期限切れの頻度を決定するために、適用および構成できるポリシーのセットが提供されます。これらのポリシーにより、リクエストを処理する方法をキャッシュ・レイヤーに伝え、その結果として、アプリケーションにとって、サーバーからデータを取得するよりもデバイスに格納されているフェッチ・データをオフラインで読み込んで使用する方が高速なため、アプリケーションのパフォーマンスを向上できます。これらのポリシーでは、インターネットに接続できなくなった場合にオフライン読取りを有効にすることで、アプリケーション・キャッシュで最適なユーザー操作性を維持することもできます。
次の項で説明されている機能から、自分のMAFアプリケーションで必要とするものを実装します。
注意:
MAFアプリケーションでは、JSONペイロードでRESTサービスによって取得されたデータのキャッシュのみがサポートされます。データ・キャッシュを有効にするには、maf.properties
ファイルで次の行のコメントを外します。
#java.commandline.argument=-DsyncEnabled=true
注意:
データ・キャッシュを有効にすると、ネットワーク上を通過するすべてのデータがキャッシュされます。キャッシングを有効にしてアプリケーションをデプロイした後、実行時にオフにする方法はありません。
キャッシュするリソースおよびキャッシュ・ポリシーの構成の詳細は、「sync-config.xmlファイル内のキャッシュ・リソースおよびキャッシュ・ポリシーの指定」を参照してください。
JDeveloperでは、MAFアプリケーションを作成すると、デフォルトでMAFアプリケーションの/.adf/META-INF
ディレクトリにsync-config.xml
ファイルが作成されます。このファイルを使用して、MAFアプリケーションが指定のエンド・ポイント(URI)に対してコールを行うときに適用されるキャッシュ・ポリシーを指定します。デフォルトで、sync-config.xml
ファイルには、キャッシュを有効にすると適用されるデフォルトのポリシーが含まれています。このデフォルトのキャッシュ・ポリシーは、sync-config.xml
ファイルで指定するエンド・ポイント以外のすべてのエンド・ポイントに適用されます。
例25-1は、同じサーバーから生成される2つのエンド・ポイント(URI)に対する2つの個別のポリシー(policy1
およびpolicy2
)を定義する方法を示しています。この例には、MAFアプリケーションがpolicy1
およびpolicy2
に指定されている以外のすべてのURIにRESTコールを行うときに適用されるデフォルトのポリシーも示されています。さらに、この例は、暗号化を有効にする方法を示しています。
WorkBetterサンプル・アプリケーションのsync-config.xml
ファイルで、キャッシュ・ポリシーの別の使用例を表示できます。サンプル・アプリケーションの詳細は、「サンプルのMAFアプリケーション」を参照してください。
例25-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
ファイルの変更は必要ありません。
例25-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
ファイルに、モバイル・アプリケーションのキャッシュ・ポリシーを定義します。ポリシーを組み合せて、モバイル・アプリケーションに適切なコンテンツを提供します。
データ・ストレージ・ポリシー設定の構成の詳細は、「sync-config.xmlファイル内のキャッシュ・リソースおよびキャッシュ・ポリシーの指定」を参照してください。
アプリケーションのキャッシング動作の構成を可能にするポリシーは、次のグループに分類されます。
フェッチ・ポリシー - リソースをフェッチするキャッシュ・レイヤーを指示します(サーバーから、ローカル・キャッシュから、その2つの組合せなど)。該当するポリシーのリストは、表25-1を参照してください。
有効期限ポリシー - キャッシュ・レイヤーが、ローカル・キャッシュに格納されているリソースが古くなり失効し、更新ポリシー(表25-4で説明)によって更新する必要があるか、または削除ポリシー(表25-3を参照)によってローカル・キャッシュから削除する必要があるかを確認するまでの期間(秒単位)を設定します。有効期限ポリシーの詳細は、表25-2を参照してください。
削除ポリシー - キャッシュ・レイヤーが、いつ、ローカル・キャッシュに格納されているリソースを削除するかを指定します。削除ポリシーは、サーバー側のリソースではなく、ローカル・キャッシュのデータのみに適用されます。ポリシーのリストは、表25-3を参照してください。
更新ポリシー — ローカル・キャッシュに格納されている期限切れのポリシーの更新のタイミングを定義します。ポリシーのリストは、表25-4を参照してください。
表25-1 フェッチ・ポリシー
|
表25-2 有効期限ポリシー
|
表25-3 削除ポリシー
|
表25-4 更新ポリシー
|
sync-config.xml
のBaseUri
要素およびServerGroup
要素のbaseUri
属性は、connections.xml
で定義されたエンド・ポイントを参照できます。この機能を利用するには、次のように、URL以外の有効な接続参照を指すように値を置換します。
baseUri="<connection_reference_name_in_connections_xml>"
エンド・ポイントが接続オーバーライドを使用して実行時に変更された場合、キャッシュ・ポリシーは新規URLに対しても同じになります。詳細は、第16章「MAFアプリケーションで使用するエンド・ポイントの構成」を参照してください。WorkBetterサンプル・アプリケーションは、この構成の実装を示しています。このサンプル・アプリケーションおよびその他のサンプル・アプリケーションにアクセスする方法の詳細は、「サンプルの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
ファイルの内容をマージします。「FARのビュー・コントローラ・プロジェクトとしての追加時に行われる処理」で説明されているように、sync-config.xml
ファイルには、モバイル・アプリケーションによって使用されるWebサービスのエンド・ポイントが記述されているため、FARを追加することで、モバイル・アプリケーションを構成するアプリケーション機能によって使用されるすべてのWebサービスのエンド・ポイントを更新できます。
FARをアプリケーションに追加すると、MAFでは、アプリケーションのsync-config.xml
ファイルおよびconnections.xml
ファイルを確認し、必要に応じて変更するように求めるメッセージがログに記録されます。図25-2に示すように、これらのメッセージは、使用するアプリケーションのsync-config.xml
ファイルの状態を反映します。
図25-2 メッセージ・ログ
使用するアプリケーションに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