フォーム デザインの要件

このセクションでは、モバイル アプリでうまく機能するフォームを構築するための貴重なガイドラインを示します。

• 各フォームは、表示メニュー項目を指定する必要があります。
  • 表示メニュー項目の ルート ナビゲーションを許可する プロパティを はい に設定する必要があります。 この設定により、モバイル フレームワークはメニュー項目によって参照されるフォームを開くことができます。
• それぞれのフォームは、表示メニュー項目から直接アクセスする必要があります。
  • アクセシビリティを確認するには、URL 経由でメニュー項目を開きます。 値がメニュー項目のアプリケーション オブジェクト ツリー (AOT) の名前である場合、単純に &mi= を URL に追加します。
  • フォームにこの方法でアクセスするときに、そのフォームが開かないまたは表示されない場合、モバイル アプリケーションでは動作しません。
• データが表示する各フォームには、1 つのマスター ルート データ ソースが必要です。
  • このデータ ソースは、フォーム上の最初のデータ ソースでなければなりません (デザイナーの最上位)。
  • このデータ ソースは、他のデータ ソースに結合してはいけません。
• 各フォームでは、データ ソース フィルターを作業する必要があります。

  • Web クライアントでフォームを開いた後、フィルターの表示ボタンを使用してフィルター ウィンドウを開きます。

    

    その後 フィルター フィールドの追加 をクリックして、マスター ルート データ ソースが、使用可能なフィールドの一覧にあるフィールドのテーブルとして表示されることを確認します。 他のテーブルも表示されますが、マスター ルート データ ソースがこの一覧に表示される必要があります。 それ以外の場合、モバイル アプリケーションは、コンテキストを使用する検索とナビゲーションを有効にしません。

  • 検索中: モバイル アプリケーションは、バックグラウンドでフィルター フレームワークを使用してデータに対してオンライン検索を行います。

  • コンテキストを使用するナビゲーション: モバイル アプリは、最初にメニュー項目からターゲット フォームを開いてから、指定されたレコード コンテキストのみを表示するフィルター フレームワークを使用することで、リストから詳細へのナビゲーション (およびその他のコンテキスト認識ナビゲーション) を可能にします。

  • リストと詳細のナビゲーション: グリッドがフォーム A (リスト フォーム) 上にバインドされているテーブルは、詳細フォーム (フォーム B) 上のマスター ルート データ ソースである必要があります。 ユーザーがフォーム A の一覧でレコードを選択すると、モバイル フレームワークは、レコードを一意に識別するフィルターをフォーム B に適用することによって、レコードのコンテキストで移動します。

デザインの考慮事項

データ メソッドの使用

表示メソッドを使用してページ (リスト タイプ ページおよび詳細タイプ ページの両方) 上にデータを表示することができます。 ただし、表示メソッドを使用する場合、覚えておくべき 2 つのキー ポイントがあります。

• [検索 ]: ユーザーが "オンライン" 検索 (ローカルにキャッシュされたデータの代わりにWebクライアントのデータに対して実行される検索) を実行すると、Webクライアントのフィルタ処理フレームワークがデータ メソッドに対する検索をサポートしないので、検索は表示方法と一致しません。 ただし、ユーザーがローカルにキャッシュされたデータに対する検索を実行すると、レコードがデバイスにキャッシュされた場合、検索は表示方法と一致します。
• [オフライン ] : デバイスがサーバーに接続されていない間にユーザーがデータを作成または更新すると、一時レコードがローカル キャッシュに作成されます。 これらの一時レコードは Web クライアントでまだ処理されていないため、レコードに自動的に入力されるフィールドやサーバー側のビジネス ロジックによる既定のフィールドがある場合、これらのフィールドはレコードが Web クライアントと同期されるまで空白です。 表示メソッドは、一時的なレコードのために空になるフィールドのカテゴリに分類されます。

オフライン用のデザイン

サーバーに密に接続され、サーバー上にオープン フォームを有するオープン ユーザー セッションを維持する Web クライアントとは異なり、モバイル アプリは短いバーストでのみユーザー セッションを生成する (およびフォームを開く)と 同時に、サーバーと同期化します (ページの場合はデータの読み込み、アクションの場合はデータの書込み/更新による)。 サーバーと同期するアクションがなく、ローカル データ キャッシュが最新の場合、ユーザーが明示的にプルをトリガーしない限り、モバイル アプリは、ユーザーがアプリをナビゲートする際に、(ユーザーが明示的にプルして更新しない限り) サーバーと通信しません。 モバイル アプリのページとアクションの設計中に、このデータ フロー パターンに注意することが重要です。 ページが読み込まれるか、アクションが起動するたびにフォームのロジックが実行されるとは限りません。 ユーザーがアクションを実行している間にフォーム ロジックが実行されることを想定する必要はありません。 フォーム ロジックは、アクションがサーバーと同期されている場合にのみ実行されます。 次のリストは、フォーム ロジックの実行にかかる時間のみを示しています。 フォーム ロジックは、モバイル アプリケーションで初めてページを開く前に直接実行されます。

1. ユーザーがまずページを開くと、モバイル アプリが Web クライアントと連絡を取って、関連付けられているフォームを開きます。 このプロセスでは、フォームinitやdata source initなどのロジックは、すべて通常どおり実行されます。
2. モバイル アプリ フレームワークは、フォームのコントロールから必要なデータを直接読み込み、データをモバイル アプリに送り返します。
3. モバイル アプリはデータをキャッシュし、モバイル アプリのページに表示します。
4. ページを開くための更なる試行は、キャッシュされたデータに読み込まれます。 これらの試行は、ユーザーがページを明示的にリフレッシュするか、キャッシュの有効期限が切れない限りフォーム ロジックを再度実行しません。 (現在、キャッシュは 30 分後に期限切れになるように設定されています。)

モバイル アプリケーションからサーバーに送信されたアクションの処理

1. ユーザーがアクションを開いて、そのアクションにデータを入力するとき、どのフォーム ロジックも実行されません。 ユーザーは、オフラインまたはオンラインのいずれかでアクションを完了できます。 どちらの場合も、システムは同じように動作します。
2. ユーザーがアクションの完了/保存をクリックすると、モバイル アプリはデータ同期操作をキューにします。 この操作は、モバイル アプリがインターネットに接続されているときにサーバーと同期されます。
3. インターネット接続 (そのアクションの直後に発生することもあります) が検出されると、モバイル アプリは、処理用のサーバーにデータ同期操作を送信します。
4. サーバー上でオペレーションが処理される間、フレームワークにより関連フォームが開かれ、フォーム コントロールに値を渡すことによりアクションからのデータが入力されます。 このプロセス中、フォーム ロジックは通常の方法 (init、変更、クリックなどはすべて実行) で実行されます。 ただし、この処理が行われている間、モバイル ユーザーがアプリの別の部分に移動した可能性があります。 コントロールを表示 / 非表示するどのフォーム ロジックも、モバイルアプリに表示される UI は無効になります。 したがって、同期時間を最小限に抑えるために、UI ロジックをフォームに含めないことをお勧めします。

既存のフォームのモバイル バージョンの作成

新しいモバイル固有フォームを作成するのではなく、モバイル フレームワークと連携できるように、既存のフォームを変更する場合は、条件付きでモバイル固有のシナリオのフォームの動作を変更する必要があります。 Web クライアント ユーザーがページ/アクションをデザインするセッション中、またはモバイル ユーザーのページ/アクションを読み込むためにモバイル フレームワーク バック エンドが作成したセッション中に、コードにアクセスしているかどうかを決定するために X++ コードでは次の静的 X++ アプリケーション プログラミング インターフェイス (API) を使用することができます。 モバイル デザイナーでフォームを使用している場合

SysTaskRecorderController::isDesigningApp()

モバイル フレームワークのバック エンドでフォームを使用してページを読み込み、アクションを実行する場合

SysTaskRecorderController::isExecutingApp()

フォーム コントロールのサポート

各種の基本データ型 (文字列、日付、および番号) およびグリッドのフォーム コントロールがサポートされます。 ただし、いくつかの一般的なコントロールのサポートは限定されます。 参照グループ ページを設計する場合、参照グループ内のフィールド コントロールは互換性があります。 ただし、アクションをデザインする際に互換性がありません。 いくつかの問題を経験せずにこれらのフィールドを選択することができるかもしれませんが、参照グループはモバイル フレームワークと基本的に互換性がありません。 参照グループを使用しないことをお勧めします。 代わりに、フォームに直接コントロールを追加してから、プロパティ シートを使用して代理外部キー (SFK) に直接コントロールをバインドします。