パート3: モバイル・アプリケーションの構築
ここまでのチュートリアルで、A-Team Persistence AcceleratorのインストールとRESTサービスの作成およびデプロイの手順についての説明が終了しました。

このパートでは、Persistence Acceleratorのウィザードを実行し、RESTサービスにアクセスするJavaオブジェクトを作成し、作成されたJavaクラスからデータ・コントロールを作成します。続いて、オンライン・アクセスとオフライン・アクセスの両方をサポートするサービスをベースにしたデフォルト・ユーザー・インタフェースを作成します(オンラインの場合はこのサービスを介して永続データにオンライン・アクセスし、オフラインの場合はSQLiteデータベースを使用します)。デバイスがオンラインに戻ったら、オンボードのデータベースに含まれる変更を、サービスを介してリモート・サーバーへ同期できます。


ステップ1:RESTサービスへアクセスするJavaクラスの作成

    このパートでは、Persistence Acceleratorを使用して、デプロイ済みのREST Webサービスにアクセスするためのオブジェクトを作成し、オンライン・モードとオフライン・モードのCRUD機能を設定します。

  1. New GalleryからGeneralカテゴリを開き、「Applications」ノードを選択します。
    Mobile Application Framework Application」アイテムをダブルクリックして新規アプリケーションを作成します。

    alt text
  2. ウィザードで、アプリケーション名にHRRest_MAFを指定し、「Finish」をクリックします。

    alt text
  3. 次は、このモバイル・アプリケーションに、REST Webサービスにアクセスするためのビジネス・オブジェクトを作成します。

    Applicationsウィンドウで、「ViewController」プロジェクトを選択してNew Galleryを起動します。「Business Tier」カテゴリを展開して「Mobile Application Framework」カテゴリを選択します。次に、「MAF Business Objects From REST Web Service」アイテムをダブルクリックします。

    alt text
  4. ウィザードが起動するので、このウィザードを使用して、REST Webサービスに対してデータの読取り/書込みを行うクラスを作成します。アプリケーションがオフラインになった場合は、後でデータを同期できるように、デバイスにローカルに格納されているSQLiteデータベースにデータが保存されます。

    注:このウィザードを実行すると、モバイル・デバイス上にデータを格納するモバイル・アプリケーションが作成されます。これには潜在的なセキュリティ・リスクがあります。デバイスを紛失したり盗難に遭ったりした場合に、データが他人の手に渡り悪用される可能性があります。また、デバイスを廃棄する場合や所有者がアプリケーションにアクセスしなくなった場合について、その対処方法に関するポリシーを定義しておくことが賢明と言えるでしょう。オンデバイスのSQLiteデータベースに格納されるのは暗号化されたデータのみですが、特定のデータ・オブジェクト、または個々の属性はオンデバイス・ストレージから除外することをお薦めします。

    最初のステップで「Next」をクリックし、「I acknowledge the security risk」チェック・ボックスを選択します。

    次に、「Next」を再度クリックします。

    alt text
  5. Step 3では、ウィザードで使用するREST接続を指定します。緑色のプラス記号「alt text」をクリックして新しい接続を作成します。

    alt text
  6. Create REST Connectionダイアログで、NameプロパティをHRRESTConnに設定し、URL Endpointhttp://:7101/HRRest/persistence/v1.0/Model-1に設定します。

    これは、RESTサービスにアクセスするためのURLの最初の部分で、使用される段階で、すべてのリソースがこれに追加されます。「Test Connection」ボタンをクリックしても、渡されるリソースがないため、テストは失敗します。

    OK」をクリックします。

    alt text
  7. Step 3に戻ります。新しい接続が選択された状態になり、ソースURIが表示されています。

    Next」をクリックします。

    alt text
  8. Step 4では、使用するリソースを指定します。このチュートリアルでは、departmentリソースとemployeeリソースを使用します。このページで指定するリソースは、アプリケーションで作成および使用するデータ・オブジェクトの候補を識別するためにのみ使用されます。さまざまな読取り/書込み操作に使用する必要があるリソースそのものは、この後のステップで指定します。ここに入力した値は、後ほどウィザードでリソースを“すべて検索”する際のデフォルト値としてのみ使用されます。

    Add」ボタンをクリックしてリソースを作成します。作成するのは次の2つのリソースです。
    1:Resource = /query/Department.findAllMethod = GET(HRスキーマのすべての部門を取得するため)
    2:Resource = /entity/Department/{id}/employeesList1Method = GET(特定の部門IDのすべての従業員のリストを表示するため)

    alt text

  9. ペイロードがXMLではなくJSON形式で返されるようにするために、ヘッダー・パラメータも指定します。そのためには、「Set Headers」ボタンをクリックします。

    Add」ボタンをクリックし、NameContent-Typeに設定し、Valueapplication/jsonに設定します。

    OK」をクリックします。

    alt text
  10. 次に、「Next」をクリックします。各リソースが起動され、返されたペイロードが解析されます。従業員のリストなど、データのコレクションが返された場合は、コレクション内の最初のアイテムが調査され、その属性がデータ・オブジェクトの候補として使用されます。

    パラメータを使用するリソースの場合は、パラメータの値を入力できるようにポップアップ・ダイアログが表示されます。
    employeesList1リソースには部門IDが必要であるため、表示されたポップアップでidプロパティに10を入力し、「OK」をクリックします。

    alt text
  11. 次のStep 5では、含めるオブジェクトと永続化するデータを決定します。ペイロードに含まれている関係のリンク情報にはデータ・オブジェクトが不要なため、これらのデータ・オブジェクトの「Select」チェック・ボックスの選択を解除します。

    また、Javaクラスが適切な単数のクラス名で生成されるように、departmentデータ・オブジェクトとemployeeデータ・オブジェクトのクラス名を変更します。

    オフライン・モードをサポートするために、Departmentデータ・オブジェクトとEmployeeデータ・オブジェクトの「Persist」チェック・ボックスを両方とも選択します。

    次に、「Next」をクリックします。

    alt text
  12. 次のStep 6では、データ・オブジェクトの表示方法を設定します。 各属性のKeyRequiredNameJava TypeおよびDB Column Typeは、必要に応じて設定または変更できます。機密データを 保持する属性は永続化しないことができ、そのように設定すると、オフライン・モードでアプリケーションを実行した場合は属性値がnullになります。このような属性は通常java.lang.Stringとして表示されるため、普通は属性のJavaタイプを変更する必要があります。ペイロード値が二重引用符で囲まれていない場合は、java.math.BigDecimalとして表示される属性もあります。

    すべての属性が永続化されるように、ウィザードでDepartmentデータ・オブジェクトの値を設定し、departmentIdRequiredKeyも設定します。

    alt text

     

  13. 引き続きStep 6Employeeオブジェクトを選択し、employeeIdRequired属性とKeyに設定します。次に、hireDatejava.util.Dateに設定します。

    Next」をクリックします。

    alt text
  14. Step 7では、既存のデータ・オブジェクトから親/子関係を確立することができます。ここでは、次の2つの親/子関係を作成します。
    1:部門に勤務するすべての従業員を表示するための、DepartmentからEmployeeへの関係
    2:部門を管理する従業員の名前を表示するための、EmployeeからDepartmentへの関係

    Department/Employeeの関係を作成するために、緑色のプラス記号をクリックし、ポップアップで次のプロパティを設定します。
    Parent Data Object = Department
    Child Data Object = Employee
    Child Accessor Attribute = employees

    Child Accessor Resourceはデフォルトのままにします。

    OK」をクリックします。

    alt text
  15. 今度は、この関係に属性マッピングを定義する必要があります。下の図を見てわかるとおり、employeeデータ・オブジェクトにはdepartmentId属性がありません。しかし、オフライン・モードでの実行中に1対多関係をリストアできるようにするには、この属性が必要です。つまり、ベースとなるDepartment表とEmployees表の間に外部キー・リレーションシップを設定する必要があります(ただし、このリレーションシップは、初めてアプリケーションを起動したときに永続性ランタイム・コードによって作成されます)。

    親属性としてdepartmentIdを選択し、「Add」ボタンをクリックします。すると、2つのことが実行されます。departmentIdが関係の親側として移動され、関係の子側をサポートするためのemployeeにdepartmentIdが追加されます。

    departmentにemployeeの詳細を問い合わせるときには、RESTペイロードにこの属性は含まれませんが、employeeの詳細が取得されるdepartmentインスタンスに基づいて、永続性ランタイム・コードによってこの属性(およびベースになっている列値)が移入されます。

    alt text
  16. 次に、管理している部門とともにマネージャーの名前を表示する関係を追加します。

    再度、緑色のプラス記号をクリックし、New Parent-Child Accessorポップアップで次のプロパティを設定します。

    Parent Data Object = Employee
    Child Data Object = Department
    Child Accessor Resource = /query/Department.findAll
    Parent Accessor Resource = /entity/Department/{id}/employees1
    Parent Accessor Attribute = manager

    今度は、子アクセッサではなく親アクセッサを定義します。なぜなら、departmentデータ・オブジェクトにはgetManagerメソッドが必要だからです。ユーザー・インタフェースには従業員が管理する部門のリストを表示しないため、employeeデータ・オブジェクトにgetManagedDepartmentsメソッドは必要ありません。つまり実際には、親リソースと子リソースの両方またはいずれかを指定する必要があるかどうかは、ユーザー・インタフェース要件によって異なります。UI要件が(まだ)はっきりしない場合は、安全策として両方のアクセッサを定義することができます。関連付けられたRESTリソースが永続性ランタイムによって起動されるのは、ユーザー・インタフェースからデータが実際に要求された場合のみです。

    OK」をクリックします。

    alt text
  17. Parent-Child Accessorsダイアログに戻り、employeeId属性を選択して「Add」ボタンをクリックします。すると、前回と同様に2つのことが実行されます。employeeIdが関係の親側として移動され、関係の子側をサポートするためのdepartmentにEmployeeIdが追加されます。

    Next」をクリックします。

    alt text
  18. Step 8では、データ・オブジェクト上で実行する永続リソースを決定します。
    DepartmentServiceサービス・オブジェクトについては、次のプロパティを設定します。

    Create Resource = /entity/Department POST(ドロップダウン・リストから選択)
    Update Resource = /entity/Department POST(ドロップダウン・リストから選択)
    Merge Resource = /entity/Department POST(ドロップダウン・リストから選択)
    Delete Resource = /entity/Department/{id} DELETE(ドロップダウン・リストから選択)
    Sort Order = departmentName

    alt text
  19. 次に、EmployeeServiceオブジェクトを選択し、次のプロパティを設定します。

    Create Resource = /entity/Employee POST(ドロップダウン・リストから選択)
    Update Resource =/entity/Employee POST(ドロップダウン・リストから選択)
    Merge Resource =/entity/Employee POST(ドロップダウン・リストから選択)
    Delete Resource = /entity/Employee/{id} DELETE(ドロップダウン・リストから選択)
    Sort Order = lastName
    Payload Date Format = yyyy-MM-dd'T'HH:mm:ssZ
    Payload DateTime Format = yyyy-MM-dd'T'HH:mm:ssZ

    Next」をクリックします。

    注:ユーザー・インタフェースからすべての従業員に直接アクセスできる必要がある場合は、ここでFind All Resourceを追加(/query/Employee.findAllを指定)できます。日付/日時の形式が、ペイロードに含まれるデータの属性の形式と一致している必要があることにも注意してください。Sort Orderフィールドには、カンマ区切りの属性名リストを定義できます。属性名に”desc”という接尾辞を付けると、属性を降順にソートできます。ここで指定したソート順が、ユーザー・インタフェースでのデフォルトの順序になります。永続性ランタイム・コードを使用すると、ソート順を実行時に変更するUIコントロールを簡単に追加できます。

    alt text
  20. ウィザードのStep 9では、Step 8で定義したさまざまなRESTリソースのパラメータとその値を指定できます。ウィザードには有用なデフォルト機能がいくつか用意されていますが、それらのデフォルトが特定の状況においても意味をなすかどうかは確認する必要があります。

    前のページでRESTリソースを指定するときに使用したパス・パラメータ(中かっこで囲んだ部分)が、あらかじめ表示されます。Addボタンを使用すると、他の問合せパラメータを追加できます。POST、PUTまたはPATCHを実行するRESTリソースでは通常、パラメータは使用されず、代わりにデータがペイロードのJSONオブジェクトまたはJSON配列として送信されます。そのようなケースでは、「Send Serialized Data Object as Payload」チェック・ボックスを選択する必要があります。

    チュートリアルのシナリオでは、値の検査以外に何も実行する必要はありません。

    alt text

    リソース・パラメータの値は、このウィザードで選択したValue Providerに基づいて永続性ランタイムによって自動的に移入されます。

    - DataObjectAttribute:データ・オブジェクト属性の値がパラメータに移入されます。この値プロバイダを使用する場合は、隣の列のドロップダウン・リストを使用して属性名を設定する必要があります。ドロップダウン・リストに属性が表示されるデータ・オブジェクトは、使用するリソースによって決まります。たとえば、上のリソースの場合は、部門に属する従業員が返されます。つまり、従業員リストのコンテキストを設定する属性をdepartmentデータ・オブジェクトから選択することが前提となっています。

    - SerializedDataObject:永続化されるべきデータを専用のパラメータで送信する必要がある場合は、この設定を選択します。この値プロバイダを使用する場合は、他の列を空のままにしておく必要があります。

    - LiteralValue:Literal Value列に指定したリテラル値がパラメータに移入されます。

    - ELExpression:EL式を評価して取得された値がパラメータに移入されます。EL式はLiteral Value列に指定します。使用するEL式には任意の有効範囲(applicationScope、pageFlowScope、viewScope、deviceScope、preferenceScope)を設定できますが、RESTサービス・コールの実行コンテキスト内での式の有効性は、設定者自身が確保する必要があります。ただし、オフライン・モードでトランザクションを実行した場合は、後からRESTサービスが起動され、EL式のコンテキストは、データの同期化をトリガーしたタスク・フローおよびページによってその時点で決定されます。

    - SearchValue:ユーザー・インタフェースに入力されたクイック検索値の値がパラメータに移入されます。通常は、Step 8で定義できるQuick Search Resourceにのみ、この値プロバイダを使用します。

  21. Next」、「Finish」の順にクリックしてウィザードを完了します。

    ウィザードで設定した値から作成されたクラスとファイルが、ログ・ウィンドウに表示されます。

    alt text
  22. Applicationsウィンドウは、次の図のように、application.modelapplication.model.serviceクラスを含んだ状態になります。

    すべての作業内容を保存します。

    alt text
  23. Androidエミュレータでアプリケーションをテストする場合は、プロパティを1つ設定する必要があります。

    このプロパティを設定するには、Applicationsウィンドウで「ApplicationController」→「Application Sources」→「META-INF」の順に展開してpersistence-mapping.xmlファイルを開きます。

    検索領域を使用してshowWebServiceInvocationErrorsプロパティを探し、falseに設定します。

    すべての作業内容を保存します。

    alt text
  24. MAF UIの開発時にこれらのクラスを選択可能にする最後の手順として、データ・コントロールを作成します。

    DepartmentServiceからデータ・コントロールを作成するには、これを右クリックして「Create Data Control」を選択します。

    Create Bean Data Controlウィザードが表示されるので、すべてデフォルトのまま「Next」をクリックし、「Finish」をクリックします。

    alt text
  25. ウィザードが終了したら、Data Controlsウィンドウを開いて新しいデータ・コントロールを確認します。DepartmentServiceノードを開き、選択可能なすべてのリソースを確認します。リフレッシュ・ボタン(青いサークル矢印)をクリックしないと、すべてのデータ・コントロールが表示されない場合があります。

    すべての作業内容を保存します。

    alt text

  26. これで、モバイル・ユーザー・インタフェースを構築する準備が整いました。構築作業は、DepartmentServiceデータ・コントロールをドラッグ・アンド・ドロップする方法でも、永続性拡張に付属するMAFユーザー・インタフェース・ジェネレータ・ウィザードを使用する方法でもできます。ウィザードを使用すると、すべてのCRUD操作とデータの同期化機能をテストできるデフォルト・ユーザー・インタフェースをすばやく生成できます。下の入門ガイドの項では、ユーザー・インタフェースの作成について、ドラッグ・アンド・ドロップを使用する方法とウィザードを使用する方法の両方に関する詳しい情報の参照先を紹介しています。

ステップ2:MAFユーザー・インタフェース・ジェネレータによるデフォルトのモバイル機能とコンテンツの作成

この項では、DepartmentService RESTサービスを使用してCRUD操作を実行できるMAFユーザー・インタフェースを作成します。

  1. Applicationsウィンドウで「ViewController」プロジェクトを右クリックし、コンテキスト・メニューから「New」→「From Gallery...」の順に選択します。

    alt text

  2. New GalleryClient Tierノードを開き、「Mobile Application Framework」カテゴリを選択し、「MAF User Interface Generator」をダブルクリックします。

    alt text
  3. Step 1では、「Next」をクリックして続行します。

    Step 2では、UIに使用するデータ・コントロールを選択します。Data Controlプロパティには、デフォルトでこの新たに作成したDepartmentServiceデータ・コントロールが移入されます。

    別のデータ・コントロールに基づくUIを生成する場合は、ここでそれを選択します。値をDepartmentServiceに設定したまま「Next」をクリックします。

    alt text
  4. Step 3では、生成されるページに表示する項目を、各種データ・オブジェクトに基づいて指定します。

    Departmentデータ・オブジェクトには次のプロパティを設定し、フィールドが表示される場所を決定します。UIが生成された後は、いつでもページをカスタマイズできます。

    Display Title Plural = Departments
    Main Left
    = departmentName
    Main Right = departmentId

    次は、Employeeデータ・オブジェクトに切り替えます。

    alt text
  5. 「Data Object」フィールドをクリックしてEmployeeデータ・オブジェクトを選択します。次のプロパティを設定します。

    Display Title Plural = Employees
    Main Left
    = lastName
    Main Right = firstName
    Sub Left = email
    Sub Right = phoneNumber

    alt text
  6. Finish」をクリックしてウィザードを完了します。新しいタスク・フローがエディタで開かれ、この新たに作成したページがApplicationsウィンドウに表示されます。

    データ・オブジェクトごとにリストとフォーム・ページ(断片)が生成され、親データ・オブジェクトのフォーム・フィールドと同じページに子データ・オブジェクトのリストを含める必要があるかどうかを構成できます。生成されたユーザー・インタフェースは携帯電話でのレンダリング用に最適化されていますが、ターゲット・デバイスが(ミニ)タブレットの場合は、他のスクリーン資産を活用できるように簡単に変更できます。

    Save」をクリックしてすべての作業内容を保存します。

    alt text

    alt text



ステップ3:ユーザー・インタフェースのデプロイとテスト

RESTサービスがデプロイされたので、定義したデータ・オブジェクトと作成したUIをデプロイし、エミュレータ上でUIをテストします。アプリケーションをデプロイする前に、使用するエミュレータが稼働していることを確認します。

  1. JDeveloperのメニューから「Application」→「New Deployment Profile...」の順に選択します。

    alt text

  2. Androidエミュレータ上でアプリケーションが実行されるところを確認するため、Create Deployment ProfileダイアログでProfile TypeMAF for Androidに設定し、Deployment Profile NameHRRESTに設定します。iOSシミュレータを使用する場合は、Profile TypeをMAF for iOSに設定します。

    OK」をクリックし、再度「OK」をクリックしてプロファイルを作成します。

    alt text

  3. Androidエミュレータが稼働していることを確認します。

    次に、メニューから「Application」→「HRREST」の順に選択します。

    Deployment Actionダイアログで「Deploy application to emulator」を選択して「Finish」をクリックします。

    alt text

  4. アプリケーションがデプロイされたら、HRRest_MAFアイコンを探してクリックします。

    alt text

  5. アプリケーションが開き、部門名でソートされた部門リストが表示されます。

    alt text


  6. Accounting部門をクリックすると、部門の詳細を表示するページにナビゲートされます。また、ページの下部には、従業員のリストが表示されます。表示されるのは、会計部門に勤務する従業員です。

    alt text
  7. ページの左上隅にある青い"小なり"アイコンをクリックし、部門リストに戻ります。

    alt text
  8. 右上隅にある灰色のプラス記号をクリックすると、新しい部門を作成できるページに移動します。

    alt text
  9. departmentIdは移入されるため、departmentNameとしてAdvertising、locationIdとして1700を入力し、ページ右上にあるディスケット・アイコンをクリックします。

    部門はすべてオンデバイスのSQLiteデータベースにも格納されるため、アプリケーションはオフライン・モードで使用できます。更新や新しい部門の追加といった変更をオフライン・モードで実行すると、これらのトランザクションは保留中のデータ同期アクションとして格納されます。この拡張に付属している再利用可能な機能にオーバーフロー・メニューからナビゲートすると、これらの保留中のデータ同期アクションを参照できます。

    alt text
  10. 部門リストに戻り、新しいAdvertising部門がアルファベット順のリストの先頭に表示されていることを確認します。

    alt text
  11. 新しいAdvertising部門をクリックしてこの部門の詳細にナビゲートします。

    右上隅にある、縦に並んだ灰色の3つの点(オーバーフロー・アイコン)をクリックし、ポップアップ・メニューを起動します。このメニューでは、オフラインのときにSQLiteデータベースに格納されたデータをRESTサービス経由でリモート・サーバーと同期するなど、さまざまな操作を実行できます。

    alt text
  12. Delete」テキストをクリックし、部門のリストに戻り、Advertising部門がリストからなくなっていることを確認します。

    alt text
  13. これで、CRUD操作の動作を確認できたため、次はオフライン機能を調査します。

    エミュレータをオフにし、Webサービスを使用できなくします。

    Home」ボタンをクリックし、アプリケーション・アイコンをクリックしてエミュレータのSettingsにアクセスします。Settingsを開き、Airplaneモードをオンにします。

    alt text
  14. 「Home」ボタンをクリックし、HRRest_MAFアプリケーションを探して開きます。

    先ほどと同じようにして新しい部門を作成し、ディスケット・アイコンをクリックして保存します。

    alt text
  15. 次に、アプリケーションに戻り、部門リストのページで、縦に並んだ灰色の3つの点(オーバーフロー・アイコン)をクリックしてポップアップ・メニューを起動します。

    alt text
  16. Pending Sync Actions」を選択すると、実行する必要のあるアクションがリストされます。

    保留中のレコードを選択し、その詳細を確認します。

    alt text

  17. 設定に戻り、Airplaneモードをオフにします。すると、再度、デバイスからネットワークにアクセスできる状態になります。

    次に、アプリケーションに戻り、部門リストで、縦に並んだ灰色の3つの点をクリックして「Synchronize」オプションを選択します。

    注:保留中の同期アクションを明示的に実行しなかった場合は、リモート・コールが初めて発行されたときに、Persistence Acceleratorのランタイムによって自動的に同期アクションが実行されます。そのため、ユーザーは同期を実行する必要があることを覚えておく必要はありません。

    alt text
  18. このメニュー・オプションを選択すると、(SQLiteデータベースに格納されている)新しい部門レコードが取得され、REST/JSONサービスを使用してデータベース・サーバーに送信されます。SQL*PlusでHRスキーマを確認すると、新しいレコードがデータベースに永続化されていることがわかります。

    alt text

    これで、A-Team Persistence Acceleratorの使用に関するチュートリアルは終了です。このチュートリアルでは拡張をインストールし、REST/JSONサービスを作成およびデプロイし、サービスをサポートするJavaオブジェクトをPersistence Acceleratorのウィザードで作成し、MAFユーザー・インタフェースも作成しました。


まとめ

Bookmark Print Expand all | Hide all
Back to top
Copyright © 2015, Oracle and/or its affiliates.All rights reserved.