常に最新のコンプリケーションを

常に最新のコンプリケーションを

時間厳守はとても重要です：昼夜問わず、Apple Watchのコンプリケーションから関わりのある情報を送り続け、ユーザーに必要な情報を必要なタイミングで届ける方法をお伝えします。アプリケーションのランタイムを活用するための成功事例、バックグラウンドアプリケーションリフレッシュ、URLSessionといったAPIを統合する方法、適切なタイミングでプッシュ通知を実行する方法についてもお知らせします。

リソース
関連ビデオ

WWDC21
- 再往復: Apple Watch上のデータ転送
WWDC20
ダウンロード

こんにちはようこそWWDCへ “常に最新のコンプリケーションを” Apple Watchチームのソフトウェアエンジニアマイク･ラムです本日はコンプリケーションを常に最新の状態に保つ方法をご紹介しますコンプリケーションはApple Watchのユーザーエクスペリエンスに組み込まれています文字盤の共有やSwiftUIのコンプリケーション複数のコンプリケーションAPIと共に watchOS 7でリリースされますコンプリケーションは今年注目の Watch向けアプリケーションです Watchの文字盤に様々な情報を表示する機能をコンプリケーションと呼んでいます快適に使用するためにコンプリケーションは最新の状態に保ちましょう watchOSはコンプリケーションアプリケーションの特別な機能を提供します他のアプリケーションが停止しメモリから削除された時でも動き続けますシステムがそれを止める必要があったとしてもその後で再起動され更新されます
コンプリケーションは常に表示されているのでコンプリケーションアプリケーションは個人情報の取り扱いが考慮されていますアプリケーションが動的コンプリケーションを最新の状態に保つための方法を見ていきましょうサンプルのアプリケーションを説明することから始めましょう
アプリケーションがアクティブに使用されている時がコンプリケーションの更新にいいタイミングですではやってみましょうアプリケーションがフォアグラウンドで動いていない時でも watchOSはコンプリケーションを常に最新の状態に保つことができますバックグラウンド更新はまるで魔法のように素晴らしいです１つ目のバックグラウンド更新機能は “Background App Refresh”です Background App Refreshによりアプリケーションはバックグラウンドランタイムをスケジュールして WatchのAPIとデータにアクセスできるようになりますさらにアプリケーションが動いていない間にサーバからデータを取得するために URLSessionをバックグラウンドでスケジュールすることも出来ますその時データはコンプリケーションのPushを使用して Watchのアプリケーションに直接送られますこの方法はセッションの最後に説明します
重要なポイントは３つの各バックグラウンド機能のためにアプリケーションがアクティブである必要がない点です更新する必要がある時にコンプリケーションは起動しますこれら全ての機能はアプリケーションの必要に応じて別々にも組み合わせても使用できますコンプリケーションを最新の状態に保つ方法を “kite flying app”を使って説明します我々は電話を必要としないでいられる体験を提供することを目指し独立したWatch向けのアプリケーションを構築しています複数のアクティブなコンプリケーションをサポートするために watchOS 7で利用可能な新しいAPIを使用します繰り返しになりますが本日紹介するのはコンプリケーションを最新の状態に保つ方法です設計や構築の方法については他のセッションをご覧ください我々は人々がアプリケーションによってより活動的になることを願っているので最初のコンプリケーションはHealthKitから１日の活動についての情報を取り出しますデータを取り出すために Background App Refreshを使います凧揚げをするには天気を知りたいですね特に風についての気象データが必要になりますバックグラウンドでURLSessionを使用し最後にキャッシュされた場所の気象データを定期的に得ることができます凧揚げを盛り上げるために友達からの声援を表示できるコンプリケーションはいかがでしょうコンプリケーションの更新にはコンプリケーションのPushを使いますまずはフォアグラウンドでの更新について話しましょうユーザーがアプリケーションを起動している時はコンプリケーションを更新するのに適しています表示したい更新がある時はコンプリケーションのタイムラインをリロードするために ClockKitのAPIを使用しますコンプリケーションはタイムラインのエントリーで構成されていますアプリケーションがコンプリケーションの更新を求めるとそのコンプリケーションのreloadTimelineをコンプリケーションのサーバに呼び出します
ここに書いたのは updateActiveComplicationsメソッドですアプリケーション全体において使うものです
このメソッドはアクティブなコンプリケーションの配列を繰り返し１個ずつリロードすることをコンプリケーションのサーバに要求しますこのサンプルでは毎回全てのコンプリケーションを更新しますが通常は更新が必要なものだけを更新すればいいですコンプリケーションを更新する時は updateActiveComplicationsを呼び出します
reloadTimelineが updateActiveComplicationsに呼び出された後コンプリケーションサーバはアプリケーションの CLKComplicationDataSourceを呼び出します現在のタイムラインのエントリーを得るためです
その後テンプレートとプロバイダを使用してアプリケーションはエントリーを作成します
エントリーを作成し終えると提供された完了ハンドラを使いそれをコンプリケーションのサーバに渡します
これがコードです reloadTimelineが updateActiveComplicationsに呼び出された後 CLKComplicationDataSourceが呼び出されます更新するコンプリケーションの現在のタイムラインのエントリーが要求されます
ハンドラはそれが構築された後エントリーを返すために提供されます
コンプリケーションのタイプに適したテンプレートを使用しますテンプレートにプロバイダを入力してタイムラインのエントリーを作成しますエントリーが作成されたら提供されたハンドラを使ってエントリーを返しますフォアグラウンドでのコンプリケーションの更新は簡単ですコンプリケーションのサーバにコンプリケーションのリロードを要求しそれから１個ずつ現在のエントリーを供給しますこれはユーザーがプリケーションで選択を変更するかアプリケーションがフォアグラウンドで新しいデータを受信するたびに行います
しかしアプリケーションがフォアグラウンドで動いていない時もありますその場合はコンプリケーションを更新するために必要なデータを得るために Background App Refreshのような機能を使います
サンプルのアプリケーションに戻ってアクティビティのコンプリケーションのために HealthKitからデータを取得してみましょう
Background App Refreshにより定期的な更新をスケジュールすることでアプリケーションが使用されていない場合でもコンプリケーションは最新の状態に保たれます
アプリケーションはコンプリケーションを更新するために１時間に４回まで Background App Refreshを使えますこの回数はアプリケーションのコンプリケーションがアクティブな文字盤に設定される回数に関わらず変わりませんアプリケーションが受け取る更新の実際の回数は他のプロセスが実行された回数やバッテリーの使用量などの状況に左右されます
Background App Refreshをスケジュールするために scheduleBackgroundRefreshが WKExtentionに呼び出されますこれはバックグラウンドでアプリケーションが起動していても可能なので applicationDidFinishLaunchingで最初のリクエストをスケジュールしましょう
Background App Refreshをスケジュールするためのメソッドを書きましたまず予定日を選びますこれが最初のリクエストですすぐにリクエストしますシステムはアプリケーションを起動する正しい時間を選びますこれはリクエストした時間以降になります通常１分か２分以内ですがシステムの状況によりますあなた自身のデータを提供するためには userInfo dictionaryを使いますこの場合実行される方法を示すためにリクエストが行われた時間を渡します
予定日とオプションのuserInfoを得ると WKExtentionに scheduleBackgroundRefreshを呼び出します
リクエストがスケジュールされると WKExtentionは非同期で完了ハンドラをメインスレッドに呼び出します発生した可能性のあるエラーを処理します
タスクが準備されるとアプリケーションがアクティブになりバックグラウンドのタスクをハンドルするために ExtentionDelegateが呼び出されます
処理の後コンプリケーションの更新をリクエストし次のBackground App Refreshをスケジュールしてタスクの完了を設定します
では ExtentionDelegateを見てみましょう XcodeがExtentionDelegateを生成すると backgroundTasksをハンドルするためのメソッドも生成されます
システムには完了する必要のある複数のタスクがある場合があります ExtentionDelegateは全てのタスクをループし１つずつ呼び出します
生成されたコードはデフォルトのハンドラをアプリケーションが受け取ることができる全タイプのバックグラウンドタスクに提供します
WKApplicationRefreshBackgroundTaskをハンドリングしてデフォルトのハンドラを我々のコードに置き換えています
ここでは例としてリクエストのスケジュール時に追加したuserInfoを検索しますリクエストからの時間を計算するためにその中に記憶した日付を使用しますその後updateActiveComplicationsメソッドを呼び出してアクティブなコンプリケーションのリロードをコンプリケーションのサーバに要求しますそれから次のバックグラウンド更新をスケジュールしますコンプリケーションを更新し別のリクエストをスケジュールすれば現在のタスクは完了しますスナップショットは必要でないことを示す “false”になりますそれぞれのコンプリケーションの更新はスナップショットのリクエストにつながるため個々にリクエストする必要はありません
アプリケーションはバックグラウンドのタスクが完了次第すぐに停止するかもしれないのでタスクの完了を設定する前に全ての処理を行う必要があります
HealthKitへのアクセスなどより複雑なことをするにはストラテジーを変更する必要があります
ExtentionDelegateにコードを入れすぎないために HealthKitを使用するデータプロバイダを追加しましたそしてそれ自身の完了ハンドラを受け取るメソッドを追加しています
HealthKitのクエリは非同期になる可能性がありますそのため更新が完了するまで待ってからコンプリケーションを更新し次のリクエストをスケジュールしてタスクの完了を設定する必要があります
これを簡単に実行することを可能にするのが HealthKitの作業を行う新しいHealthDataProviderです
このデータを更新するために HealthDataProviderを呼び出します非同期で行います
データの更新が終わるとコンプリケーションが更新したかを問う完了ハンドラを呼び出します完了ハンドラの中で実際にコンプリケーションを更新し次の更新をスケジュールしそしてタスクの完了を設定します
つまりBackground App Refreshは定期的なバックグラウンドのタスクをスケジュールするのに最適なのですこれらのタスクをハンドルするために１時間に最大４回までアプリケーションを再開もしくは起動することができます覚えておくべきガイドラインを挙げましょう
一度にリクエストできる未処理のリクエストの数は１つだけです定期的な更新を必要であればご紹介した手順を実行してくださいそして現在の更新を完了する前に次の更新をスケジュールしますネットワークのアクティビティは許可されていません WatchでほとんどのAPIが使用可能ですが URLSessionは例外ですもしURLSessionを使おうとしてもエラーになります
アプリケーションはアクティブなCPU時間の最大４秒までに制限されています短いと思われるかもしれませんが一定の処理の４秒間は実はかなり長いのですそれより長い処理が必要な場合は小さいチャンクに分割してください
アプリケーションがタスクを完了するための合計時間は最大15秒です 15秒を超える理由として一般的なのはタスクの完了を設定し忘れていることです
バックグラウンドでネットワークからデータにアクセスする必要がある場合は Background URLSessionを使ってください Background URLSessionはアプリケーションを実行していない時でもアプリケーションをスケジュールしてデータを受信できるようにします
Background App Refreshに加えて Background URLSessionが使えますリクエストを素早く変更することや認証チャレンジを挿入することも出来ます
追加予定のローカライズされた “風”のコンプリケーションで気象情報を検索するためにそれを使いますほとんどの状況下でアプリケーションは１時間に４回までリクエストを送受信できますが実際の回数は Wi-Fiの利用や携帯電話の電波― バッテリーの寿命などの要因に左右されます
複数の未処理のバックグラウンドでのダウンロードタスクが実行できますアプリケーションの起動時は常にセッションにアタッチして URLSessionデリゲートコールバックを受信できるようにしてくださいまずBackground URLSessionをスケジュールする方法を説明しましょう
このアプリケーションでは定期的に気象データを得たいの URLSessionのフレームワークを使います URLSessionデリゲートになる WeatherDataProviderを作成しましたデータプロバイダはBackground URLSessionのコンフィギュレーションを作成しますバックグラウンドでアプリケーションを動かすためにバックグラウンドのコンフィギュレーションに sessionSendsLaunchEventを設定しますダウンロードタスクでURLSessionを作成するためコンフィギュレーションを使用しますタスクの一番早い開始日を設定しますタスクがスケジュールされている日付になります次にタスクを再開始して開始しますこれがWeatherDataProviderの最初の部分です URLSessionDownloadDelegateです URLSessionを作成するためには次のようにしますバックグラウンドのコンフィギュレーションを取得 “nondiscretionary”としてコンフィギュレーションを設定 sessionSendsLaunchEventsが “true”に設定してあることを確認これでアプリケーションはバックグラウンドで起動しますそれからURLSessionを作成するためにコンフィギュレーションを使いますそしてdelegateQueueを “nil”に設定する場合は URLSessionのレスポンスはバックグラウンドのシリアルキューに送られます WeatherDataProviderを引き続き使用して scheduleメソッドを追加しましたこれによりダウンロードタスクを作成しスケジュールすることができます未処理のリクエストは複数がありますがこの場合１つしか必要ないため未処理のリクエストがない限り新しいバックグラウンドタスクをスケジュールします Core Locationから最後にキャッシュされた場所を使って必要なURLを構築しバックグラウンドのセッションのためのダウンロードタスクを作成しますこのタスクに一番早い開始日を設定します最初のリクエストをすぐに作成し後続のリクエストを 15分ごとにスケジュールします送受信する予定のバイト数を設定し最後に実行準備をするタスクを再開始しますスケジュールした後ダウンロードタスクはアプリケーションから独立して実行します完了したらアプリケーションはバックグラウンドで再開始するかリクエストをハンドルするために必要に応じて起動します
ダウンロードが完了すると WKExtentsion WKURLSessionRefreshBackgroundTaskを extension delegateに送ります
リクエストをハンドルするために WeatherDataProviderを使用します
タスクが終了したことを設定するまで URLSessionのデリゲートメソッドは処理されますこれらの呼び出しをハンドリングする前にタスクの完了を設定しないでください
タスクが正常に完了したならデリゲートは didFinishDownloadingToデリゲートの呼び出しを受け取りますダウンロードが正常に完了したかどうかにかかわらずデリゲートは didCompleteWithOptionalErrorを受け取ります呼び出しが完了すると WeatherDataProviderが与えられた完了ハンドラを呼び出しますそしてコンプリケーションを更新し新しいリクエストをスケジュールしてそれからタスクの完了を設定します
スケジュールしたダウンロードタスクが完了したら次は結果をハンドルしますセッションのデリゲートは WKURLSessionRefreshBackgroundTaskをハンドルすることを要求されますセッションのデリゲートは WeatherDataProviderに更新を要求し完了時に呼び出されるclosureを渡します
更新が完了すると WeatherDataProviderがclosureを呼び出しますそのclosureの中で次の検索をスケジュールし必要に応じてコンプリケーションを更新しそれからタスクの完了を設定します WeatherDataProviderの中で refreshメソッドが― 完了ハンドラを保存しますスケジュールされたデリゲートメソッドが実行されたら呼び出せます WeatherDataProviderはタスクが完了されてから URLSession delegate method downloadTask didFinishDownloadingToを受け取ります要求したデータはファイルにダウンロードされるのでそれを確認しますそれから受け取った json気象データを処理します
ダウンロードタスクが完了しデータが処理されるとアプリケーションは didCompleteWithOptionalErrorを受け取ります完了ハンドラをメインキューに呼び出したいのでメインキューにディスパッチし完了ハンドラを呼び出しますエラーが全く無ければコンプリケーションを更新していますその時完了ハンドラを“nil”に設定すればそれ以上呼び出されません
リクエストによってはダウンロードの完了前にアプリケーションが中間リクエストを受け取りアプリケーションがURLを更新したりダウンロードタスクをキャンセルさせたり認証チャレンジに応答できたりします
これらを簡単に見ていきましょうこれまで見てきたURLSessionタスクに関連する他のケースのように WKURLSessionRefreshBackgroundTaskとしてこれらはアプリケーションに処理されます ExtentionDelegateはこれらのタスクをハンドルすることを要求されますこれらのリクエストをハンドルするために WeatherDataProviderを使いますタスクがアクティブな間に WeatherDataProviderは URLSessionサブシステムからデリゲートの呼び出しを受け取ります
WillBeginDelayRequestによりアプリケーションで― URLのリクエストの更新やキャンセルができます例えばもしリクエストを開始してから長時間が経過したなら最初にリクエストを行ったときに指定した場所を Core Locationの最後にキャッシュされた場所に置き換えます
DidReceiveChallengeがアプリケーションに発生する― 可能性のある認証チャレンジに応答しますデリゲートがSessionDidFinishEventsを受け取るのは全てのイベントが処理された時でありこれが完了ハンドラを呼び出す時です
この時新しいタスクをスケジュールしたいかもしれませんが現在のタスクが完了していないのでやめておきましょうその代わりにこのタスクが完了したとして設定しますこのガイドラインは Background App Refreshのものと同じです
負荷のかかる処理は避けるべきですそして処理を受けてから15秒以内にタスクの完了を設定してください Background URLSessionは遠隔のサーバからデータを検索することに優れています必要に応じてスケジュールしたり修正またはキャンセルしたり出来ます
本日紹介する最後の機能はコンプリケーションのPushですユースケースによっては Pushはサーバから取り出すデータよりもより効率的です
これは特にイベントドリブン型データに顕著ですコンプリケーションのPushを使い最新のコンプリケーションにデータを供給しますこれにより凧揚げをする仲間からの声援を追跡することができますサーバは各Watchに１日に最大50個までコンプリケーションのPushを送れますコンプリケーションのPushは等間隔にする必要はありませんデータがバースト伝送になる場合は今までに説明した他の機能よりもリクエストが速く送られるでしょう１日の容量を超過することを防ぐために調整する必要があるかもしれません
WatchにPushを送っているサーバは適切な認証を受ける必要がありますでは簡単にその設定方法を見てみましょうまずアプリケーションのバンドルIDを含む識別子が必要です “.watchkitapp.complication”を後ろに続けます　これは重要ですアプリケーションIDが正しい形式になっていない場合 PushはAppleのサーバにより拒否されるか Watchで受信されないかもしれません
.complicationの付いたアプリケーションIDが作成されたら Apple Push Notification service SSL証明書を作成するためにそれを使いますサーバはその証明書を使用して AppleのPush通知サーバを認証します
アプリケーションには WatchKit extensionのリモート通知バックグラウンドモードと Push通知機能も必要です
Watch向けでは PushKitに登録するために PushNotificationProviderを使います
登録が成功しするとアプリケーションは認証を受け取りますこれらの資格情報をサーバにアップロードしてサーバがWatchと通信できるようにしますこれはPushNotificationProviderで PKPushRegistryDelegateです PKPushRegistryのインスタンスを作成しコールバックにメインキューを供給しますそれ自身をデリゲートとして設定します
またdesiredPushTypeを.complicationに設定しますこれはサーバに作成してインストールした .complication識別子と証明書に一致します
登録が完了するとレジストリは資格情報と didUpdate pushCredentials呼び出しを返しますこれらの資格情報をサーバに送信しアプリケーションのインスタンスと通信できるようにします
Watchがその認証をサーバにアップデートしたらサーバはこれらの資格情報を使用してそのWatchのPushをAppleサーバに送信します AppleサーバはそれらをWatchに送ります各Watchに１日あたり50個のPushが可能です
コンプリケーションのPushを送る時はバックグラウンドPushと同じようにフォーマットして aps dictionaryにある content-availableのエントリーを提供します PushがWatchでPushKitにより受け取られると didReceiveIncomingPushWithPayloadでアプリケーションに渡されます Pushの処理が終了した後の呼び出しのために完了ハンドラが用意されています
PushNotificationProviderの実装に戻ります Pushが可能になるとアクティブでない場合アプリケーションは再開始または起動されます
didReceiveIncomingPush payload for typeがデリゲートに呼び出されます PushKitへの登録時に指定するキューはこの呼び出しを行うために使用されます
この場合はこれがメインキューです
完了ハンドラが提供されますペイロードが処理された時に呼び出されますペイロードを処理し extension delegateを呼び出してコンプリケーションを更新しますこれで全てのコンプリケーションを更新していますもしこれがshippingアプリケーションだったなら必要なコンプリケーションだけを更新したいでしょうではコンプリケーションの Pushについて復習していきますアプリケーションの各インスタンスは１日50個まで受け取れます複数のアクティブなコンプリケーションが― アプリケーションにあってもその数は変わりません
ガイドラインは他のタイプのバックグラウンド更新の場合と同じです本日説明した技術をまとめますアクティブな時はフォアグラウンドの状態でコンプリケーションを更新してください特にこれを行うべき時は入力に応じてアプリケーションの状態が変化する場合やフォアグラウンドの状態の時にサーバからデータを取り出す場合です
アプリケーションがフォアグラウンドからバックグラウンドに移動する時に処理を完了するため ProcessInfoのアクティビティを使用します
Background App Refreshは HealthKitなどのwatchOS APIの使用やあなた自身のデータへのアクセスのためのランタイムをスケジュールするのに最適ですバックグラウンドの更新は１時間に４回までコンプリケーションの更新のために使用できます
サーバからデータを取り出すために Background URLSessionのタスクは１時間に４回までスケジュールすることが出来ますアプリケーションが動いている時は常にデリゲートを再アタッチしてくださいそうすることで保留になっているかもしれない更新を受け取ることが出来ます
Push通知は１日50回までサーバから各Watchへ送られますデータがバースト伝送になる場合は一定の間隔を置くかもっと頻繁に送ってください 51回目以降の通知は無視されるため必要に応じてサーバにスロットルを適用しますこれらの機能を必要に応じて個別にまたは組み合わせて使用してくださいコンプリケーションを常に最新状態に保つことがいかに重要であるか分かるでしょうアプリケーションがアクティブでない時でもコンプリケーションを常に最新の状態に保つための機能が複数あります最高の体験のために本日学んだ技術を組み合わせてみてください本日説明した全ての機能は独立した Watch向けアプリケーションで使用できます “Meet Watch Face Sharing”セッションは最新のコンプリケーションAPIを詳しくを説明しています “Build Complications in SwiftUI”は SwiftUIを使用してコンプリケーションを構築する方法を説明しています昨年の“Creating Independent Watch Apps”も含め是非ご覧になってくださいこれらの技術を使用してコンプリケーションを構築してみてください引き続き WWDCをお楽しみください

class ExtensionDelegate: NSObject, WKExtensionDelegate {

    func updateActiveComplications() {

       let complicationServer = CLKComplicationServer.sharedInstance()

        if let activeComplications = complicationServer.activeComplications {

            for complication in activeComplications {

               complicationServer.reloadTimeline(for: complication)

            }
        } 
    }
}

4:26 - getCurrentTimelineEntry

class ComplicationController: NSObject, CLKComplicationDataSource {

    func getCurrentTimelineEntry(for complication: CLKComplication, 
        withHandler handler: @escaping (CLKComplicationTimelineEntry?) -> Void) {

        switch (complication.family) {
  
        case .modularSmall:
           let template = CLKComplicationTemplateModularLargeTallBody.init(
                               headerTextProvider: headerTextProvider, 
                               bodyTextProvider: bodyTextProvider)

            entry = CLKComplicationTimelineEntry(date: Date(), 
                        complicationTemplate: template)
        }

        handler(entry)
    }
}

6:06 - scheduleBar

private func scheduleBAR(_ first: Bool) {
        let now = Date()
        let scheduledDate = now.addingTimeInterval(first ? 60 : 15*60)

        let info:NSDictionary = [“submissionDate”:now]

        let wkExt = WKExtension.shared()
        wkExt.scheduleBackgroundRefresh(withPreferredDate: scheduledDate, userInfo:info)
        { (error: Error?) in
            if (error != nil) {
                print("background refresh could not be scheduled \(error.debugDescription)")
            } 
        }
   }

7:08 - handleBAR

class ExtensionDelegate: NSObject, WKExtensionDelegate {
    func handle(_ backgroundTasks: Set<WKRefreshBackgroundTask>) {

        for task in backgroundTasks {

          switch task {
          case let backgroundTask as WKApplicationRefreshBackgroundTask:

                if let userInfo:NSDictionary = backgroundTask.userInfo as? NSDictionary {
                   if let then:Date = userInfo["submissionDate"] as! Date {
                      let interval = Date.init().timeIntervalSince(then)
                      print("interval since request was made \(interval)")
                   }
                }

                self.updateActiveComplications()

                self.scheduleBAR(first: false)

                backgroundTask.setTaskCompletedWithSnapshot(false)

8:47 - handleBAR (DataProvider)

class ExtensionDelegate: NSObject, WKExtensionDelegate {

    var healthDataProvider: HealthDataProvider

    func handle(_ backgroundTasks: Set<WKRefreshBackgroundTask>) {
        for task in backgroundTasks {
            switch task {
            case let backgroundTask as WKApplicationRefreshBackgroundTask:

                healthDataProvider.refresh() { (update: Bool) -> Void in
                    if update {
                        self.updateActiveComplications()
                    }
                    self.scheduleBAR(first: false)
                    backgroundTask.setTaskCompletedWithSnapshot(false)
                }

11:35 - Instantiate backgroundURLSession

class WeatherDataProvider : NSObject, URLSessionDownloadDelegate {

    private lazy var backgroundURLSession: URLSession = {
        let config = URLSessionConfiguration.background(withIdentifier: “BackgroundWeather")
        config.isDiscretionary = false
        config.sessionSendsLaunchEvents = true

        return URLSession(configuration: config, delegate: self, delegateQueue: nil)
    }()

12:02 - Schedule backgroundURLSessionTask

func schedule(_ first: Bool) {

        if backgroundTask == nil {

            if let url = self.currentWeatherURLForLocation(delegate.currentLocationCoordinate)
            {
                let bgTask = backgroundURLSession.downloadTask(with: url)

                bgTask.earliestBeginDate = Date().addingTimeInterval(first ? 60 : 15*60)

                bgTask.countOfBytesClientExpectsToSend = 200
                bgTask.countOfBytesClientExpectsToReceive = 1024

                bgTask.resume()

                backgroundTask = bgTask
            }
        }
    }
}

13:29 - handle backgroundURLSession

class ExtensionDelegate: NSObject, WKExtensionDelegate {

   var weatherDataProvider:WeatherDataProvider

    func handle(_ backgroundTasks: Set<WKRefreshBackgroundTask>) {
       for task in backgroundTasks {
           switch task {
            
                case let urlSessionTask as WKURLSessionRefreshBackgroundTask:

                    weatherDataProvider.refresh() { (update: Bool) -> Void in
                        weatherDataProvider.schedule(first: false)
                        if update {
                            self.updateActiveComplications()
                        }
                        urlSessionTask.setTaskCompletedWithSnapshot(false)
                    }

13:59 - handle backgroundURLSession

class WeatherDataProvider : NSObject, URLSessionDownloadDelegate {

    var completionHandler : ((_ update: Bool) -> Void)?

    func refresh(_ completionHandler: @escaping (_ update: Bool) -> Void) {

        self.completionHandler = completionHandler

    }

14:08 - didFinishDownloadingTo

class WeatherDataProvider : NSObject, URLSessionDownloadDelegate {

    func urlSession(_ session: URLSession, downloadTask: URLSessionDownloadTask,
                    didFinishDownloadingTo location: URL) {

        if location.isFileURL {
            do {

                let jsonData = try Data(contentsOf: location)
                if let kiteFlyingWeather = KiteFlyingWeather(jsonData) {
                    // Process weather data here.
                }

            } catch let error as NSError {
                print("could not read data from \(location)")
            }
        }
    }

14:23 - didComplete

func urlSession(_ session: URLSession, task: URLSessionTask, 
                     didCompleteWithError error: Error?) {

        print("session didCompleteWithError \(error.debugDescription)”)

        DispatchQueue.main.async {

           self.completionHandler?(error == nil)

            self.completionHandler = nil

        }
    }
}

17:53 - Complication Pushes

class PushNotificationProvider : NSObject, PKPushRegistryDelegate {

    func startPushKit() -> Void {
        let pushRegistry = PKPushRegistry(queue: .main)
        pushRegistry.delegate = self
        pushRegistry.desiredPushTypes = [.complication]
    }
  
    func pushRegistry(_ registry: PKPushRegistry, 
                      didUpdate pushCredentials: PKPushCredentials, for type: PKPushType) {
        // Send credentials to server 
    }
  
    func pushRegistry(_ registry: PKPushRegistry, 
                        didReceiveIncomingPushWith payload: PKPushPayload, 
                        for type: PKPushType, completion: @escaping () -> Void) {
        // Process payload
        delegate.updateActiveComplications()
        completion()
    }

特定のトピックをお探しの場合は、上にトピックを入力すると、関連するトピックにすばやく移動できます。

クエリの送信中にエラーが発生しました。インターネット接続を確認して、もう一度お試しください。

リソース

関連ビデオ

WWDC21

WWDC20