使用するdelegate methodの違い
iOS 7以降
- いかなる種類のPush通知においてもapplication:didReceiveRemoteNotification:fetchCompletionHandler:を使用します。
- application:didReceiveRemoteNotification:fetchCompletionHandler:とapplication:didReceiveRemoteNotification:が両方実装されている場合も、application:didReceiveRemoteNotification:fetchCompletionHandler:しか呼び出されません。application:didReceiveRemoteNotification:fetchCompletionHandler:のみ考えればOKです。
- ただし、application:didReceiveRemoteNotification:が実装されており、application:didReceiveRemoteNotification:fetchCompletionHandler:が存在しない場合は、iOS 6以前同様の挙動になります。
- 以下、長ったらしいのでapplication:didReceiveRemoteNotification:fetchCompletionHandler:を新メソッドと呼称します。
iOS 6以前
- application:didReceiveRemoteNotification:を使用します。
- 新メソッドが実装してあっても一切反応しません。
- 以下、長ったらしいのでapplication:didReceiveRemoteNotification:を旧メソッドと呼称します。
挙動の違いまとめ
以下に表にしてまとめました。ここで、iOS 7以降とは新メソッドを使用する場合、iOS 6以前とは旧メソッドを使用する場合のことを指します。
| iOS 6以前 | iOS 7以降 | |
|---|---|---|
| 初回起動 | application:didFinishLaunchingWithOptions:に UIApplicationLaunchOptionsRemoteNotificationKeyが付いて呼び出される。 旧メソッドは呼び出されない。 | application:didFinishLaunchingWithOptions:に UIApplicationLaunchOptionsRemoteNotificationKeyが付いて呼び出される。 その後、UIApplicationStateActiveの状態で、新メソッドも呼び出される。 handlerについては、content-available指定が1の場合のみ付いてくる（未確認）。 |
| 起動中 | UIApplicationStateActiveの状態で、旧メソッドが呼び出される。 | UIApplicationStateActiveの状態で、新メソッドが呼び出される。 handlerについては、content-available指定が1の場合のみ付いてくる（未確認）。 |
| 未起動 | UIApplicationStateInactiveの状態で、旧メソッドが呼び出される。 | UIApplicationStateInactiveの状態で、新メソッドが呼び出される。 handlerについては、content-available指定が1の場合のみ付いてくる（未確認）。 |
| データ取得 | 不可能。 | UIApplicationStateBackgroundの状態で、新メソッドが呼び出される。 handlerは必ず付いてくる。 この通知がアラートや通知センターに表示された場合、ユーザーがそれらとインタラクションしたらさらにもう一回UIApplicationStateInactiveの状態で新メソッドが呼び出される。 |
バックグラウンドでの通知受け取りとデータ取得
iOS 7から、Push通知のペイロードのapsオブジェクトにcontent-availableというプロパティが新たに追加されました。content-availableプロパティの値を数字の1に設定すると、ユーザーのインタラクションを介さずにバックグラウンドでアプリケーションが起き上がることができ、サーバから最新のデータの取得を行ったりする事が可能です。詳しくは「Push通知 バックグラウンド iOS7 content-available」とかその辺の単語を適当に組み合わせてググってください。山ほど解説しているページがあります。サイレント通知が届かないときの処方箋
さて、上記バックグラウンドでの通知受け取りとデータ取得について、余り解説が見当たらなかった点についてまとめました。iOS 7以降のPush通知は、apsオブジェクトのalertプロパティの有無とcontent-availableプロパティの有無によって挙動が変わります。具体的には以下の表のようになります。
| content-availableがある | content-availableがない | |
|---|---|---|
| alertがある | 通常通知 同時にバックグラウンドデータ取得も可能 | 通常通知 |
| alertがない | サイレント通知 バックグラウンドデータ取得のみ可能 | 送信できない |
content-availableがない場合はiOS 6以前のPush通知と全く同じなので説明を割愛します。次にcontent-availableとalert両方が指定されている場合ですが、これはiOS 6以前の通常通知と基本は同じで、異なる点は通知を受け取った瞬間にバックグラウンドでアプリが立ち上がってデータの取得ができるという点だけです。したがいましてちょっと上記に記載しましたが、通知を受け取った瞬間と、ユーザーがインタラクションした瞬間で2回新メソッドが呼び出されるので、必ず新メソッドの中でUIApplicationStateを見て処理を分岐するようにしてください。
問題になってくるのがcontent-availableだけが指定されている通知、サイレント通知についてです。ほかのサイトでもよく紹介されていますが、この通知を使ってバックグラウンドでアプリを起動させて最新のデータをダウンロードしたりすることができます。以下にサイレント通知のペイロードの例を示します。
上が通常のサイレント通知ですが、下のようにサイレント通知と同時にバッジの数を更新することもできます。
さてこのサイレント通知ですが、とにかく「届かない！」というトラブルを耳にします。実際私が試した際にもなかなか届かないで弱りました。そこで調査したところ、サイレント通知のペイロードを工夫することできちんと通知が到達するようになりました。以下に到達率を改善したサイレント通知のペイロードの例を示します。
ご覧のように、空のsound要素を追加することで到達率が劇的に向上します。また2つ目の例のように、priorityというプロパティを10に設定するとこれまた到達率が劇的に向上します。どうやらこのpriorityプロパティはalertプロパティかsoundプロパティが設定されている場合はデフォルト10に、設定されていないサイレント通知の場合はデフォルト5に設定されているようで、それが原因で到達しない事が多いということがわかりました。
参考記事: http://stackoverflow.com/questions/19239737/silent-push-notification-in-ios-7-does-not-work
それから、Xcode上からプロジェクトのCapabilitiesの設定をするとき、Background fetchとRemote notificationsの両方の指定がおそらく必須と思われます。中にはRemote notificationsだけ設定しておけば良いと解説しているところもありますが、どうやらRemote notificationsは通知を受け取る箇所までだけで、肝心のバックグラウンドでのデータの取得はBackground fetchがないと実行できないのではないかと思われます。
