LoginSignup
0
0

More than 3 years have passed since last update.

[OutSystems]Mobile Developer Specializationのサンプル問題について解説 2/2(#5-#8)

Posted at

各問題を確認し、回答に必要な資料への解説をまとめます。
これまでに試験のサンプル問題を解説した記事では、英語の試験問題を使ってきましたが、今回はダウンロードした時点で日本語版試験があるため、そちらを使います。

全部で8問で、この記事では5問目-8問目が対象。
1問目-4問目

試験問題は、
https://www.outsystems.com/learn/certifications/
の、「Mobile Developer Specialist (OutSystems 11)」項目のリンク「Exam Details (.pdf)」でダウンロードできる資料から。解凍したら、Japaneseフォルダにあるファイルを開いてください。

5 プラグインの使い方

問題は、Camera Pluginを使って写真を撮影し、その結果をデータベースに保存するAction Flowを見て、問題点を指摘するもの。
データベース保存については、「データベースとローカルストレージで情報が一致していること」という要件がありますが、問題文中で同期処理についてはテストして適切であることを確認済みであるとされています。

というわけで、問題となるべき部分はプラグインの利用箇所に絞られます。プラグイン利用時の注意事項を確認してみます。

まず、プラグインは、端末ネイティブの機能を利用するCordova PluginをOutSystemsのモジュールにラップしたものです。Cordova PluginがJavaScriptでインターフェースを提供するため、OutSystemsモジュールはそのインターフェースを更にClient Actionでラップして提供します。

ラッパーモジュールのストラクチャに記載があります。

各プラグインには、ブーリアン型のIsAvailable出力パラメータのあるCheckPluginアクション(CheckCameraPluginhなど)が必要です。これにより、プラグインがターゲットモジュールで使用可能かどうかを確認できます。

端末のHW機能を使うため、端末に該当の機能がなかったり、準備ができていないことが有り、機能を使う前に使える状況か判定するCheck<プラグイン名> Actionを提供することがプラグインに推奨されています。提供されているときは、機能を使う前にこのActionを呼び、結果がTrueであるときのみ利用します。

よって、このCheck Actionの利用について言及している選択肢B「TakePictureアクションを呼び出す前にプラグインが利用可能かどうかをロジックで確認する必要がある。」が正解。

ちなみに、この問題の選択肢CとDが、2021/4現在全く同じになっています。英語版はそうではないので翻訳時のミスと思われます。

6 ListのOnScrollEndingの実装

モバイルアプリケーションのベストプラクティスリストの読み込みを最適化するに記載の内容についての問題です。
端末の計算能力やネットワークの問題があるため、

すべてのレコードを一度に取得するのではなく、必要に応じて取得します。最初は最小限のレコード(たとえば、10レコード)を取得します。ユーザーが下にスクロールしたときに、On Scroll Endingイベントを使用して次のレコード(たとえば、続きの10レコード)を取得します。

という動作にすることが勧められています。大量のデータがあるリストでは、下にスクロールしていくとその場で差分データの取得が行われて表示されることがあると思いますが、あれをOutSystemsでもやります。

この機能は、実はスキャフォールディングでリストを作ると自動実装されます。
Service Stduio上で、画面にLocal StorageのEntityをドラッグ&ドロップすると、List Widgetが配置され、そのOn Scroll Endingイベントのハンドラーに自動的に必要な処理が実装されます。
image.png

処理内容(MaxRecordsは次のデータ取得時に最大何件まで取得するか、IncrementRecordsはMaxRecordsを何件ずつ増やすか):
1. Aggregateの取得が終わっているかを確認。終わっていなければ処理終了
2. 最後に取得したデータの件数 < MaxRecords - IncrementRecordsなら処理終了
3. MaxRecordsをIncrementRecords分だけ増やす
4. Aggregateを再取得する(AggreagateのMax. RecordsプロパティがMaxRecords変数で指定されているため、3.で増やした後のMaxRecordsを取得件数の上限とする)

実際にデータ件数が32のLocal EntityをListに配置して動作確認すると、各値は以下のように変わります。

最下部にスクロールした回数 Aggregateから取得した件数 MaxRecords MaxRecords - IncrementRecords 増やした後のMaxRecords
0 20 20 15 25
1 25 25 20 30
2 30 30 25 35
3 32 35 30 40
4 32 40 35 -

ここまでを前提に、問題文のAction Flowを見ると、上記処理内容の3.に該当する部分が抜けていますね。よって選択肢C「Refresh Dataノードの直前に、MaxRecordsの値を増やすAssignが不足している。」が正解。

7 デバッグ

モバイルアプリケーションを動作確認・デバッグする方法として、ブラウザのプレビューを使う方法と、実機インストールしてで行う方法があります。

ブラウザのプレビューはネイティブアプリの生成や、インストール作業を必要としないため、手軽に動作確認できます。ただし、あくまでプレビューなので実際に端末にインストールしたときには判明する問題を見逃す可能性があり、操作感も違います。更に、プラグインを使ったハードウェアの利用もできません。

よって、選択肢A「モバイルアプリのパフォーマンスとエクスペリエンスをテストする場合、ブラウザのエミュレータが非常に便利である。」は正しくない。

8 アプリの更新

通常、新しいバージョンをPublishすると、アプリがその変更を検知して、更新内容を自動で取り込んでくれます。
ただし、新しいバージョンをビルドして再インストールが必須となる変更がいくつか有り、それを聞いている問題。

新しいビルドをインストールする必要がある場合に記載があります。

アプリ名
アプリのアイコン
アプリのメインカラー
プラグインの外部リソース
モバイルプラットフォームの構成
エントリモジュールまたはその名前
Extensibility Configurationsプロパティ(モバイルプラグインの変更、追加、削除や、ステータスバーの透明度、カスタムアイコン、スプラッシュ画面の変更など)

の変更の場合は再インストールが必要。問題は再インストールしなくても変更が利用できる場合を聞いているので、ここにない変更である選択肢D「アプリのデフォルトホーム画面の変更。」が正解。

ここも2021/4時点では日本語版の選択肢に誤りがあります。選択肢BとCが同じになっている。

他のSpecialization試験のサンプル問題

Architecture Specializationのサンプル問題についてメモ 1/2(#1-#5)
Architecture Specializationのサンプル問題についてメモ 2/2

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0