iOS 10などで使えるようになるUserNotificationsフレームワークへの所感
WWDC16. Meetup @Wantedly with 日本経済新聞社にて久々に発表しました( ´･‿･｀)
| 自己紹介 | ちょっと遠目から |
|---|---|
 |
 |
10分間のLTの割に盛り込みすぎて予定通り、全て話し切れ無かったので、フォローアップ記事です。
スライド31ページ目まででUserNotificationsをほぼ網羅的に紹介してそこで時間切れでしたが、32ページ目から実際にプロダクト上で実装するにあたっての検討事項や悩ましいところについて用意していました。
そのあたりについてざっと記事にします。
(今回はあえて口頭の説明込みじゃないと分かりにくいかな、みたいなスライドにしているので31ページまでも記事化したいなと思いつつけっこう大変なので迷い中です🤔)
では、以下32ページ目以降の内容を記事化したものです:
iOSバージョン差異による実装の複雑化
2016年5月9日時点でのiOSバージョンのシェアはこのようになっています。
(最新のデータはこちら参照: App Store - Support - Apple Developer)
直感的に、最新バージョンがリリースして半年以上経過した状態でも大体のアプリでは2世代以上はサポートしないと良くないかなという感じが読み取れると思います。
一方、通知周りのAPIは、〜iOS 7・iOS 8/9・iOS 10〜でざっくり次のような違いがあります。
(iOS 8では、ローカル通知許可確認が追加された影響でそれと統合される形でリモート通知用のAPIに変更が生じました。)
| API | 機能 | イメージ | |
|---|---|---|---|
| 〜iOS 7 | UIKit(registerForRemoteNotificationTypes:など) | 通知, バッジ, 音, バイブレーション, バックグラウンド・サイレント通知 (iOS 7) |  |
| iOS 8/9 | UIKit (registerUserNotificationSettings:,registerForRemoteNotificationsなど) | アクション選択(iOS 8)・テキスト入力(iOS 9) |  |
| iOS 10 | UserNotificationsフレームワーク | ローカル通知改善, メディアアタッチメント, 通知管理, アプリ内通知, App Extensions(Service・Content) |  |
UsersNotificationsフレームワークで、iOS・tvOS・macOSの各プラットフォームの通知関連の処理がほぼ全て集約されてAPIも使いやすく刷新された、ということは素晴らしいのですが、現実的には以前のバージョンのサポートも同時にしなければいけないことが多く、その場合逆に複雑化してしまいます。
通知周りで細かい制御しようとするとただでさえ複雑なのに、混在するとけっこう厄介かなと思います。
以前のAPIでiOS 10上で通知は動くか？
そこで、iOS 10でもiOS 8/9と同じやり方で通知が届くのか試してみたところ、届くことが確認出来ました。(Xcode 8 beta1・iOS 10 beta1実機の組み合わせで確認)
まだβなので安心しない方が良いとは思いますが、正式リリースが近くなったらテストして問題無く動くか確認し、さらに新フレームワークの機能が必要で無ければ何も対応しない、という選択肢も充分ありなのではとも感じました。
iOS 8でAPIに変更が生じたタイミングでは、既存コードのまま新しいSDKでビルドするとiOS 8端末にプッシュ通知が届かなくなってしまう、という問題があって、少し騒ぎになりました。今回は大丈夫そう、という感触です。
もちろんきちんと対応してiOS 10ユーザーのUX向上だったり、新機能を使うことでAppStoreでフィーチャーされやすくなるということを狙うのも良いと思いますし、僕自身も新機能を活用したアプリにたくさん触れたいと思っていますが。
ライブラリに頼る
また、delegate系の処理を使いやすくバージョン間の揺れなど埋めつつ統一的にラップするようなライブラリもあり、その1つであるSuperDelegateはiOS 10対応も予定されているので、混在の辛さはこういうのに頼る、という選択肢もありかもしれません。
(あるいはこのライブラリが需要に合わなければ、同様の方針でより良いものを自ら作るなど。)
1.0 – Will be released when iOS 10 is near release.
iOS 10の通知APIの活用のために必要なこと
次に、ちょっと対応手こずるかなと思った点について述べます。
リモート通知のidentifierの利用
スライド17-18の、通知管理についてのところで、その管理はidentifierベースで行い、リモート通知の場合はapns-collapse-idというHTTP/2 request headerに値を設定する、と述べました。
これまでサーバーでのプッシュ通知ハンドリングは、バイナリAPIというWeb標準ではない独特のものでしたが、HTTP/2ベースの新しいAPIが登場し、その利用が必要です。
(参考: APNs Provider API)
HTTP/2ベースの新しいAPIは、2015年のWWDCで発表されて、同年12月から実際に使えるようになりました。
(参考: Apple Push Notification Service Update - News and Updates - Apple Developer)
おそらくですが、ほとんどのプッシュ通知サービスはこの新しいAPIに対応していないはずです。
(参考にAmazon SNSの情報: AWS Developer Forums: Will SNS offer the new APNS features ...)
なので、これを利用するためには現状、自前のハンドリングが必要になってくるはずです。
HTTP/2ということで自前で扱いやすいはずですが、FirebaseやAmazon SNSなどを使うと便利なことも多いですし、移行コストなどもあるのでけっこう悩ましいところかと思います。
せっかく自前ハンドリングに移行したと思ったら、その後すぐプッシュ通知系サービスが対応しちゃった、などもあり得そうですし。
個人的には、どうしても必要ということで無ければしばらく待ちが賢明かなあという印象です。
APNs ペイロードの変更
iOS 10からこのように、title・subtitle・bodyが指定出来るようになります。
ペイロード例:
{
"aps": {
"alert": {
"title": “Introduction to Notifications",
"subtitle": “Session 707",
"body": "Woah! These new notifications look
amazing! Don’t you agree?"
},
"badge": 1
}
}
初め、iOS 10でalertの入れ子表示対応になったかと勘違いしてたのですが、こちらのTweetを見て違うと気づきました。
APNs Payloadの title, body はすでにiOS 8.2からあったようですね #WWDC16共有会 / “The Remote Notification Payload” https://t.co/551fSdygdd
— Kosuke 8/20はiosdc.jp (@koogawa) June 29, 2016
確かに、リモート通知文言の国際化をクライアントサイドで行う時に使うalertにtitle-loc-keyなどを入れ子にして設定することなどが以前から可能でしたしね。
(参考: The Remote Notification Payload)
リモート通知文言の国際化は、サーバーサイドで行うことが主流な気がしていて、僕もそうしていて普段使っていないので頭から抜けかけていました。
まとめるとこんな感じです:
- iOS 10から増えたのは
alertの子要素のsubtitleのみ - iOS 8.2からこっそり
alertの子要素のtitleが増えている- 上からバナーが出る時には出ずに、通知一覧などで表示される、など中途半端な対応だった
-
alertの子要素のbodyに設定したもの =alertに単純に文字列指定したもの
というわけで気を付けるべきはこの程度ですね:
- iOS 10向けにalertを細かく出したい時は、
bodyに一番知らせたいことを入れて、titleはiOS 8.2以降でも通知種類によっては見え、subtitleはiOS 9以前では表示されないことを念頭に- これに従いたく無い場合、手間増えるが、OSごとにペイロード内容を変えることでより最適な表示も可能(普通ここまで手間かけたくないと思いますが)
-
alertに単純に文字列指定だとiOS 10含めて全てのバージョンで現状維持になるだけ
iOS 10からというよりiOS 8.2から気を付けたり活用すべきことだったのかなと思いますが、今回目立つ形で発表があって、またiOS 8.2からのtitleのような中途半端な扱いでは無くなったので、実際にはiOS 10からalertの細かい表示が活用され出すのかなと思いました。
というわけで、初めはこのあたり処理分けなど手間になるかも？と思ったのですが、上に書いたちょっとしたことを頭に入れておく程度で大丈夫そうです( ´･‿･｀)
この記事はスライドで話しきれなかったということで、懸念点など中心の内容になってしまいましたが、UserNotificationsフレームワーク自体は自由度など一段と上がってとても良く出来ていると感じています。
iOS 10が正式リリースされてシェアも増えた頃には、UserNotificationsフレームワークを活用した使いやすいアプリがたくさん登場してほしいところです( ´･‿･｀)
関連リンク
- スライド: What's New in User Notifications Framework - WWDC16. Meetup @Wantedly…
- サンプルコード: mono0926/wwdc2016-sample
(NDA的にセーフと解釈している範囲で書いているつもりですがアウトの指摘などあれば調整します)
Author And Source
この問題について(iOS 10などで使えるようになるUserNotificationsフレームワークへの所感), 我々は、より多くの情報をここで見つけました https://qiita.com/mono0926/items/1fdf9ce8d1de0e30012b著者帰属：元の著者の情報は、元のURLに含まれています。著作権は原作者に属する。
Content is automatically searched and collected through network algorithms . If there is a violation . Please contact us . We will adjust (correct author information ,or delete content ) as soon as possible .