すでにキューに登録されている処理を更新する

WorkManager を使用すると、WorkRequest を エンキューされました。これは、頻繁に変更される大規模なアプリでよく必要になります。 ワーカーをその場で更新する必要があったりします。WorkManager 以降 バージョン 2.8.0 では、そのための手段として updateWork() API が使用されます。

updateWork() メソッドを使用すると、 手動でのプロセスを必要とせずに、その場で WorkRequest を実行 新しいものをキャンセルしてキューに登録できます。これにより開発が大幅に簡素化されます プロセスです

処理のキャンセルを回避する

通常は、既存の WorkRequest をキャンセルして新しい WorkRequest をキューに登録することは避けるべきです。 1 です。そのようにすると、アプリが特定のタスクを繰り返すことがあり、 大量のコードを追加で記述する必要があります

次の例について考えてみましょう。この場合、WorkRequest のキャンセルにより、 困難：

  • バックエンド リクエスト: コンピューティングの最中に Worker をキャンセルした場合 新しい Worker を最初からやり直す必要があります。 コストがかかる可能性のあるペイロードを再計算します。
  • スケジュール: PeriodicWorkRequest をキャンセルして、 同じスケジュールで実行する新しい PeriodicWorkRequest のような場合は、 時間オフセットを計算して、新しい実行時間が調整されるようにする 前の処理リクエストと照合します

updateWork() API を使用すると、処理リクエストの制約と 新しいリクエストのキャンセルやキューへの登録の手間を省くことができます。

処理をキャンセルするタイミング

リクエストではなく、WorkRequest を直接キャンセルすべきケースがあります。 updateWork() を呼び出します。これが、変更したい場合はどうすればよいですか？ キューに入れた作業の基本的な性質についてです。

処理を更新するタイミング

ユーザーの写真を毎日バックアップする写真アプリについて考えてみましょう。機能 PeriodicWorkRequest をキューに登録しました。WorkRequest に制約がある デバイスを充電し、Wi-Fi に接続する必要があります。

しかし、お客様は急速充電ケーブルを使用して 1 日 20 分しか充電できない 充電してください。この場合、アプリは WorkRequest を更新して、 デバイスが充電されていても、 フル充電されていません。

この場合は、updateWork() メソッドを使用して処理を更新できます。 構成できます。

処理を更新する方法

updateWork() メソッドは、既存のバージョンを更新する簡単な手段です。 WorkRequest の 2 種類があります。新しいインスタンスをキャンセルしてキューに登録する必要はありません。

キューに登録された処理の更新を使用するには、次の手順を行います。

  1. キューに登録された作業の既存の ID を取得する: 必要な WorkRequest の ID を取得します。 更新します。この ID は、いずれかの getWorkInfo API を使用するか、最初のモジュールから ID を手動で 後でパブリック プロパティを使用して取得するための WorkRequest WorkRequest.id。キューに追加する前。
  2. 新しい WorkRequest を作成する: 新しい WorkRequest を作成し、 WorkRequest.Builder.setID() で、既存の ID と一致する ID を設定します。 WorkRequest。
  3. 制約を設定する: WorkRequest.Builder.setConstraints() を使用して、 WorkManager の新しい制約。
  4. updateWork: 新しい WorkRequest を updateWork() に渡します。

更新処理の例

この Kotlin のコード スニペットの例は、 使用する WorkRequest のバッテリーの制約を変更する updateWork() メソッド 写真をアップロードするには:

suspend fun updatePhotoUploadWork() {
    // Get instance of WorkManager.
    val workManager = WorkManager.getInstance(context)

    // Retrieve the work request ID. In this example, the work being updated is unique
    // work so we can retrieve the ID using the unique work name.
    val photoUploadWorkInfoList = workManager.getWorkInfosForUniqueWork(
        PHOTO_UPLOAD_WORK_NAME
    ).await()

    val existingWorkRequestId = photoUploadWorkInfoList.firstOrNull()?.id ?: return

    // Update the constraints of the WorkRequest to not require a charging device.
    val newConstraints = Constraints.Builder()
        // Add other constraints as required here.
        .setRequiresCharging(false)
        .build()

    // Create new WorkRequest from existing Worker, new constraints, and the id of the old WorkRequest.
    val updatedWorkRequest: WorkRequest =
        OneTimeWorkRequestBuilder<MyWorker>()
            .setConstraints(newConstraints)
            .setId(existingWorkRequestId)
            .build()

    // Pass the new WorkRequest to updateWork().
    workManager.updateWork(updatedWorkRequest)
}

結果を処理する

updateWork() は ListenableFuture<UpdateResult> を返します。指定された UpdateResult には、利用可能かどうかを示す複数の値のいずれかを指定できます。 WorkManager が変更を適用できました。また、マルウェアがいつ実行されたかも 変更を適用します

詳細については、updateWork() と UpdateResult をご覧ください。 リファレンスをご覧ください。

何世代にもわたって提出物を追跡する

WorkRequest を更新するたびに、その generation が 1 ずつ増加します。この を使用すると、現在キューに入っている WorkRequest を正確に追跡できます。 世代によって作業の監視、トレース、テストをより細かく管理 できます。

WorkRequest の世代を取得する手順は次のとおりです。

  1. WorkInfo: WorkManager.getWorkInfoById() を呼び出してインスタンスを取得します。 WorkRequest に対応する WorkInfo。
    • WorkInfo を返すメソッドのいずれかを呼び出すことができます。詳細 詳しくは、WorkManager リファレンスをご覧ください。
  2. getGeneration: のインスタンスで getGeneration() を呼び出します。 WorkInfo。返される Int は、Terraform の WorkRequest。
    • 世代フィールドやプロパティはなく、 WorkInfo.getGeneration() メソッドを使用します。

トラック生成の例

以下は、上記のワークフローの実装例です。 WorkRequest の世代を取得します。

// Get instance of WorkManager.
val workManager = WorkManager.getInstance(context)

// Retrieve WorkInfo instance.
val workInfo = workManager.getWorkInfoById(oldWorkRequestId)

// Call getGeneration to retrieve the generation.
val generation = workInfo.getGeneration()

処理の更新ポリシー

以前は、定期的な処理を更新するのに推奨される解決策は、 PeriodicWorkRequest は、ポリシー ExistingPeriodicWorkPolicy.REPLACE に置き換えます。 同じ一意の id を持つ保留中の PeriodicWorkRequest があった場合、新しい キャンセルして削除されます。このポリシーは非推奨になりました。 ExistingPeriodicWorkPolicy.UPDATE を使用してワークフローを選択します。

たとえば、enqueueUniquePeriodicWork を PeriodicWorkRequest、新しい PeriodicWorkRequest を ExistingPeriodicWorkPolicy.UPDATE ポリシー:保留中のアクションがある場合 PeriodicWorkRequest を同じ一意名で呼び出すと、WorkManager がこれを 新しい仕様です。このワークフローに沿って操作する場合、 updateWork()。