Power Apps の App オブジェクト

適用先: キャンバス アプリ

現在実行中のアプリに関する情報を取得し、アプリの動作を制御します。

内容

コントロールと同様に、 App オブジェクトには、表示されている画面を識別するプロパティがあり、変更が失われないように変更を保存するように求められます。 すべてのアプリには App オブジェクトがあります。

App オブジェクトの一部のプロパティの数式を記述します。 ツリー ビュー ウィンドウの一番上で、その他のコントロールまたは画面と同じように App オブジェクトを選択します。 オブジェクトのプロパティの 1 つを表示または編集するには、数式バーの左側にあるドロップダウン リストでオブジェクトを選択します。

ActiveScreen プロパティ

ActiveScreen プロパティは、現在表示されている画面を識別します。

このプロパティは画面オブジェクトを返します。 数式 App.ActiveScreen.Name の名前など、現在の画面のプロパティを参照するために使用 します。 このプロパティは、 比較数式 App.ActiveScreen = Screen2 と同様に、別の画面オブジェクトと比較して 、Screen2 が現在の画面かどうかを確認することもできます。

[戻る] または [移動] 機能を使用して、表示される画面を切り替えます。

BackEnabled プロパティ

BackEnabled プロパティは、Power Apps モバイルで実行しているときに、アプリがデバイスの戻るジェスチャに応答する方法を変更します (Android デバイスではハードウェアの戻るボタンをスワイプするか、iOS デバイスでは左からスワイプします)。 有効にすると、デバイスの戻るジェスチャは、最近表示された画面に戻ります。これは Back 数式に 似ています。 無効にすると、デバイスのバック ジェスチャによってユーザーがアプリの一覧に移動します。

ConfirmExit プロパティ

保存されていない変更を失いたい人はいません。 ConfirmExit プロパティと ConfirmExitMessage プロパティを使用して、アプリを閉じる前にユーザーに警告します。

ConfirmExit

ConfirmExit はブール型のプロパティで、 true の場合、アプリを閉じる前に確認ダイアログ ボックスを開きます。 既定では、このプロパティは false で、ダイアログ ボックスは表示されません。

ユーザーがアプリに未保存の変更を加えている可能性がある場合は、このプロパティを使用して、アプリを終了する前に確認ダイアログ ボックスを表示します。 変数とコントロールのプロパティをチェックする数式を使用します (たとえば、編集フォーム コントロールの保存されていないプロパティ)。

確認ダイアログ ボックスは、次のようなデータが失われる可能性がある状況で表示されます。

• Exit 関数を実行します。
• アプリがブラウザーで実行されている場合:
  • アプリが実行されているブラウザーまたはブラウザー タブを閉じます。
  • ブラウザーの [戻る] ボタンを選択します。
  • LaunchTarget of Self を使用して Launch 関数を実行します。
• アプリが Power Apps Mobile (iOS または Android) で実行されている場合:
  • Power Apps Mobile でスワイプして別のアプリに切り替えます。
  • Android デバイスの [戻る] ボタンを選択します。
  • Launch 関数を実行して、別のキャンバス アプリを起動します。

確認ダイアログ ボックスの正確な外観は、デバイスと Power Apps のバージョンによって異なる場合があります。

確認ダイアログ ボックスが Power Apps Studio に表示されません。

ConfirmExitMessage

既定では、確認ダイアログ ボックスに変更が保存されていない可能性があります。などの、汎用メッセージがユーザーの言語で表示されます。

ConfirmExitMessage を使用し、確認ダイアログ ボックスのカスタム メッセージを指定します。 このプロパティが空白の場合、既定値が使用されます。 カスタム メッセージは、確認ダイアログ ボックス内に収まるように必要に応じて切り捨てられるため、メッセージは最大で数行にしてください。

ブラウザーでは、確認ダイアログ ボックスにブラウザーからの汎用メッセージを表示できます。

例

1. App オブジェクトの ConfirmExit プロパティをこの式に設定します。

   AccountForm.Unsaved Or ContactForm.Unsaved
   

   ダイアログ ボックスには、ユーザーがいずれかのフォームでデータを変更した後、それらの変更を保存せずにアプリを閉じようとしたかどうかが表示されます。つまり、ユーザーはいずれかのフォームでデータを変更し、それらの変更を保存せずにアプリを閉じようとします。

   [!div clas1. App オブジェクトの ConfirmExitMessage プロパティをこの数式に設定します。

   If( AccountsForm.Unsaved,
       "Accounts form has unsaved changes.",
       "Contacts form has unsaved changes."
   )
   

   ダイアログ ボックスには、ユーザーがアカウント フォームのデータを変更した後、それらの変更を保存せずにアプリを閉じようとするかどうかが表示されます。

   

Application Insights の接続文字列を設定する

システム生成のアプリケーション ログを Application Insights にエクスポートするには、キャンバス アプリの 接続文字列 を設定します。

1. Power Apps Studio で編集のためにアプリを開きます。
2. 左側のナビゲーションのツリー ビューでアプリ オブジェクトを選択します。
3. プロパティ ウィンドウに 接続文字列 を入力します。

データが Application Insights に送信されない場合は、Power Platform 管理者に問い合わせて、テナント レベルで App Insights が無効になっているかどうかを確認してください。

Formulas プロパティ

Formulas プロパティで名前付き計算式を使用して、アプリ全体で再利用できる式を定義します。

Power Apps では、数式がコントロール プロパティの値を決定します。 たとえば、アプリ全体で一貫した背景色を設定するには、それぞれのFillプロパティを一般的な数式に設定できます。

Label1.Fill: ColorValue( Param( "BackgroundColor" ) )
Label2.Fill: ColorValue( Param( "BackgroundColor" ) )
Label3.Fill: ColorValue( Param( "BackgroundColor" ) )

この数式が表示される場所が非常に多いため、変更が必要な場合にそれらすべてを更新するのは面倒で、エラーが発生しやすくなります。 代わりに、OnStart でグローバル変数を作成して、色を一度設定してから、アプリ全体で値を再利用します。

App.OnStart: Set( BGColor, ColorValue( Param( "BackgroundColor" ) ) )
Label1.Fill: BGColor
Label2.Fill: BGColor
Label3.Fill: BGColor

この方法のほうが優れていますが、BGColor の値が設定される前の OnStart の実行に依存しています。 BGColor はまた、作成者が気付いていないアプリの一部で操作されたり、他の誰かによって行われた変更であったり、追跡が困難な場合があります。

名前付き計算式によって代替手段が提供されます。 通常制御プロパティ = 式を書いているように、代わりに名前 = 式を書くことができ、名前をアプリ全体で再利用して表現を置き換えることができます。 これらの数式の定義は、Formulas プロパティで行われます。

App.Formulas: BGColor = ColorValue( Param( "BackgroundColor" ) );
Label1.Fill: BGColor
Label2.Fill: BGColor
Label3.Fill: BGColor

名前付き計算式を使用する利点は次のとおりです。

• 数式の値は常に利用可能です。 タイミング依存関係も、値が設定される前に最初に実行する必要のある OnStart もなく、式の値が不正確になる時間もありません。 名前付き計算式は、循環参照を作成しない限り、任意の順序で相互に参照できます。 それらは並行して計算できます。
• 数式の値は常に最新です。 数式は、コントロール プロパティまたはデータベース レコードに依存する計算を実行でき、それらが変更されると、数式の値が自動的に更新されます。 変数の場合のように値を手動で更新する必要はありません。 また、数式は必要な場合にのみ再計算されます。
• 式の定義は不変です。 数式の定義は信頼できる唯一の情報源であり、アプリ内の他の場所で値を変更することはできません。 変数では、あるコードが予期せず値を変更してしまう可能性がありますが、名前付き数式ではこのようなデバッグしにくい状況はありえません。
• 数式の計算は延期できます。 値が不変であるため、必要なときにいつでも計算できます。つまり、必要になるまでは計算する必要がありません。 アプリのスクリーン 2 まで使用されない数式の値はスクリーン 2 が表示されるまで計算する必要はないと表示されます。 この作業を遅延させることにより、アプリの読み込み時間を改善できます。 名前付き計算式は宣言型であり、システムが計算方法とタイミングを最適化する機会を提供します。
• 名前付き計算式は Excel の概念です。 非常に多くの人が Excel をよく知っているので Power Fx は可能な限り Excel の概念を使用します。 名前付き計算式は、名前マネージャーで管理される Excel の名前付きセルおよび名前付き計算式と同等です。 スプレッドシートのセルやコントロール プロパティのように、自動的に再計算されます。

名前付き計算式は、Formulas プロパティで順番に定義され、それぞれセミコロンで終わります。 数式の型は、数式内の要素の型と、それらがどのように一緒に使用されるかから推測されます。 たとえば、これらの名前付き計算式は、現在のユーザーに関する有用な情報を Dataverse から取得します。

UserEmail = User().Email;
UserInfo = LookUp( Users, 'Primary Email' = User().Email );
UserTitle = UserInfo.Title;
UserPhone = Switch( UserInfo.'Preferred Phone', 
                    'Preferred Phone (Users)'.'Mobile Phone', UserInfo.'Mobile Phone',
                    UserInfo.'Main Phone' );

UserTitle の式を更新する必要がある場合、この 1 つの場所で簡単に行うことができます。 もしも UserPhone アプリでは必要ない場合、これらの Dataverse のユーザー テーブルへの呼び出しは作られません。 使用されていない数式定義を含めても問題はありません。

名前付き計算式のいくつかの制限:

• 動作関数を使用したり、アプリ内で副作用を引き起こしたりすることはできません。
• 循環参照を作成することはできません。 a = b; と b = a; を同じアプリ内で持つことは許可されていません。

ユーザー定義関数

Power Fx には、If、Text、Set などの組み込み関数の長いリストがあります。 ユーザー定義関数を使用すると、組み込み関数と同様に、パラメーターを受け取って値を返す独自の関数を記述できます。 ユーザー定義関数は、パラメーターを追加し、動作の数式をサポートする名前付き数式の拡張機能と考えることができます。

たとえば、ライブラリからフィクションの本を返す名前付き数式を定義できます。

Library = [ { Title: "The Hobbit", Author: "J. R. R. Tolkien", Genre: "Fiction" },
            { Title: "Oxford English Dictionary", Author: "Oxford University", Genre: "Reference" } ];

LibraryFiction = Filter( Library, Genre = "Fiction" );

パラメーターがない場合は、ジャンルごとに個別の名前付き数式を定義する必要があります。 代わりに、名前付き数式をパラメーター化してください。

LibraryType := Type( [ { Title: Text, Author: Text, Genre: Text } ] );

LibraryGenre( SelectedGenre: Text ): LibraryType = Filter( Library, Genre = SelectedGenre );

ユーザー定義関数ひとつつで LibraryGenre( "Fiction" )、LibraryGenre( "Reference" ) を呼び出したり、他のジャンルのフィルターをかけたりできるようになりました。

構文は次のとおりです:

FunctionName( [ ParameterName1: ParameterType1 [ , ParameterName2: ParameterType2 ... ] ] ) : ReturnType = Formula;

• FunctionName – 必須です。 ユーザー定義関数の名前です。
• ParameterName(s) – 省略可能。 関数パラメーターの名前。
• ParameterType(s) – 任意です。 組み込みデータ型名、データ ソース名、または Type 関数で定義された型の名前です。
• ReturnType – 必須です。 関数からの戻り値の型。
• Formula – 必須。 パラメーターに基づいて関数の値を計算する数式。

各パラメーターとユーザー定義関数からの出力は、型を指定する必要があります。 この例では、SelectedGenre: Text は関数の最初のパラメーターを Text 型に定義し、SelectedGenre はフィルター操作のボディで使用されるパラメーターの名前です。 サポートされている型名についてはデータ型を参照してください。 Type 関数は、ライブラリの集約型を作成するために使用され、関数から書籍のテーブルを返すことができます。

LibraryType をレコード型の複数のテーブルと定義しました。 ひとつのブックを関数に渡す場合、RecordOf関数でこのテーブルのレコードの型を抽出することができます:

BookType := Type( RecordOf( LibraryType ) );

IsGenre( Book: BookType, SelectedGenre: Text ): Boolean = (Book.Genre = SelectedGenre);

関数パラメーターのレコード マッチングは、Power Fx の他の部分よりも厳しくなっています。 レコード値のフィールドは、型定義の適切なサブセットである必要があり、追加のフィールドを含めることはできません。 たとえば IsGenre( { Title: "My Book", Published: 2001 }, "Fiction" ) はエラーになります。

再帰はユーザー定義関数ではまだサポートされていないことに注意してください。

ユーザー定義関数の動作

名前付き数式とほとんどのユーザー定義関数は、Set や Notify のような副作用を持つ行動関数をサポートしていません。 その代わりに関数型プログラミングのパターンに頼り、必要に応じて Power Fx が自動的に計算式を再計算するようにするのが最良です。 しかし、やむを得ない場合もあります。 ユーザー定義関数に動作ロジックを含めるには、本文を中かっこで囲みます。

Spend( Amount: Number ) : Void = {
    If( Amount > Savings, 
        Error( $"{Amount} is more than available savings" ),
        Set( Savings, Savings - Amount );
        Set( Spent, Spent + Amount) 
    );
}

これで Spend( 12 ) を呼び出して、Savings に 12 があるかどうかをチェックし、もしあれば 12 を引いて、Spent 変数に 12 を加えます。 この関数は値を返さないため、戻り値の型は Void です。

動作ユーザー定義関数の構文は次のとおりです。

FunctionName( [ ParameterName1: ParameterType1 [ , ParameterName2: ParameterType2 ... ] ] ) : ReturnType = { Formula1 [ ; Formula2 ... ]};

• FunctionName – 必須です。 ユーザー定義関数の名前です。
• ParameterName(s) – 省略可能。 関数パラメーターの名前。
• ParameterType(s) – 任意です。 組み込みデータ型名、データ ソース名、または Type 関数で定義された型の名前です。
• ReturnType – 必須です。 関数からの戻り値の型。 関数が値を返さない場合は Void を使用します。
• Formula(s) - 必須。 パラメーターに基づいて関数の値を計算する数式。

すべての Power Fx 数式と同様に、エラーが発生しても実行は終了しません。 Error 関数が呼び出された後、If 関数が Savings と Spent の変更を防ぎます。 IfError 関数は、エラー後の実行を阻止する目的でも使用できます。 Void を返しても、問題があれば数式はエラーを返します。

ユーザー定義の型

名前付き数式は、ユーザー定義の型を作成するために Type 関数と一緒に使用することができます。 ユーザー定義の型を定義する場合は、:= の代わりに = を使用します (Book := Type( { Title: Text, Author: Text } ) など)。 詳細と例については、Type関数を参照してください。

OnError プロパティ

OnError を使用して、アプリのどこかでエラーが発生したときにアクションを実行します。 エンドユーザーに表示される前にエラー バナーをインターセプトするグローバルな機会となります。 また、Trace 関数 でエラーを記録したり、データベースや Web サービスに書き込んだりすることも可能です。

Canvas アプリでは、数式の評価結果がすべてエラー チェックされます。 エラーが発生した場合、OnError は、式全体が IfError 関数でラップされていた場合と同じ FirstError と AllErrors スコープ変数で評価されます。

OnError が空の場合、既定のエラー バナーにエラーの FirstError.Message が表示されます。 OnError 数式を定義すると、この動作がオーバーライドされるため、作成者は必要に応じてエラー報告を処理できます。 エラー関数を使用してエラーを再スローすることで、OnError で既定の動作を要求できます。 一部のエラーを別の方法で除外または処理するが、他のエラーを通過させる場合は、再スローアプローチを使用します。

OnError は、IfError のように計算の誤りを置き換えることはできません。 OnError が呼び出された場合、エラーはすでに発生しており、IfError などの数式計算によって処理されています。OnError はエラー報告のみを制御します。

OnError 数式は同時に評価され、その評価が他のエラーの処理と重複する可能性があります。 たとえば、 OnError の先頭にグローバル変数を設定し、後で同じ数式で読み上げた場合、値が変更されている可能性があります。 With 関数 を使用して、数式にローカルな名前付き値を作成します。

各エラーは OnError によって個別に処理されますが、エラーごとに既定のエラー バナーが表示されない場合があります。 同時に多くのエラーバナーが表示されることを避けるため、同じエラーバナーが最近表示された場合は、再度表示されません。

例

式で結合された Label コントロールと Slider コントロールを考えてみましょう:

Label1.Text = 1/Slider1.Value

スライダーの既定値は 50 です。 スライダーを 0 にすると、Label1 の値は表示されず、エラー バナーが表示されます。

何が起こったのかを詳しく見てみましょう:

1. ユーザーがスライドを左に移動し、 Slide1.Value プロパティが 0 に変更されました。
2. Label1.Text が自動的に再評価されました。 ゼロ除算が発生し、エラーが発生しました。
3. この式では IfError はありません。 ゼロ除算エラーは、数式評価によって返されます。
4. Label1.Text はこのエラーに対して何も表示できないので、空白の状態が表示されます。
5. OnError が呼び出されます。 ハンドラーがないため、標準エラー バナーがエラー情報とともに表示されます。

必要に応じて、数式を Label1.Text = IfError( 1/Slider1.Value, 0 )に変更することもできます。 IfError を使用すると、エラーやエラー バナーがないことを意味します。 エラーが既に発生しているため、エラーの値を OnError から変更することはできません。OnError では、報告方法のみが制御されます。

OnError ハンドラーを追加しても、手順 5. の前の手順には影響しませんが、エラーの報告方法は変わります。

Trace( $"Error {FirstError.Message} in {FirstError.Source}" )

この OnError ハンドラーでは、アプリ ユーザーにエラーは表示されません。 ただし、エラーは、 FirstError からのエラー情報のソースを含め、モニターのトレースに追加されます。

また、トレースと共に既定のエラー バナーを表示する場合は、Trace 呼び出しの後に Error 関数でエラーを再スローします。これは、Trace が存在しなかったかのようにします。

Trace( $"Error {FirstError.Message} in {FirstError.Source}" );
Error( FirstError )

OnStart プロパティ

OnStart プロパティは、ユーザーがアプリを開始するときに実行されます。 このプロパティは、多くの場合、次の用途に使用されます。

• Collect 関数を使用して、コレクション内のデータを取得およびキャッシュします。
• Set 関数を使用して、グローバル変数を設定します。

この数式は、最初の画面が表示される前に実行されます。 画面が読み込まれないため、UpdateContext 関数を使用してコンテキスト変数を設定することはできません。 ただし、 Navigate 関数を使用してコンテキスト変数を渡すことができます。

OnStart プロパティを変更した後、ツリー ビュー ペインの App オブジェクトにマウス ポインターを合わせ、省略記号 (...) を選択し、[OnStart の実行] を選択してテストします。 アプリが初めて読み込まれる場合とは異なり、既存のコレクションと変数は既に設定されています。 空のコレクションから始めるには、Collect 関数の代わりに、ClearCollect 関数を使用します。

StartScreen プロパティ

StartScreen プロパティは、最初に表示する画面を設定します。 アプリが読み込まれたときに 1 回評価され、表示する画面オブジェクトが返されます。 既定では、このプロパティは空で、Studio ツリー ビューの最初の画面が最初に表示されます。

StartScreen は、動作関数を含めることができないデータ フロー プロパティです。 すべてのデータ フロー関数を使用できます。 次の機能とシグナルを使用して、最初に表示する画面を決定します。

• アプリの起動に使用されるパラメーターを読み取る Param 関数。
• 現在のユーザーに関する情報を読み取る User 関数。
• LookUp、Filter、CountRows、Max など、データ ソースから読み取る関数。
• コネクタを介した API 呼び出し。 呼び出しがすぐに返されるようにします。
• Connection、Compass、App などの信号。

StartScreen からエラーが返された場合、Studio ツリー ビューの最初の画面は、StartScreen が設定されていないかのように表示されます。 IfError 関数を使用してエラーをキャッチし、エラー画面にリダイレクトします。

Studio で StartScreen を変更した後、ツリー ビュー ペインの App オブジェクトにマウス ポインターを合わせ、省略記号 (...) を選択し、[StartScreen に移動] を選択してテストします。 アプリが読み込まれたかのように画面が変わります。

使用例

Screen9

Screen9 は、アプリが起動するたびに最初に表示されます。

If( Param( "admin-mode" ) = 1, HomeScreen, AdminScreen )

パラメーター "admin-mode" が設定されているかどうかを確認し、それを使用して HomeScreen または AdminScreen が最初に表示されるかどうかを判断します。

If( LookUp( Attendees, User = User().Email ).Staff, StaffPortal, HomeScreen )

出席者がスタッフ メンバーであるかどうかを確認し、起動時に正しい画面に誘導します。

IfError( If( CustomConnector.APICall() = "Forest", 
             ForestScreen, 
             OceanScreen 
         ), 
         ErrorScreen 
)

API 呼び出しに基づいてアプリを ForestScreen または OceanScreen に移動します。 API が失敗した場合、アプリは代わりに ErrorScreen を使用します。

StudioVersion プロパティ

StudioVersion プロパティを使用して、アプリの発行に使用した Power Apps Studio のバージョンを表示またはログに記録します。 このプロパティは、アプリが Power Apps Studio の最新バージョンで再発行されたことをデバッグして確認するときに役立ちます。

StudioVersion はテキストを返します。 このテキストの形式は時間の経過と同時に変更される可能性があるため、全体として扱い、個々の部分を抽出しません。