ユーザー通知用に Android アプリをクライアント側のSDKと統合するIntegrate your Android app with the client-side SDK for user notifications

Azure ポータルでアプリを登録し、パートナー デベロッパー センターでクロスデバイス体験を始めたら、次の手順で、クライアント側の Android 用 SDK アプリとクライアント アプリケーションを統合します。After you register your app in the Azure Portal and onboard your cross-device experiences in the Partner Dev Center, the next step is to integrate your client app with the client-side SDK for Android apps.

クライアント側 SDK を使用することで、アプリは、アプリケーション サーバーから現在サインインしているユーザーを対象に発行された通知の受信を開始するために必要な登録手順を実行できるようになります。With the client-side SDK, your app can perform the necessary registration steps to start receiving notifications published from your app server targeted at the user who is currently signed in. その後で、この SDK はクライアント側での通知の管理を実行します。これには、新しい着信通知の受信、すべて消去のようなシナリオを実現するための通知状態の管理、および完全な通知履歴の取得が含まれます。The SDK then manages the notifications on the client side, including receiving new incoming notifications, managing the state of notifications to achieve scenarios like universal dismiss, and retrieving full notification history.

新しい着信通知のフローNew incoming notification flow

新しい受信通知を受け取ると、次の図のようなデータ フローが表示されます。For receiving new incoming notifications, the data flow is shown in the following diagram.

Android アプリの新しい通知のフロー

プロセスには、いくつかのコンポーネントが含まれます:he process involves a few components:

  • アプリケーション サーバー - アプリケーションのバック エンドApp server - The back end of your application
  • アプリケーション クライアント: アプリケーションのフロント エンド (UWP アプリ、Android アプリ、または iOS アプリ)App client - The front end of your application (a UWP app, an Android app, or an iOS app)
  • Microsoft Graph の通知 - デバイスおよびプラットフォームを跨ぐアプリケーション クライアントの異なるインスタンス間でのユーザー通知の発行と格納、同期を可能にするサービス コンポーネントMicrosoft Graph notifications - The service component that enables user notifications to be published, stored, and synced across different instances of app clients across devices and platforms
  • FCM - Firebase Cloud Messaging のことで、Google Play サービスの一部として Android が提供するプッシュ通知サービス。FCM - Firebase Cloud Messaging, the push notification service provided by Android as a part of Google Play Services. Microsoft Graph の通知は、このサービスを使用して、ユーザーの通知データの変更について Android アプリ クライアントに通知します。Microsoft Graph notifications use this service to signal the Android app clients about user notification data changes.

この図は次の手順を示します。The diagram shows the following steps:

  1. アプリケーションのロジック。Application logic. この手順では、ユーザーに通知を発行するトリガーになるものを取り込みます。This step captures what triggers the notification to be published to the user. これは、アプリケーション固有のロジックであり、Microsoft Graph の別のもの (予定表イベントやタスクの割り当てなど) に関するイベントまたはデータの更新になることも、それとは別にアプリ サービスでユーザーに通知しようとしているものになることもあります。This is app-specific logic, and can be an event or data update about something else in Microsoft Graph, such as a new calendar event or task assignment, or else your app service wants to notify the user about.
  2. アプリケーション サーバーから対象ユーザーへの通知は、Microsoft Graph 通知 API 経由で発行されます。The app server publishes a notification to the targeted user via the Microsoft Graph notifications API. 詳細については、サーバー側との統合を参照してください。For more details, see server side integration.
  3. 新しい通知が含まれている Web 要求を受信すると、Microsoft Graph 通知は、このアプリとユーザーのためにクラウドで通知の内容を安全に保持します。On receiving the web request containing the new notification, Microsoft Graph notifications persists the content of the notification securely in the cloud for this app and this user.
  4. このユーザーが通知を受け取るための各アプリケーション クライアント インスタンスのサブスクリプションには、Microsoft Graph の通知がオペレーティング システムによって提供されるネイティブ プッシュ サービスを使用して、アプリのクライアントに通知を送信します。For each app client instance subscribing to receive notifications for this user, Microsoft Graph notifications sends a signal to notify the app client, via the native push service provided by the operating system. この場合、アプリケーションは Android アプリであり、FCM データメッセージを使用して信号を送信します。In this case, the application is an Android app, and it uses FCM data message to send the signal.
  5. 受信プッシュ通知によって通知がアプリケーションに送られた後、アプリケーションはユーザー通知ストア内の変更の取得を SDK に求めます。After the application is signaled by the incoming push notification, it asks the SDK to fetch for the changes in the user notification store.
  6. SDK は、Microsoft Graph 内で、ユーザー通知ストアとの安全で準拠した接続を確立します。The SDK establishes a secure and compliant connection with the user notifications store in Microsoft Graph.
  7. SDK は、データの変更 (この場合は新しい通知の内容) を取得します。The SDK gets the data changes - in this case, the new notification contents.
  8. 変更が正常に取得された後、アプリに通知するためのイベント コールバックが SDK で発生します。The SDK fires event callbacks to notify the app after the changes are successfully retrieved.
  9. アプリケーションのロジック。Application logic. この手順では、アプリがイベント コールバック内で実行する内容を取得します。This step captures what your app chooses to do inside the event callback. 通常、ローカルのアプリ データが変更され、ローカルの UI 更新が発生します。Usually, this results in local app data changes and local UI updates. この場合、通常、アプリは通知内容をユーザーに知らせるトースト通知ポップアップを作成します。In this case, the app usually constructs a toast notification popup to notify the user about the notification contents.

通知の更新フローNotification update flow

Microsoft Graph 通知を使用する主な利点の 1 つは、通知が安全にクラウドで保持され、ステートフル リソース タイプに変更できることです。One of the main benefits for using Microsoft Graph notifications is that it persists notifications in the cloud securely and turns them into a stateful resource type. そのため、アプリケーションはクロスデバイス シナリオにおいて、サインインしている同一のユーザーに対して、異なるデバイス間で通知の正しい状態を管理および同期できます。Therefore, it can help your application to manage and sync the correct state of the notifications across different devices for the same signed in user in a cross-device scenario. あるデバイスで通知が消去または既読になったときには、その他のデバイスにリアルタイムで通知されます。When a notification is marked as dismissed, or marked as read on one device, the other devices can be notified in real-time. "一度処理すれば、すべての場所で消去される" ということが、ユーザーの通知体験の一部として実現されます。"Handled once, dismissed everywhere" can become a true promise as part of the notification experience for your users.

次の図は、通知の状態を変更したり、一つのデバイスでの通知を削除したり、別のデバイスで状態の変更または削除を受信/処理するためのデータフローを示しています。The following diagram shows the data flow for changing the state of a notification or deleting the notification on one device, and receiving/handling the state change or the deletion on another device.

Android アプリの更新通知のフロー

フローの2番目の部分の通知は、新しい受信通知の処理の流れと似ています。Notice that the second part of the flow is similar to the flow for handling new incoming notifications. これは仕様によるものです。SDK のプログラミング パターンでは、あらゆる種類のユーザー通知データの変更 (新規に受信した通知、通知状態の変更、通知の削除など) をアプリケーション クライアントが同じような方法で処理できるように設計されています。This is by design - the programming pattern of the SDK is designed so that the application client can handle all types of user notification data changes (new incoming notifications, notification state changes, notification deleted) in a similar way.

この図は、次の手順を示しています。The diagram shows the following steps:

  1. アプリケーションのロジック。Application logic. 何らかのものが、通知の変更または削除をトリガーします。Something triggers the notification to be changed or deleted. 一般に、あらゆるイベントが通知を変更するトリガーになり得ます。In general, any event can trigger a notification to change.
  2. 通知を更新または削除するクライアント SDK のアプリによる呼び出し。App calling into the client SDK to update or delete a notification. 現在、状態の変更に関して 2 つのプロパティ (userActionState および readState) が公開されていますが、こうした状態とその状態の更新時期はアプリケーションで定義できます。Currently, we expose two properties regarding state changes - userActionState and readState - but your application can define these states and when they need to be updated. たとえば、ユーザーが通知ポップアップを消去したときには、userActionState が消去済み (Dismissed) になるように更新します。For example, when a user dismisses the notification popup, you can update the userActionState to be Dismissed. ユーザーが通知ポップアップをクリックして、それに対応するアプリのコンテンツを利用するアプリを起動したときに、userActionState をアクティブ化済み (Activated) に更新し、readState を読み取り (Read) に更新します。When a user clicks the notification popup and launches the app to consume corresponding app content, you can update the userActionState to be Activated and update the readState to be Read.
  3. 通知を更新または削除するために対応する API が呼び出された後、SDK は、クラウド内のユーザー通知ストアに送信して、この変更をサインインしている同一ユーザーの別のアプリクライアント インスタンスに展開します。After the corresponding API is called to update or delete a notification, the SDK will call into the user notification store in the cloud in order to fan-out this change to the other app client instances with the same signed in user.
  4. クライアントから更新/削除要求を受信した Microsoft Graph 通知は、通知ストアを更新して、この変更をサブスクライブしている別のアプリ クライアント インスタンスを特定します。On receiving the update/delete request from a client, Microsoft Graph notifications will update the notification store, and identify the other app client instances that subscribed to this change.
  5. 各アプリケーションの クライアント サブスクリプションには、Microsoft Graph の通知がオペレーティング システムによって提供されるネイティブ プッシュ サービスを使用して、アプリのクライアントに通知を送信します。For each app client subscription, Microsoft Graph notifications sends a signal to notify the app client, via the native push service provided by the operating system. この場合、これは Android アプリであり、FCM データメッセージを使用して信号を送信します。In this case, this is an Android app, and it uses FCM data message to send the signal.
  6. 受信プッシュ通知によって通知がアプリケーションに送られた後、アプリケーションはユーザー通知ストア内の変更の取得を SDK に求めます。After the application is signaled by the incoming push notification, it asks the SDK to fetch for the changes in the user notification store.
  7. SDK は、Microsoft Graph 内で、ユーザー通知ストアとの安全で準拠した接続を確立します。The SDK establishes a secure and compliant connection with the user notifications store in Microsoft Graph.
  8. SDK によってデータが変更されます。ここでは、変更内容は通知状態の更新または通知の削除です。The SDK gets the data changes - in this case, the changes are notification state updates or notification deletions.
  9. 変更が正常に取得された後、アプリに通知するためのイベント コールバックが SDK で発生します。The SDK fires event callbacks to notify the app after the changes are successfully retrieved.
  10. アプリケーションのロジック。Application logic. この手順では、アプリがイベント コールバック内で実行する内容を取得します。This step captures what your app chooses to do inside the event callback. 通常、ローカルのアプリ データが変更され、ローカルの UI 更新が発生します。Usually, this results in local app data changes and local UI updates. この場合、通知の更新があるため、アプリはローカルに UI を更新して状態の変更を反映させる必要があります。In this case, because there are notification updates, the app should update the UI locally to reflect the state change. たとえば、通知がアクティブ化されている場合、Android 通知トレイ内の対応する通知メッセージを削除すると、"一度処理すれば、すべての場所で消去" することができます。For example, if a notification is marked as activated, you can remove the corresponding notification message inside Android's notification tray to achieve "handled once, dismissed everywhere".

Microsoft Graph の通知の詳細については、Microsoft Graph の通知の概要を参照してください。For more information about Microsoft Graph notifications, see Microsoft Graph Notifications overview. 全てを Microsoft Graph の通知と統合するために必要な手順の詳細については、Microsoft Graph の通知の統合の概要を参照してください。For more information about the steps required to integrate with Microsoft Graph notifications from end to end, see Microsoft Graph notifications integration overview.

開発環境と要件Development environment and requirements

Microsoft Graph の通知を使用するには、Android アプリ開発 IDE と、サポートされているアーキテクチャの 1 つ (armeabi-v7aarm64-v8ax86、または x86_64) を備えた Android デバイス、またはエミュレーターが必要です。To use Microsoft Graph notifications, you will need an Android app development IDE and an Android device with one of the supported architectures (armeabi-v7a, arm64-v8a, x86, or x86_64) or an emulator. システムは Android 4.4.2 以降を実行している必要があります。The system must be running Android 4.4.2 or later.

プロジェクトに SDK を追加するAdding the SDK to your project

プロジェクトのルートにある build.gradle ファイルに、次のリポジトリ参照を挿入します。Insert the following repository references into the build.gradle file at the root of your project.

allprojects {
    repositories {
    jcenter()
    maven { url 'https://maven.google.com' }
    maven { url 'https://projectrome.bintray.com/maven/' }
    }
}

次に、プロジェクトフォルダーにある build.gradle ファイルに次の依存関係を挿入します。Then, insert the following dependency into the build.gradle file that is in your project folder.

dependencies { 
    ...
    implementation 'com.microsoft.connecteddevices:connecteddevices-sdk:+'
}

アプリで ProGuard を使用したい場合は、これらの新しい API の ProGuard ルールを追加してください。If you want to use ProGuard in your app, add the ProGuard Rules for these new APIs. プロジェクトの App フォルダに proguard-rules.txt というファイルを作成し、ProGuard_Rules_for_Android_Rome_SDK.txt の内容を貼り付けます。Create a file called proguard-rules.txt in the App folder of your project, and paste in the contents of ProGuard_Rules_for_Android_Rome_SDK.txt. プロジェクトの AndroidManifest.xml ファイルで、manifest 要素内に次の権限を追加します (まだ存在しない場合)。In your project's AndroidManifest.xml file, add the following permissions inside the manifest element (if they are not already present). これにより、インターネットに接続してデバイス上で Bluetooth 検出を有効にする権限がアプリケーションに与えられます。This gives your app permission to connect to the Internet and to enable Bluetooth discovery on your device. Bluetooth 関連の権限は、Bluetooth 検出を使用する場合にのみ必要であり、接続されているデバイス プラットフォームの他の機能には必要ありません。Note that the Bluetooth-related permissions are only necessary for using Bluetooth discovery; they are not needed for the other features in the Connected Devices Platform. また、ACCESS_COARSE_LOCATIONは Android SDK 21 以降でのみ必須です。Additionally, ACCESS_COARSE_LOCATION is only required on Android SDKs 21 and later. Android SDK 23 以降では、実行時に位置アクセスを許可するようにユーザーに要求する必要もあります。On Android SDKs 23 and later, you must also prompt the user to grant location access at runtime.

<uses-permission android:name="android.permission.INTERNET" />
<uses-permission android:name="android.permission.BLUETOOTH" />
<uses-permission android:name="android.permission.BLUETOOTH_ADMIN" />
<uses-permission android:name="android.permission.ACCESS_COARSE_LOCATION" />
<uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" />

次に、接続されているデバイスの機能を配置するアクティビティのクラスに移動します。Next, go to the activity classes where you would like the Connected Devices functionality to be located. 次の名前空間をインポートします。Import the following namespaces.

import com.microsoft.connecteddevices;
import com.microsoft.connecteddevices.userdata;
import com.microsoft.connecteddevices.userdata.usernotifications;

Connected Device Platforms の初期化Initializing the Connected Device Platforms

クライアント側のSDKは、Connected Device Platforms と呼ばれるインフラストラクチャの上に構築されています。The client-side SDK is built on top of an infrastructure called Connected Device Platform. 機能を使用するには、アプリ内でプラットフォームを初期化する必要があります。Before any feature can be used, the platform must be initialized within your app. この初期化手順は、通知シナリオを実行する前に必須であるため、メインクラス OnCreate メソッド内で実行する必要があります。The initialization steps should occur in your main class OnCreate method, because they are required before the notification scenarios can take place.

ConnectedDevicesPlatform クラスをインスタンス化して、プラットフォームを構築および初期化する必要があります。You must construct and initialize the platform by instantiating the ConnectedDevicesPlatform class. これを行う前に、プラットフォームが起動した後、イベントが発生する可能性があるため、イベント ハンドラーを接続してください。Before doing that, make sure to hook up event handlers, because after the platform is started, the events might begin to fire.

ConnectedDevicesPlatform platform = new ConnectedDevicesPlatform(context);

platform.getAccountManager().accessTokenRequested().subscribe((accountManager, args) -> onAccessTokenRequested(accountManager, args));
platform.getAccountManager().accessTokenInvalidated().subscribe((accountManager, args) -> onAccessTokenInvalidated(accountManager, args));
platform.getNotificationRegistrationManager().notificationRegistrationStateChanged().subscribe((notificationRegistrationManager, args) -> onNotificationRegistrationStateChanged(notificationRegistrationManager, args));

platform.start();

アカウント アクセス トークンの処理Handling account access token

新しい着信通知のコンテンツの取得、通知状態の更新など、SDK で実行されるすべての Web 呼び出しは、ユーザーのデータに対する読み取りと書き込みになるため、常に有効なアクセス トークンが必要になります。All the web calls the SDK makes, including retrieving the content of a new incoming notification, updating notification states, and more, are reading from or writing to the user's data, and therefore always require a valid access token. プラットフォームが初期化された後に、ユーザーのアクセストークンが正常に機能するために、SDK は次のイベント - アクセス トークン が要求または無効化されたときに呼び出された - の処理を必要とします。The SDK requires you to handle the following events - invoked when an access token is requested or invalidated - to make sure that after the platform is initialized, your access token for the user is handled correctly.

accessTokenRequestedaccessTokenRequested

完全に実装するには、Android サンプルアプリを参照してください。For a full implementation, see the Android sample app.

private void onAccessTokenRequested(ConnectedDevicesAccountManager sender, ConnectedDevicesAccessTokenRequestedEventArgs args) {
    ConnectedDevicesAccessTokenRequest request = args.getRequest();
    List<String> scopes = request.getScopes();

    // We always need to complete the request, even if a matching account is not found
    if (account == null) {
        request.completeWithErrorMessage("The app could not find a matching ConnectedDevicesAccount to get a token");
        return;
    }

    // Complete the request with a token
    account.getAccessTokenAsync(scopes)
        .thenAcceptAsync((String token) -> {
            request.completeWithAccessToken(token);
        }).exceptionally(throwable -> {
            request.completeWithErrorMessage("The Account could not return a token with those scopes");
            return null;
    });
}

accessTokenInvalidatedaccessTokenInvalidated

完全に実装するには、Android サンプルアプリを参照してください。For a full implementation, see the Android sample app.

private void onAccessTokenInvalidated(ConnectedDevicesAccountManager sender, ConnectedDevicesAccessTokenInvalidatedEventArgs args, List<Account> accounts) {
    Log.i(TAG, "Token invalidated for account: " + args.getAccount().getId());
}

プッシュ登録の有効期限を処理するHandling push registration expiration

Microsoft Graph の通知は、FCM、Androidのネイティブのプッシュ プラットフォームを使用して、ユーザー通知のデータ変更をクライアント アプリケーションに通知します。Microsoft Graph notifications uses FCM, the native push platform on Android, to signal the client application on user notifications data changes. これは、新しい受信通知がアプリサーバーから発行されている場合、またはクロスデバイス シナリオにおいてサインインした同じユーザーの別のデバイスで通知の状態が更新された場合に発生します。This happens when new incoming notifications are published from your app server, or when any notification's state is updated on a different device with the same signed in user in a cross-device scenario.

したがって、データ通知メッセージが正常に送信されることを許可する有効なFCMトークンが必要です。Therefore, a valid FCM token that allows data notification messages to come through successfully is required. 次のイベントコールバックでは、FCM プッシュトークンの有効期限を処理します。The following event callback handles FCM push token expirations.

notificationRegistrationStateChangednotificationRegistrationStateChanged

完全に実装するには、Android サンプルアプリを参照してください。For a full implementation, see the Android sample app.

ユーザーにサインインするSigning in your user

Microsoft Graph 内の他の多くのリソースタイプと同様に、Microsoft Graph の通知は、ユーザーを中核として一元化されます。Microsoft Graph notifications, like many other resource types in Microsoft Graph, are centralized around users. アプリでサブスクライブし、サインインしたユーザーへの通知を受信できるようにするには、最初に登録プロセスで使用する有効な OAuth トークンを入手する必要があります。In order for your app to subscribe to and start receiving notifications for the signed in user, you first need to obtain a valid OAuth token to be used in the registration process. OAuth トークンを生成および管理する方法を選択できます。You can use your preferred method of generating and managing the OAuth tokens. サンプルアプリは ADAL を使用しました。The sample app used ADAL.

Microsoft アカウント を使用している場合は、サインイン リクエストに次の許可を含める必要があります:wl.offline_access", ccs.ReadWrite, wns.connect, asimovrome.telemetry, https://activity.windows.com/UserActivity.ReadWrite.CreatedByAppIf you're using a Microsoft account, you will need to include the following permissions in your sign-in request: wl.offline_access", ccs.ReadWrite, wns.connect, asimovrome.telemetry, and https://activity.windows.com/UserActivity.ReadWrite.CreatedByApp.

Azure AD アカウントを使用している場合は、次の対象ユーザーを要求する必要があります: https://cdpcs.access.microsoft.comIf you're using an Azure AD account, you'll need to request the following audience: https://cdpcs.access.microsoft.com.

プラットフォームにユーザーアカウントを追加するAdding the user account to the platform

サインインしたユーザーアカウントを SDK に登録する必要があります。これには、FCM を経由して最初のプッシュ通知を受信するためのアカウントの追加とプッシュ チャネルの登録が含まれます。You need to register the signed in user account with the SDK, which involves adding the account and registering a push channel in order to receive the initial push notifications through FCM.

public AsyncOperation<Boolean> prepareAccountAsync(final Context context) {
    // Accounts can be in 3 different scenarios:
    // 1: cached account in good standing (initialized in the SDK and our token cache).
    // 2: account missing from the SDK but present in our cache: Add and initialize account.
    // 3: account missing from our cache but present in the SDK. Log the account out async

    // Subcomponents (e.g. UserDataFeed) can only be initialized when an account is in both the app cache
    // and the SDK cache.
    // For scenario 1, initialize our subcomponents.
    // For scenario 2, subcomponents will be initialized after InitializeAccountAsync registers the account with the SDK.
    // For scenario 3, InitializeAccountAsync will unregister the account and subcomponents will never be initialized.
    switch (mState) {
        // Scenario 1
        case IN_APP_CACHE_AND_SDK_CACHE:
            mUserNotificationsManager = new UserNotificationsManager(context, mAccount, mPlatform);
            return registerAccountWithSdkAsync();
        // Scenario 2
        case IN_APP_CACHE_ONLY: {
            // Add the this account to the ConnectedDevicesPlatform.AccountManager
            return mPlatform.getAccountManager().addAccountAsync(mAccount).thenComposeAsync((ConnectedDevicesAddAccountResult result) -> {
                // We failed to add the account, so exit with a failure to prepare bool
                if (result.getStatus() != ConnectedDevicesAccountAddedStatus.SUCCESS) {
                    result.getStatus());
                    return AsyncOperation.completedFuture(false);
                }

                // Set the registration state of this account as in both app and sdk cache
                mState = AccountRegistrationState.IN_APP_CACHE_AND_SDK_CACHE;
                mUserNotificationsManager = new UserNotificationsManager(context, mAccount, mPlatform);
                return registerAccountWithSdkAsync();
            });
        }
        // Scenario 3
        case IN_SDK_CACHE_ONLY:
            // Remove the account from the SDK since the app has no knowledge of it
            mPlatform.getAccountManager().removeAccountAsync(mAccount);
            // This account could not be prepared
            return AsyncOperation.completedFuture(false);
        default:
            // This account could not be prepared
            Log.e(TAG, "Failed to prepare account " + mAccount.getId() + " due to unknown state!");
            return AsyncOperation.completedFuture(false);
    }
}
public AsyncOperation<Boolean> registerAccountWithSdkAsync() {
    if (mState != AccountRegistrationState.IN_APP_CACHE_AND_SDK_CACHE) {
        AsyncOperation<Boolean> toReturn = new AsyncOperation<>();
        toReturn.completeExceptionally(new IllegalStateException("Cannot register this account due to bad state: " + mAccount.getId()));
        return toReturn;
    }

    // Grab the shared GCM/FCM notification token from this app's BroadcastReceiver
    return RomeNotificationReceiver.getNotificationRegistrationAsync().thenComposeAsync((ConnectedDevicesNotificationRegistration notificationRegistration) -> {
        // Perform the registration using the NotificationRegistration
        return mPlatform.getNotificationRegistrationManager().registerAsync(mAccount, notificationRegistration)
            .thenComposeAsync((result) -> {
                if (result.getStatus() == ConnectedDevicesNotificationRegistrationStatus.SUCCESS) {
                    Log.i(TAG, "Successfully registered account " + mAccount.getId() + " for cloud notifications");
                } else {
                    // It would be a good idea for apps to take a look at the different statuses here and perhaps attempt some sort of remediation.
                    // For example, token request failed could mean that the user needs to sign in again. An app could prompt the user for this action 
                    // and retry the operation afterwards.
                    Log.e(TAG, "Failed to register account " + mAccount.getId() + " for cloud notifications!");
                    return AsyncOperation.completedFuture(false);
                }

                return mUserNotificationsManager.registerForAccountAsync();
            });
    });
}

ユーザーの通知を受信するためのサブスクライブSubscribing to receive user's notifications

このログイン ユーザーのアプリケーションのため、UserDataFeed オブジェクトをインスタンス化する必要があります。You need to instantiate a UserDataFeed object for your application for this logged in user. アプリケーションは、クロスデバイス エクスペリエンスの開始に指定したクロスプラットフォームアプリ ID によって識別されます。Your application is identified by the cross-platform app ID you provided during the Cross-Device Experiences onboarding.

public UserNotificationsManager(@NonNull Context context, @NonNull ConnectedDevicesAccount account, @NonNull ConnectedDevicesPlatform platform)
{
    Context context = new Context;
    UserDataFeed feed = UserDataFeed.getForAccount(account, platform, Secrets.APP_HOST_NAME);
    UserNotificationChannel channel = new UserNotificationChannel(feed);
    UserNotificationReader reader = channel.createReader();
    reader.dataChanged().subscribe((reader, aVoid) -> readFromCache(reader));
    }
}

ユーザー通知を受信および管理するReceiving and managing user notifications

このトピックの前半のフロー図では、アプリ サーバーからの新しい着信通知や、別のアプリケーション クライアント インスタンスで開始された通知の更新または削除を処理するためのプログラミング パターンを示しました。The flow diagram earlier in this topic shows that the programming patterns to handle a new incoming notifications from an app server and a notification update or deletion initiated from another app client instance are similar. このようなデータの変更を処理する手順は次のとおりです。The following are the steps for handling these data changes.

着信プッシュ通知シグナルの処理Handling incoming push notification signal

全ての種類のユーザー通知データの変更について、プッシュ通知としてアプリクライアントに配信されるシグナルが生成されます。All types of user notification data changes generate a signal that gets delivered to the app clients as a push notification. Android アプリの場合、信号は FCM プッシュ データ メッセージとして配信されます。For Android apps, the signal is delivered as a FCM push data message. データ メッセージ シグナルを受信するには、アプリがTryParseを呼び出し、実際のデータ変更のためのSDKによる Microsoft Graph の通知サービスからの取得をトリガーします。On receiving the data message signal, the app should call TryParse to trigger the SDK to fetch from the Microsoft Graph notifications service for the actual data changes.

public void onMessageReceived(RemoteMessage message) {
    Map data = message.getData();
    ConnectedDevicesNotification notification = ConnectedDevicesNotification.tryParse(data);

    if (notification != null) {
        try {
            ConnectedDevicesPlatform platform = ConnectedDevicesManager.getConnectedDevicesManager(getApplicationContext()).getPlatform();

            // NOTE: it may be useful to attach completion to this async in order to know when the notification is done being processed.
            // This would be a good time to stop a background service or otherwise cleanup.
            platform.processNotificationAsync(notification);
        } catch (Exception e) {
            Log.e(TAG, "Failed to process FCM notification" + e.getMessage());
        }
    }
}

ユーザー通知のデータ変更の処理Handling user notification data changes

SDK がデータ変更の取得を正常に完了すると、イベントコールバックが起こり、アプリクライアントが通知の作成、更新、または削除を処理することが想定されます。After the SDK successfully completes fetching the data changes, an event callback is invoked and the app client is expected to handle notification creation, update, or deletion.

private void readFromCache(final UserNotificationReader reader)
{
    reader.readBatchAsync(Long.MAX_VALUE).thenAccept(notifications -> {
        synchronized (this) {
            for (final UserNotification notification : notifications) {
                if (notification.getStatus() == UserNotificationStatus.ACTIVE) {
                    removeIf(mNewNotifications, item -> notification.getId().equals(item.getId()));

                    if (notification.getUserActionState() == UserNotificationUserActionState.NO_INTERACTION) {
                        mNewNotifications.add(notification);
                        if (notification.getReadState() != UserNotificationReadState.READ) {
                            clearNotification(mContext.getApplicationContext(), notification.getId());
                            addNotification(mContext.getApplicationContext(), notification.getContent(), notification.getId());
                        }
                    } else {
                        clearNotification(mContext.getApplicationContext(), notification.getId());
                    }

                    removeIf(mHistoricalNotifications, item -> notification.getId().equals(item.getId()));
                    mHistoricalNotifications.add(0, notification);
                } else {
                    removeIf(mNewNotifications, item -> notification.getId().equals(item.getId()));
                    removeIf(mHistoricalNotifications, item -> notification.getId().equals(item.getId()));
                    clearNotification(mContext.getApplicationContext(), notification.getId());
                }
            }
        }

    });
}

通知の更新状態Update state of a notification

このアプリ クライアントのインスタンスから通知状態の変更が開始された場合 (たとえば、このデバイスのトースト通知ポップアップをユーザーが有効化した場合)、アプリでは、この状態の変更を同じユーザーが使用するすべてのデバイスで同期するために、SDK を呼び出して通知の状態を更新する必要があります。If a notification state change is initiated from this app client instance (for example, if the toast notification popup on this device is activated by the user), the app needs to call the SDK to update the notification's state in order to have this state change synced across all devices used by the same user.

notification.setUserActionState(UserNotificationUserActionState.ACTIVATED);
notification.saveAsync().whenCompleteAsync((userNotificationUpdateResult, throwable) -> {
    if (throwable == null && userNotificationUpdateResult != null && userNotificationUpdateResult.getSucceeded()) {
        Log.d(TAG, "Successfully activated the notification");
    }
});

通知を削除するDelete a notification

このアプリ クライアントのインスタンスから通知の削除が開始された場合 (たとえば、この通知に対応するタスクに完了のマークが付けられ、アプリのデータベースから通知が削除された場合)、アプリでは、この削除の操作を同じユーザーが使用するすべてのデバイスで同期するために、SDK を呼び出して通知を削除する必要があります。If a notification deletion is initiated from this app client instance (for example, if the task corresponding to this notification is marked as complete and is removed from your app's database), the app needs to call the SDK to delete the notification in order to have this delete operation synced across all devices used by the same user.

通知は、有効期限が切れているか、明示的に削除された場合にのみ、ユーザー通知ストアから削除されます。A notification is removed from the user notification store only if it is expired or explicitly deleted. UserActionState のセマンティック定義はアプリケーション自体によって定義されているため、UserActionState が消去済み (Dismissed) になるように更新しても、ユーザー通知は削除されません。A user notification is not deleted when you update the UserActionState to be Dismissed, because the semantic definition of UserActionState is defined by the application itself.

channel.deleteUserNotificationAsync(notification.getId()).whenCompleteAsync((userNotificationUpdateResult, throwable) -> {
    if (throwable == null && userNotificationUpdateResult != null && userNotificationUpdateResult.getSucceeded()) {
        Log.d(TAG, "Successfully deleted the notification");
    }
});

関連項目See also