プライマリ・コンテンツに移動
Oracle® Mobile Application Framework Oracle Mobile Application Frameworkのインストール
2.2.2
E72583-01
目次へ移動
目次

前

3 アプリケーションのMAF 2.2.2への移行

この章では、以前のリリースのMAFを使用して作成されたアプリケーションをMAF 2.2.2に移行する際に必要になる情報を説明します。

この章の内容は次のとおりです。

3.1 アプリケーションのMAF 2.2.2への移行

MAFでは、このリリースに移行するアプリケーションのアプリケーション・トランスポート・セキュリティ(ATS)がデフォルトで有効になります。詳細は、「MAFリリース2.2.1以上でのセキュリティの変更」を参照してください。移行対象のアプリケーションがURLスキームを使用して他のアプリケーションを起動する場合は、「カスタムURLスキームを使用して他のアプリケーションを起動するMAFアプリケーションの移行」の説明に従って移行対象アプリケーションを構成します。

MAF 2.1.0リリースでは、この章で説明する大幅な変更が導入されました。この章の情報は、MAF 2.1.0より前のリリースで作成したアプリケーションをMAF 2.2.2に移行する場合に使用します。

MAF 2.1.0では、新しいバージョンのApache CordovaとJavaが使用されていました。また、JDeveloperによるMAFアプリケーションへのプラグインの登録方法も変更されました。SSL用には、新しいCAルート証明書が含まれているcacertsファイルが提供されていました。

MAF 2.1.0で作成されたアプリケーションまたは以前にMAF 2.1.0に移行したアプリケーションをMAF 2.2.2に移行する場合、MAFでは、JDK 8への移行、Cordovaプラグインの管理、および新しいcacertsファイルに必要な変更は事前に行われます。

この章の後続の項では、これらの変更がMAFアプリケーションのMAF 2.1.0以降への移行にどのような影響を与えるかについて説明しているので、参照してください。

また、MAF 2.1.0ではSQLiteデータベースとJDBCドライバが更新されていました。移行対象のMAFアプリケーションで、SQLiteデータベースに接続するコードを確認し、必要に応じて移行してください。SQLiteデータベースへの接続方法の詳細は、『Oracle Mobile Application Frameworkでのモバイル・アプリケーションの開発』のローカルSQLiteデータベースの使用方法に関する項を参照してください。

アプリケーションをこのリリースに移行した後で、JDeveloperの「すべてクリーン」コマンドを起動します。こうすることで、このリリースに移行する前に、ビルド・アーティファクトのアプリケーションがビルドから消去されます。これには、JDeveloperのメイン・メニューで「ビルド」「すべてクリーン」をクリックします。

3.2 MAFリリース2.2.1以上でのセキュリティの変更

MAF 2.2.1以降、iOS上のMAFアプリケーションからサーバーへのすべての接続では、TLS 1.2のHTTPSを使用することが必要です。非HTTPS接続およびTLS1.2未満のSSLバージョンを使用するすべてのMAFアプリケーションは、iOSでは実行できません。MAFは、Apple iOS 9の要件を満たすためにこの動作を行い、TLS 1.2のHTTPSの使用が必要なアプリケーション・トランスポート・セキュリティ(ATS)を使用します。次の説明に従って、ATSの使用を無効にすることもできます。

また、MAFアプリケーションは、Java 8のJVMによって実施されるデフォルトの動作に従って、最新のSSLバージョンと暗号化スイートを使用します。このような新しいバージョンを使用するためにサーバーのアップグレードをお薦めします。ただし、次の説明に従ってMAFアプリケーションを構成すると、古いSSLバージョンでサーバーを使用した際に発生する可能性があるSSLエラーを回避することができます。

iOSデバイス上のMAFアプリケーションでのアプリケーション・トランスポート・セキュリティの無効化

このリリースのMAFに移行するMAFアプリケーションでは、ATSがデフォルトで有効になります。MAFアプリケーションのATSを次のように無効化できます。

  1. JDeveloperで、「アプリケーション」「アプリケーション・プロパティ」「デプロイメント」を選択します。

  2. 「デプロイメント」ページで、iOSデプロイメント・プロファイルをダブルクリックします。

  3. 「iOSオプション」を選択します。

  4. 「アプリケーション・トランスポート・セキュリティの無効化」を選択して「OK」をクリックします。

SSL構成の変更

TLS 1.2未満のSSLバージョン、非推奨の暗号化スイートまたは非推奨の暗号化アルゴリズムを使用するユーザーには、「invalid cipher suite」「close notify」「TLS error」などのSSLエラーが表示されます。Java 8では、最新のSSLバージョンと暗号化スイートの使用が実施されます。セキュアでないSSLバージョンの使用はデフォルトで無効化されています。新しいSSLバージョンを使用するためにサーバーの更新をお薦めします。これができない場合は、前述したSSLエラーを回避するために次の構成を使用します。

  1. 使用するSSLバージョンを含むようにmaf.propertiesファイルを更新します。たとえば、TLS 1を使用するには次のエントリをmaf.propertiesファイルに追加します。

    java.commandline.argument=-Dhttps.protocols=TLSv1

  2. アプリケーションで必要なすべての暗号化スイートのリストを指定してmaf.propertiesファイルを更新します。Javaでサポートされる暗号化スイートのリストは、このページの暗号化スイートに関する項を参照してください。

    たとえば、SSL_RSA_WITH_RC4_128_MD5を有効にするには、次を追加します。

    java.commandline.argument=-D SSL_RSA_WITH_RC4_128_MD5

  3. 非推奨のアルゴリズムを有効化するようにjava.securityファイルを更新します。既存のMAFアプリケーションにこのファイルを含めることはできないため、新しい空のMAFアプリケーションを作成し、新しいMAFアプリケーションの/resources/securityに作成されたjava.securityファイルを、既存のアプリケーションの同じディレクトリにコピーします。

    たとえば、RC4アルゴリズムは、java.securityファイルの次のエントリに基づいてデフォルトで無効になっています。

    jdk.tls.disabledAlgorithms=SSLv3, RC4, DH keySize < 768

    RC4アルゴリズムを必要とする暗号化スイート(SSL_RSA_WITH_RC4_128_MD5など)を使用すると、実行時にSSL接続を確立する際にエラーがスローされます。これを回避するため、java.securityエントリを次のように変更してRC4アルゴリズムを有効にします。

    jdk.tls.disabledAlgorithms=SSLv3, DH keySize < 768

3.3 MAF 2.2.2とMAF 2.2.0の個別Xcodeインストールの維持

2つのMAF開発環境を作成して、異なるバージョンの2つのXcodeと2つのJDeveloperインスタンスを同じマシンにインストールできます。インストールの後で、使用するバージョンのXcodeを手動でアクティブ化します。JDeveloperは現在アクティブになっているXcodeインスタンスを使用します。

MAF 2.2.2ではXcode 7.xが必要です。1つの開発環境のみ(MAF 2.2.2)を維持する場合は、「XcodeおよびiOS SDKのインストール方法」の説明に従ってXcode 7.xをインストールするかXcode 7.xにアップグレードします。Xcode 7.xのインストールまたはアップグレードを行ったら、必ず起動してライセンス契約を受諾してください。これを行わないと、JDeveloperがMAF 2.2.2アプリケーションのiOSへのデプロイを試行する際にデプロイメント・エラーが発生することがあります。このインストールによってXcode 7.xがXcode 6.xを置換します。JDeveloperはアクティブなXcodeインストールを使用するため他の変更は必要ありません。

MAF 2.2.2 (Xcode 7.xを使用)とMAF 2.2 (Xcode 6.xを使用)のために個別の開発環境を維持する場合、Xcode 6.xとXcode 7.xの両方を同じマシンにインストールし、そこにMAF 2.2とMAF 2.2.2のための個別のJDeveloper環境をインストールします。この作業を行うための情報は、この後に示す手順を参照してください。

サポートされている開発ツールとランタイム・ツールのバージョンの詳細なリストは、MAFドキュメント・ページ(http://www.oracle.com/technetwork/developer-tools/maf/documentation/)の「Certification Information」リンクから「Oracle Mobile Application Framework Certification Matrix」を参照してください。

3.3.1 MAF 2.2.2と2.2.0の個別JDeveloper環境を維持する方法

MAF 2.2.0と2.2.2のために個別のJDeveloper環境を維持するには、次の手順を実行します。
  1. MAFの各バージョンに1つのJDeveloperインスタンスが対応するように、MAF 2.2.2用の新しいJDeveloperインスタンスをインストールします。つまり、MAF 2.2.0用の既存のDeveloperインストールと、次の例に示すMAF 2.2.2用の新しいJDeveloperインストールです。
    /usrdir/Oracle/Middleware/Oracle_Home/maf222/jdeveloper
    

    インストール・ウィザードの「インストール完了」画面で、「次のステップ」フィールドの下の「JDeveloperを開始せずにインストールを終了」ラジオ・ボタンを選択します。JDeveloperを起動する前に、次の手順の説明に従ってjdev.confファイルを構成する必要があります。

  2. インストールの後でMAF 2.2.2用のJDeveloperインスタンスを起動する前に、jdev.confファイルを調べて、新しいインストールのシステム・フォルダが、MAF 2.2.0用の既存JDeveloperインストールで使用されているのとは別の場所を指していることを確認します。Also verify that theまた、jdev.confファイルのSetJavaHome変数がJDK 7を参照していることも確認します。このリリースのMAFではコンパイルのためにJDK 8が必要ですが、「JDeveloperとのMAF拡張機能のインストールの概要」の説明に従って、JDK 7を使用してJDeveloperをインストールします。

    jdev.confファイルは/usrdir/Oracle/Middleware/Oracle_Home/maf222/jdeveloper/jdev/binディレクトリにあります

    次の例は、MAF 2.2.2開発に使用されるJDeveloperインストールのエントリです。MAF 2.2.0の開発に使用したJDeveloperインストールのjdev.confファイルを調べて、MAF 2.2.2インストールのシステム・フォルダには異なる値を使用していることを確認します。

    # Point -Dide.system.dir variable to the folder where JDeveloper extracts its system folder.
    AddVMOption -Dide.system.dir=/usrdir/Oracle/Middleware/Oracle_Home/maf222/jdeveloper
    
    # SetJavaHome variable must point to the JDK 1.7 Home
    SetJavaHome /Library/Java/JavaVirtualMachines/jdk1.7.0_79.jdk/Contents/Home
    

    これらのエントリでは、両方のJDeveloperインストールのシステム・フォルダが別の場所に配置されるため、一方の環境を使用中に別の環境の内容を誤って上書きする可能性がなくなります。

3.3.2 Xcode 7.xとXcode 6.xの個別インストールを維持する方法

Xcode 7.xおよびXcode 6.xの個別インストールを維持するには、次の手順を実行します。
  1. Xcode 6.x用の既存のXcode.appインストールの名前を変更します(たとえばXcode6.app。)
  2. 「XcodeおよびiOS SDKのインストール方法」の説明に従って、Xcode 7.xをApple社のApp Storeからインストールします。更新ではなく、Apple社のApp StoreからXcodeをインストールしてください。
  3. Xcode 7.xをインストールしたら、必ず起動してライセンス契約を受諾してください。
    インストールの後で、次のXcodeインストールがApplicationsの場所にあることを確認します。
    Xcode 7.x installation:
    /Applications/Xcode.app 
    
    Xcode 6.x installation:
    /Applications/Xcode6.app 
  4. Xcodeの2つのバージョンをインストールしてからは、どちらのXcodeインストールをアクティブにするかを常に手動で制御する必要があります。端末ウィンドウでxcode-selectコマンドを使用して、次の例に示すようにこの手順を実行します。
    //To make Xcode 7.x active: 
    sudo xcode-select -s /Applications/Xcode.app
    
    //To make Xcode 6 active: 
    sudo xcode-select -s /Applications/Xcode6.app
    
    //To determine which instance of Xcode is currently active:
    xcode-select --print-path
    

3.4 カスタムURLスキームを使用して他のアプリケーションを起動するMAFアプリケーションの移行

MAF 2.2.2に移行するアプリケーションが、カスタムURLスキームを使用して別のアプリケーションを起動する場合は、maf-application.xmlファイルの概要エディタで「セキュリティ」ページの「許可されるスキーム」リストにスキームを追加します。

この変更は、アプリケーションが他のアプリケーションの起動に使用するすべてのURLスキームを宣言しなければならないというiOS 9の要件に対処するものです。「セキュリティ」ページの「許可されるスキーム」セクションの「追加」アイコンをクリックしてカスタムURLスキームを追加します(図3-1)。

図3-1 MAFアプリケーションが別のアプリケーションの起動に使用するカスタムURLスキームの登録

このイメージについては周囲のテキストで説明しています。

3.5 MAF 2.2.2のJDK 8への移行

MAF 2.1.0以降で作成するMAFアプリケーションは、JDK 8を使用します。JDK 8のインストール場所は、MAF拡張機能をインストールした後でJDeveloperを初めて起動したときに指定します(「JDeveloperへのMAF拡張機能のインストール」を参照)。

以前のバージョンのJavaを使用してコンパイルされたMAFアプリケーションを移行する場合、MAF 2.1.0以降ではJDK 8が必要なことと、Java SE Embedded 8 Compact2プロファイルを使用してアプリケーションがコンパイルされることに注意してください。MAF 2.1.0より前のリリースから移行したアプリケーションをMAF 2.2.2で初めて開くときに、JDeveloperでは次の変更が行われます。

  • JVMの起動パラメータを指定する構成ファイルの名前をcvm.propertiesからmaf.propertiesに変更します。maf.propertiesファイルの詳細は、『Oracle Mobile Application Frameworkでのモバイル・アプリケーションの開発』のJavaコードおよびJavaScriptのデバッグを有効にする方法に関する項を参照してください。

  • アプリケーションのJavaソース・ファイルに記載された次のimport文のインスタンス(ある場合)を置き換えます。

    com.sun.util.logging
    

    置換後:

    java.util.logging
    
  • アプリケーションのlogging.propertiesファイルに記載された次のエントリを置き換えます。

    .handlers=com.sun.util.logging.ConsoleHandler
    .formatter=com.sun.util.logging.SimpleFormatter
    

    置換後:

    .handlers=java.util.logging.ConsoleHandler
    .formatter=java.util.logging.SimpleFormatter
    

    logging.propertiesファイルの詳細は、『Oracle Mobile Application Frameworkでのモバイル・アプリケーションの開発』のプロパティ・ファイルを使用したロギングの構成方法に関する項を参照してください。

3.6 Cordovaプラグインの旧リリースからMAF 2.2.2への移行

以前のリリースのMAF (MAF 2.1.0より前)を使用して開発されたMAFアプリケーションでは、maf-applicationファイルにプラグインが登録されていました。MAF 2.1.0以降のリリースでは、maf-plugins.xmlファイルにプラグインを登録します。アプリケーションの移行時に、JDeveloperでは、プラグインを使用している以前のリリースのアプリケーションに次の変更を加えます。

  • maf-application.xmlファイル内でプラグインを参照していたエントリをコメント・アウトします。たとえば、JDeveloperではエントリを次のようにコメント・アウトします。

    <!--<adfmf:cordovaPlugins>
        <adfmf:plugin fullyQualifiedName="BarcodeScanner"
                      implementationClass="com.phonegap.plugins.
                           barcodescanner.BarcodeScanner" platform="Android"
                                                           name="BarcodeScanner">
      .....
    </adfmf:cordovaPlugins>-->
    
  • 次の例に示すように、maf-plugins.xmlファイルにプラグインを登録します。

    <cordova-plugins>
        ...
        <cordova-plugin id="c3" pluginId="org.apache.cordova.barcodeScanner">
          <platform id="p3" name="ios" enabled="true"/>
          <platform id="p4" name="android" enabled="false"/>
        </cordova-plugin>
      </cordova-plugins>
    

移行を完了して、移行済のMAFアプリケーションで以前使用していたプラグインを確実に使用できるようにするには、次の点を確認します。

  • プラグインのバージョンがMAFによってサポートされていること。

    MAF 2.2.2のアプリケーションは、AndroidではCordova 3.7.2を、iOSではCordova 3.8.0を使用します。

    現在のMAFリリースで使用されるものよりも古いリリースのCordovaを使用してプラグインが作成されている場合は、新しいバージョンのプラグインを取得してください。

  • MAFアプリケーションのmaf-plugins.xmlファイルがプラグインを正しく参照できるように、プラグインへの相対パスが設定されていること。詳細は、『Oracle Mobile Application Frameworkでのモバイル・アプリケーションの開発』のMAFアプリケーションでの追加プラグインの登録に関する項を参照してください。

    maf-plugins.xmlファイルで、相対パスを使用してプラグインを正しく参照していない場合、maf-application.xmlファイルの概要エディタで必須入力フィールドの「パス*」が空になり、maf-plugins.xmlに検証失敗が表示されます(図3-2を参照)。

図3-2 プラグインへのパスが指定されていないMAFアプリケーション

この図は周囲のテキストで説明しています

3.7 ADFモバイル・アプリケーションの移行

MAFでは、ADFモバイルのバージョン11.1.2.3.0および11.1.2.4.0で作成されたアプリケーションの構成が自動的に移行されます。ADFモバイル・アプリケーションのワークスペース(.jws)・ファイルを開くと、MAFでは、「警告」ダイアログ(図3-3を参照)が開いて、アプリケーションが現行バージョンでないという警告が表示され、移行を続行するか、ダイアログを閉じてファイルを閉じるかを選択するように求められます。

図3-3 「警告」ダイアログ

このイメージについては周囲のテキストで説明しています。

MAFでは、移行ステータスが「ログ」ウィンドウに書き込まれます(図3-4 を参照)。移行プロセスで、移行するアプリケーションで古い構成サービスAPIが使用されていることが検出されると、次の警告も記録されます。

The MAF 2.0 Configuration Service API is not backwards compatible with previous
versions and cannot be migrated automatically. Refer to Section 9.3 "Migrating
the Configuration Service API" in Oracle Fusion Middleware Developing Mobile
Applications with Oracle Mobile Application Framework 2.0. for information on
migrating to the new API.

詳細は、『Oracle Mobile Application Frameworkでのモバイル・アプリケーションの開発』の構成サービスの移行に関する項を参照してください。

図3-4 移行ログ

このイメージについては周囲のテキストで説明しています。

3.7.1 ADFモバイル・アプリケーションの移行時に行われる処理

表3-1 に、移行がADFモバイルのアーティファクトにどのような影響を与えるかを示します。


表3-1 ADFモバイルのアーティファクトおよび構成の移行

ファイル名 変更内容

adfmf-feature.xml

移行によって次の変更が行われます。

  • ファイル名がmaf-feature.xmlに変更されます。

  • credentials属性がsecurityEnabled=trueで置換されます。

  • ハイブリッド接続定義(<authenticationMode value="hybrid"/>)として(localremoteのいずれかとして定義されている) credentials属性定義がconnections.xmlファイル内に複写されます。

adfmf-application.xml

移行によって、ファイル名がmaf-application.xmlに変更されます。

connections.xml

移行によって、<policy-references>要素で定義されているセキュアなSOAP Webサービス接続がconnections.xmlファイルから削除されます。これらの定義は、wsm-assembly.xmlファイルに移入されます。ADFモバイル・アプリケーションにconnections.xmlファイルが含まれていない場合、移行ではスタブ・ファイルconnections.xmlおよびwsm-assembly.xmlが作成されます。Webサービス・ポリシー定義を持たないconnections.xmlがADFモバイル・アプリケーションに含まれている場合、移行ではスタブ・ファイルwsm-assemblyが作成されます。

adfmf-config.xml

移行によって、ファイル名がmaf-config.xmlに変更されます。また、スキン・ファミリがデフォルト・スキン・ファミリであり、スキン・バージョンが指定されていない場合、そのスキン・ファミリのデフォルトのスキン・バージョンも追加されます。たとえば、次の値が含まれるようにmaf-config.xmlを変更できます。

<skin-family>mobileAlta</skin-family>  <skin-version>v1.1</skin-version>

adfmf-skins.xml

移行によって、ファイル名がmaf-skins.xmlに変更されます。


アプリケーションがADFモバイル・フレームワーク・テクノロジから移行され、モバイル・アプリケーション・フレームワーク・テクノロジがプロジェクト機能として使用されるようになります。図3-5 に、モバイル・アプリケーション・フレームワーク・テクノロジを使用するアプリケーション・コントローラ・プロジェクトの「機能」ページを示します。「プロジェクト・プロパティ」「機能」を選択して、このダイアログを表示します。

図3-5 モバイル・アプリケーション・フレームワークのプロジェクト機能

このイメージについては周囲のテキストで説明しています。

MAFでは、ADFモバイル・アプリケーションに対して作成されたアイコン、スプラッシュ画面またはナビゲーション・バーのイメージはオーバーライドされず、アプリケーション・コントローラのresourcesファイル内のイメージ・ファイルが保持されます。同様に、アプリケーション機能に使用されるイメージもすべて保持されます。

3.7.1.1 Webサービス・ポリシー定義の移行について

MAFでは、Webサービス・ポリシー定義がwsm-assembly.xmlファイルに格納されます。ADFモバイル・アプリケーションはこの情報をconnections.xmlファイルに格納します。例3-1 は、connections.xmlファイル内の<policy-references>要素によるoracle/wss_username_token_client_policyを示しています。

例3-2 は、wsm-assembly.xmlファイル内に定義されたポリシーを示しています。

例3-1 connections.xmlファイル

<policy-references xmlns="http://oracle.com/adf">policy-reference category="security"
                   uri="oracle/wss_username_token_client_policy"
                   enabled="true"
                   id="oracle/wss_username_token_client_policy" xmlns=""/>
</policy-references>

例3-2 wsm-assembly.xmlファイル

<wsp:PolicyReference xmlns:wsp="http://www.w3.org/ns/ws-policy"                    
                     DigestAlgorithm="http://www.w3.org/ns/ws-policy/Sha1Exc"
                     URI="oracle/wss_username_token_client_policy"
                     orawsp:status="enabled"
                     orawsp:id="2"/>

3.7.2 移行済アプリケーションにおけるFARに関する必知事項

MAFでは、機能アーカイブ(FAR)ファイル内にパッケージ化されたadfmf-feature.xmlファイルは移行されません。移行済アプリケーションで使用されるADFモバイルFARを置換して、FARのmaf-feature.xmlファイル内でcredentials属性がsecurityEnabled=trueで置換されていることを確認します。

アプリケーションの移行後、次の手順を実行します。

  1. 「アプリケーションのプロパティ」→「ライブラリとクラスパス」を選択します。

  2. FARを選択し、「削除」をクリックします。

  3. 移行済ビュー・コントローラが含まれるFARをインポートします。

  4. FARとしてパッケージ化されたビュー・コントローラ・プロジェクトが含まれるADFモバイル・アプリケーションを移行します。

    注意:

    1つのFARにadfmf-feature.xmlファイルとmaf-feature.xmlファイルの両方を含めることはできません。

    1. ビュー・コントローラ・プロジェクトをFARとしてデプロイします。

    2. FARを移行済アプリケーションにインポートします。

FARをアプリケーションにインポートする方法の詳細は、『Oracle Mobile Application Frameworkでのモバイル・アプリケーションの開発』のMAFアプリケーションでのFARコンテンツの使用方法に関する項を参照してください。

3.8 iOSデバイスでフル・スクリーンを使用するための移行済MAFアプリケーションの構成

MAF 2.2.0リリース以降を使用して作成するMAFアプリケーションは、iOS 7以降を実行しているデバイスではデフォルトでフル・スクリーンを使用します。

これは、iOSデバイスのステータス・バーがMAFアプリケーションでレンダリングされるコンテンツの上に表示されることを意味します。図3-6 に示すように、MAFアプリケーションのコンテンツの上にステータス・バーのステータス・アイコンが重ねて表示されます。この状況は、iOSデバイスのステータス・バーの背景が透明なために生じます。図3-6 では、MAFアプリケーションの黄色いパネル・ヘッダー・コンポーネントの上に、ネットワーク、時刻およびバッテリに関するステータス・バーの情報が重ねて表示されています。

iOSデバイスでレンダリングされるステータス・バーは、lightとdarkの2つのスタイルをサポートします。MAFには、iOSデバイスのステータス・バー・スタイルを取得および設定して、MAFアプリケーションが背景にレンダリングするときに適切にレンダリングされるようにするAPIが用意されています。ステータス・バーを暗い背景でMAFアプリケーションにレンダリングする場合は、ステータス・バーにlightスタイルを適用します。ステータス・バーを明るい背景でレンダリングする場合は、ステータス・バーにdarkスタイルを適用します。

MAFには、iOSデバイスでMAFアプリケーションのスタイルを取得および設定するための次のJavaScriptメソッドが用意されています。

adf.mf.api.getStatusBarStyle = function(callback)
adf.mf.api.setStatusBarStyle = function(style, callback)

これらのメソッドの詳細は、Oracle Mobile Application Frameworkタグ・リファレンスを参照してください。

MAFには、MAFアプリケーションでマネージドBeanまたはライフサイクル・リスナーからステータス・バーのスタイルを設定するために使用できる次のJavaメソッドもoracle.adfmf.framework.api.AdfmfContainerUtilitiesに用意されています。

getStatusBarStyle()
setStatusBarStyle(AdfmfContainerUtilities.STATUS_BAR_STYLE color)

これらのメソッドの詳細は、Oracle Mobile Application Framework Java APIリファレンスを参照してください。

MAFアプリケーションは、iOS以外のデバイスではこれらのメソッドを無視します。MAFアプリケーションでのJavaおよびJavaScript APIの使用の詳細は、『Oracle Mobile Application Frameworkでのモバイル・アプリケーションの開発』の付録「ローカルHTMLおよびアプリケーション・コンテナAPI」を参照してください。

図3-6 iOSデバイスでフル・スクリーンを使用したMAFアプリケーション

このイメージについては周囲のテキストで説明しています。

MAF 2.2.2に移行されたMAFアプリケーションは、前述の動作を示しません。かわりに、iOSデバイスのステータス・バーはMAFアプリケーションの上部に表示されます。MAF 2.2.2に移行するMAFアプリケーションを、iOS 8以降を実行しているデバイスでフル・スクリーンを使用するように構成できます。

3.8.1 iOSデバイスのフル・スクリーンを使用するように移行済MAFアプリケーションを構成する方法

maf-config.xmlファイルの<fullscreenLayout>要素を設定することで、MAF 2.2.0以上に移行するMAFアプリケーションを、iOS 8以降を実行しているデバイスでフル・スクリーンを使用するように構成します。

iOSデバイスでフル・スクリーンを使用するように移行済MAFアプリケーションを構成する手順:
  1. 「アプリケーション」ウィンドウで、「アプリケーション・リソース」パネルを開きます。
  2. 「アプリケーション・リソース」パネルでDescriptorsを展開し、ADF META-INFを展開します。
  3. maf-config.xmlファイルをダブルクリックします。
  4. 構造ウィンドウで、adfmf-configノードを右クリックして、「プロパティに移動」を選択します。
  5. 「プロパティ」ウィンドウで、「fullscreenLayout」ドロップダウン・メニューから「fullscreen」を選択します。

3.8.2 iOSデバイスのフル・スクリーンを使用するように移行済MAFアプリケーションを構成した場合の動作

JDeveloperは、移行したMAFアプリケーションのmaf-config.xmlファイルに、次の例に示すエントリを書き込みます。

例3-3 移行したMAFアプリケーションをiOSデバイスのフル・スクリーンにレンダリングするためのmaf-config.xmlの構成

<?xml version="1.0" encoding="UTF-8" ?>
  <adfmf-config xmlns="http://xmlns.oracle.com/adf/mf/config">
   ...
  <fullscreenLayout>fullscreen</fullscreenLayout>
</adfmf-config>

3.9 Androidの戻るボタンを使用してMAFアプリケーションをナビゲートするときのレガシー動作の維持

MAF 2.2.0では、このリリースを使用して作成されたMAFアプリケーションがAndroidシステムの戻るボタンの使用に応答する方法が変更されています。前のリリースで作成し、MAF 2.2.0以降に移行したMAFアプリケーションでは、新しい動作が使用されます。

図3-7は、Billingアプリケーション機能のBilling Page 3ページまで、エンド・ユーザーが3つのアプリケーション機能(Customer、SalesおよびBilling)間をナビゲートする、MAFアプリケーションのナビゲーション・フローを示しています。

図3-7 MAFアプリケーションのアプリケーション機能間のナビゲーション・フロー

このイメージについては周囲のテキストで説明しています。

リリースMAF 2.2.0より前では、エンド・ユーザーがAndroidシステムの戻るボタンをタップした場合のMAFアプリケーションのデフォルト動作は次のとおりでした。

  • Billing Page 3はSalesアプリケーション機能にナビゲートする

  • Salesアプリケーション機能はCustomersアプリケーション機能にナビゲートする

  • CustomerアプリケーションはMAFアプリケーションを終了する

MAF 2.2.0以降では、エンド・ユーザーがAndroidシステムの戻るボタンをタップした場合のMAFアプリケーションのデフォルト動作は次のとおりです。

  • Billing Page 3はBilling Page 2にナビゲートする

  • Billing Page 2はBilling Page 1にナビゲートする

  • Billing Page 1はMAFアプリケーションを休止する

『Oracle Mobile Application Frameworkでのモバイル・アプリケーションの開発』のAndroidの戻るボタンを使用したMAFアプリケーションのナビゲートに関する項の説明に従って、エンド・ユーザーがAndroidシステムの戻るボタンをタップした場合のMAFアプリケーションの動作をカスタマイズできます。

「Androidの戻るボタンの使用に対してMAF 2.2.0より前のアプリケーションの動作を維持する方法」の説明に従ってmaf-config.xmlでプロパティを設定することで、MAF 2.2.0より前のアプリケーションの動作(アプリケーション機能間のナビゲート)を示すようにMAFアプリケーションを構成することもできます。

3.9.1 Androidの戻るボタンの使用に対してMAF 2.2.0より前のアプリケーションの動作を維持する方法

maf-config.xmlファイルのlegacyBack要素を構成して、エンド・ユーザーがAndroidの戻るボタンをタップしたときにMAFアプリケーションがMAF 2.2.0より前の動作を示すようにすることができます。

Androidの戻るボタンの使用に対してMAF 2.2.0より前のアプリケーションの動作を維持する手順:
  1. 「アプリケーション」ウィンドウで、maf-config.xmlファイルをダブルクリックします。
    デフォルトでは、これは、「アプリケーション・リソース」ペインの「ディスクリプタ」および「ADF META-INF」ノードの下にあります。
  2. maf-config.xmlファイルで、例3-4 に示すようにlegacyBack要素の値をtrueに設定します。

例3-4 Androidの戻るボタンの使用に対してMAF 2.2.0より前のアプリケーションの動作を維持するためのlegacyBack要素

<?xml version="1.0" encoding="UTF-8" ?> 
<adfmf-config xmlns="http://xmlns.oracle.com/adf/mf/config">   
   ...   
   <legacyBack>true</legacyBack> 
</adfmf-config>

3.10 MAF 2.2.2の新しいSSL用cacertsファイルへの移行

MAF 2.1.0は、MAFアプリケーションで使用する新しいcacertsファイルを提供しました。エンド・ユーザーのインストール用に公開するMAFアプリケーションにパッケージ化されたcacertsファイルに、エンド・ユーザーがMAFアプリケーションの使用時に接続するHTTPSサーバーと同じCAルート証明書が含まれていることを確認します。

MAFアプリケーションのcacertsファイルにない証明書がHTTPSサーバーに含まれている場合、MAFアプリケーションのcacertsファイルに新しい証明書をインポートする必要があります。同様に、HTTPSサーバーにない証明書がMAFアプリケーションで使用されている場合、MAFアプリケーションが接続するHTTPSサーバーのシステム管理者は、新しい証明書をインポートする必要があります。

MAFアプリケーションのcacertsファイル内の証明書を表示および管理するには、JDK 8のkeytoolユーティリティを使用します。次の例は、JDK 8のkeytoolユーティリティを使用してcacertsファイル内の証明書リストを表示する方法を示しています。

JDK8install/bin/keytool -list -v -keystore dirPathToCacertsFile/cacerts –storepass changeit | grep "Issuer:"

JDK 8のkeytoolユーティリティを使用して証明書を管理する方法の詳細は、http://docs.oracle.com/javase/8/docs/technotes/tools/#securityを参照してください。たとえば、Windowsでkeytoolユーティリティを使用する場合は、http://docs.oracle.com/javase/8/docs/technotes/tools/windows/keytool.htmlを参照してください。UNIXベースのオペレーティング・システムの場合は、http://docs.oracle.com/javase/8/docs/technotes/tools/unix/keytool.htmlを参照してください。

cacertsファイルについて、およびSSLを使用してMAFアプリケーションを保護する方法の詳細は、『Oracle Mobile Application Frameworkでのモバイル・アプリケーションの開発』のSSLのサポートに関する項を参照してください。

例3-5 に、MAF 2.1.0のcacertsファイルに含まれているCAルート証明書の発行者を示します。このファイル内の証明書を管理して、MAFアプリケーションの使用環境の要件を満たすには、JDK 8のkeytoolユーティリティ(前述)を使用します。

例3-5 MAF 2.1.0用cacertsファイル内のCAルート証明書の発行者

Issuer: CN=DigiCert Assured ID Root CA, OU=www.digicert.com, O=DigiCert Inc, C=US
Issuer: CN=TC TrustCenter Class 2 CA II, OU=TC TrustCenter Class 2 CA, O=TC TrustCenter GmbH, C=DE
Issuer: EMAILADDRESS=premium-server@thawte.com, CN=Thawte Premium Server CA, OU=Certification Services Division, O=Thawte Consulting cc, L=Cape Town, ST=Western Cape, C=ZA
Issuer: CN=SwissSign Platinum CA - G2, O=SwissSign AG, C=CH
Issuer: CN=SwissSign Silver CA - G2, O=SwissSign AG, C=CH
Issuer: EMAILADDRESS=server-certs@thawte.com, CN=Thawte Server CA, OU=Certification Services Division, O=Thawte Consulting cc, L=Cape Town, ST=Western Cape, C=ZA
Issuer: CN=Equifax Secure eBusiness CA-1, O=Equifax Secure Inc., C=US
Issuer: CN=SecureTrust CA, O=SecureTrust Corporation, C=US
Issuer: CN=UTN-USERFirst-Client Authentication and Email, OU=http://www.usertrust.com, O=The USERTRUST Network, L=Salt Lake City, ST=UT, C=US
Issuer: EMAILADDRESS=personal-freemail@thawte.com, CN=Thawte Personal Freemail CA, OU=Certification Services Division, O=Thawte Consulting, L=Cape Town, ST=Western Cape, C=ZA
Issuer: CN=AffirmTrust Networking, O=AffirmTrust, C=US
Issuer: CN=Entrust Root Certification Authority, OU="(c) 2006 Entrust, Inc.", OU=www.entrust.net/CPS is incorporated by reference, O="Entrust, Inc.", C=US
Issuer: CN=UTN-USERFirst-Hardware, OU=http://www.usertrust.com, O=The USERTRUST Network, L=Salt Lake City, ST=UT, C=US
Issuer: CN=Certum CA, O=Unizeto Sp. z o.o., C=PL
Issuer: CN=AddTrust Class 1 CA Root, OU=AddTrust TTP Network, O=AddTrust AB, C=SE
Issuer: CN=Entrust Root Certification Authority - G2, OU="(c) 2009 Entrust, Inc. - for authorized use only", OU=See www.entrust.net/legal-terms, O="Entrust, Inc.", C=US
Issuer: OU=Equifax Secure Certificate Authority, O=Equifax, C=US
Issuer: CN=QuoVadis Root CA 3, O=QuoVadis Limited, C=BM
Issuer: CN=QuoVadis Root CA 2, O=QuoVadis Limited, C=BM
Issuer: CN=DigiCert High Assurance EV Root CA, OU=www.digicert.com, O=DigiCert Inc, C=US
Issuer: EMAILADDRESS=info@valicert.com, CN=http://www.valicert.com/, OU=ValiCert Class 1 Policy Validation Authority, O="ValiCert, Inc.", L=ValiCert Validation Network
Issuer: CN=Equifax Secure Global eBusiness CA-1, O=Equifax Secure Inc., C=US
Issuer: CN=GeoTrust Universal CA, O=GeoTrust Inc., C=US
Issuer: OU=Class 3 Public Primary Certification Authority, O="VeriSign, Inc.", C=US
Issuer: CN=thawte Primary Root CA - G3, OU="(c) 2008 thawte, Inc. - For authorized use only", OU=Certification Services Division, O="thawte, Inc.", C=US
Issuer: CN=thawte Primary Root CA - G2, OU="(c) 2007 thawte, Inc. - For authorized use only", O="thawte, Inc.", C=US
Issuer: CN=Deutsche Telekom Root CA 2, OU=T-TeleSec Trust Center, O=Deutsche Telekom AG, C=DE
Issuer: CN=Buypass Class 3 Root CA, O=Buypass AS-983163327, C=NO
Issuer: CN=UTN-USERFirst-Object, OU=http://www.usertrust.com, O=The USERTRUST Network, L=Salt Lake City, ST=UT, C=US
Issuer: CN=GeoTrust Primary Certification Authority, O=GeoTrust Inc., C=US
Issuer: CN=Buypass Class 2 Root CA, O=Buypass AS-983163327, C=NO
Issuer: CN=Baltimore CyberTrust Code Signing Root, OU=CyberTrust, O=Baltimore, C=IE
Issuer: OU=Class 1 Public Primary Certification Authority, O="VeriSign, Inc.", C=US
Issuer: CN=Baltimore CyberTrust Root, OU=CyberTrust, O=Baltimore, C=IE
Issuer: OU=Starfield Class 2 Certification Authority, O="Starfield Technologies, Inc.", C=US
Issuer: CN=Chambers of Commerce Root, OU=http://www.chambersign.org, O=AC Camerfirma SA CIF A82743287, C=EU
Issuer: CN=T-TeleSec GlobalRoot Class 3, OU=T-Systems Trust Center, O=T-Systems Enterprise Services GmbH, C=DE
Issuer: CN=VeriSign Class 3 Public Primary Certification Authority - G5, OU="(c) 2006 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US
Issuer: CN=T-TeleSec GlobalRoot Class 2, OU=T-Systems Trust Center, O=T-Systems Enterprise Services GmbH, C=DE
Issuer: CN=TC TrustCenter Universal CA I, OU=TC TrustCenter Universal CA, O=TC TrustCenter GmbH, C=DE
Issuer: CN=VeriSign Class 3 Public Primary Certification Authority - G4, OU="(c) 2007 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US
Issuer: CN=VeriSign Class 3 Public Primary Certification Authority - G3, OU="(c) 1999 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US
Issuer: CN=XRamp Global Certification Authority, O=XRamp Security Services Inc, OU=www.xrampsecurity.com, C=US
Issuer: CN=Class 3P Primary CA, O=Certplus, C=FR
Issuer: CN=Certum Trusted Network CA, OU=Certum Certification Authority, O=Unizeto Technologies S.A., C=PL
Issuer: OU=VeriSign Trust Network, OU="(c) 1998 VeriSign, Inc. - For authorized use only", OU=Class 3 Public Primary Certification Authority - G2, O="VeriSign, Inc.", C=US
Issuer: CN=GlobalSign, O=GlobalSign, OU=GlobalSign Root CA - R3
Issuer: CN=UTN - DATACorp SGC, OU=http://www.usertrust.com, O=The USERTRUST Network, L=Salt Lake City, ST=UT, C=US
Issuer: OU=Security Communication RootCA2, O="SECOM Trust Systems CO.,LTD.", C=JP
Issuer: CN=GTE CyberTrust Global Root, OU="GTE CyberTrust Solutions, Inc.", O=GTE Corporation, C=US
Issuer: OU=Security Communication RootCA1, O=SECOM Trust.net, C=JP
Issuer: CN=AffirmTrust Commercial, O=AffirmTrust, C=US
Issuer: CN=TC TrustCenter Class 4 CA II, OU=TC TrustCenter Class 4 CA, O=TC TrustCenter GmbH, C=DE
Issuer: CN=VeriSign Universal Root Certification Authority, OU="(c) 2008 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US
Issuer: CN=GlobalSign, O=GlobalSign, OU=GlobalSign Root CA - R2
Issuer: CN=Class 2 Primary CA, O=Certplus, C=FR
Issuer: CN=DigiCert Global Root CA, OU=www.digicert.com, O=DigiCert Inc, C=US
Issuer: CN=GlobalSign Root CA, OU=Root CA, O=GlobalSign nv-sa, C=BE
Issuer: CN=thawte Primary Root CA, OU="(c) 2006 thawte, Inc. - For authorized use only", OU=Certification Services Division, O="thawte, Inc.", C=US
Issuer: CN=Starfield Root Certificate Authority - G2, O="Starfield Technologies, Inc.", L=Scottsdale, ST=Arizona, C=US
Issuer: CN=GeoTrust Global CA, O=GeoTrust Inc., C=US
Issuer: CN=Sonera Class2 CA, O=Sonera, C=FI
Issuer: CN=Thawte Timestamping CA, OU=Thawte Certification, O=Thawte, L=Durbanville, ST=Western Cape, C=ZA
Issuer: CN=Sonera Class1 CA, O=Sonera, C=FI
Issuer: CN=QuoVadis Root Certification Authority, OU=Root Certification Authority, O=QuoVadis Limited, C=BM
Issuer: CN=AffirmTrust Premium ECC, O=AffirmTrust, C=US
Issuer: CN=Starfield Services Root Certificate Authority - G2, O="Starfield Technologies, Inc.", L=Scottsdale, ST=Arizona, C=US
Issuer: EMAILADDRESS=info@valicert.com, CN=http://www.valicert.com/, OU=ValiCert Class 2 Policy Validation Authority, O="ValiCert, Inc.", L=ValiCert Validation Network
Issuer: CN=AAA Certificate Services, O=Comodo CA Limited, L=Salford, ST=Greater Manchester, C=GB
Issuer: CN=America Online Root Certification Authority 2, O=America Online Inc., C=US
Issuer: CN=AddTrust Qualified CA Root, OU=AddTrust TTP Network, O=AddTrust AB, C=SE
Issuer: CN=KEYNECTIS ROOT CA, OU=ROOT, O=KEYNECTIS, C=FR
Issuer: CN=America Online Root Certification Authority 1, O=America Online Inc., C=US
Issuer: CN=VeriSign Class 2 Public Primary Certification Authority - G3, OU="(c) 1999 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US
Issuer: CN=AddTrust External CA Root, OU=AddTrust External TTP Network, O=AddTrust AB, C=SE
Issuer: OU=VeriSign Trust Network, OU="(c) 1998 VeriSign, Inc. - For authorized use only", OU=Class 2 Public Primary Certification Authority - G2, O="VeriSign, Inc.", C=US
Issuer: CN=GeoTrust Primary Certification Authority - G3, OU=(c) 2008 GeoTrust Inc. - For authorized use only, O=GeoTrust Inc., C=US
Issuer: CN=GeoTrust Primary Certification Authority - G2, OU=(c) 2007 GeoTrust Inc. - For authorized use only, O=GeoTrust Inc., C=US
Issuer: CN=SwissSign Gold CA - G2, O=SwissSign AG, C=CH
Issuer: CN=Entrust.net Certification Authority (2048), OU=(c) 1999 Entrust.net Limited, OU=www.entrust.net/CPS_2048 incorp. by ref. (limits liab.), O=Entrust.net
Issuer: OU=ePKI Root Certification Authority, O="Chunghwa Telecom Co., Ltd.", C=TW
Issuer: CN=Global Chambersign Root - 2008, O=AC Camerfirma S.A., SERIALNUMBER=A82743287, L=Madrid (see current address at www.camerfirma.com/address), C=EU
Issuer: CN=Chambers of Commerce Root - 2008, O=AC Camerfirma S.A., SERIALNUMBER=A82743287, L=Madrid (see current address at www.camerfirma.com/address), C=EU
Issuer: OU=Go Daddy Class 2 Certification Authority, O="The Go Daddy Group, Inc.", C=US
Issuer: CN=AffirmTrust Premium, O=AffirmTrust, C=US
Issuer: CN=VeriSign Class 1 Public Primary Certification Authority - G3, OU="(c) 1999 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US
Issuer: OU=Security Communication EV RootCA1, O="SECOM Trust Systems CO.,LTD.", C=JP
Issuer: OU=VeriSign Trust Network, OU="(c) 1998 VeriSign, Inc. - For authorized use only", OU=Class 1 Public Primary Certification Authority - G2, O="VeriSign, Inc.", C=US
Issuer: CN=Go Daddy Root Certificate Authority - G2, O="GoDaddy.com, Inc.", L=Scottsdale, ST=Arizona, C=US