ラベル Xcode 5.1 の投稿を表示しています。 すべての投稿を表示
ラベル Xcode 5.1 の投稿を表示しています。 すべての投稿を表示

2014年8月12日火曜日

Apple Push Notification (APN) 使用時の delegate の挙動について、 iOS 7以降 / iOS 6以前の差をまとめた

iOS 7以降とiOS 6以前で、俗にいうリモートPush通知の受け取り方と受け取った際の挙動がまるで違っているので、最近リモートPush通知を実装した時につまづいた箇所をまとめてみました。

使用する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がないと実行できないのではないかと思われます。

2014年3月12日水曜日

iOS SDK 7.1 / Xcode 5.1にアップグレードした時に踏んだ地雷まとめ

本日iOS SDK 7.1 / Xcode 5.1にアップグレードを行った際にぶつかった所々の問題とTipsをまとめておきたいと思います。

arm64対応とCocoaPods

Xcode 5.1からデフォルトのビルド設定$(ARCHS_STANDARD_32_BIT)がarm64、要するに64bit対応を含むようになり、arm64 armv7 armv7sの3つのアーキテクチャに対してビルドを行うようになりました。ソースコードからビルドを行っている場合は大抵問題ないと思うのですが、以下の様なケースでarm64対応を切りたい場合があります。

  • プロジェクト内にarm64アーキテクチャに対応していないstaticライブラリが含まれている場合。
  • 64bitになると危険なバグが発生するおそれがあるコードが含まれている場合、例えばCGFloatやNSIntegerのサイズが変化したり、各種ポインタのサイズが4byteから8byteに増えていたりすると面倒な事が起きるような計算をしている場合。

このような場合、一番簡単な対応策はBuild SettingsのArchitectures(ARCH)をarmv7 armv7sに書き換えることなのですが、こうすると実はCocoaPodsを使用しているプロジェクトの場合リンカエラーが発生してビルドができなくなるという問題があります。
https://github.com/CocoaPods/CocoaPods/issues/1787

そこでBuild SettingsのArchitectures(ARCH)を$(ARCHS_STANDARD_32_BIT)という値に設定すると内部的にarmv7 armv7sとして扱ってくれ、かつCocoaPodsが問題を起こさないようです。この方法をオススメします。この件については以下のページが詳しかったです。
http://stackoverflow.com/questions/8323343/archs-standard-32-bit-vs-armv6-armv7-armv7s-vs-i386

JSONKit対応とCocoaPods

Xcode 5.1からisaポインタへの直接アクセスが完全に禁止になりました。これまでは警告を出さないようにする事が可能でしたが、Xcode 5.1からはそのオプションもなくなり問答無用でビルドエラーにされてしまいます。この問題が最も深刻に出るのはJSONKitライブラリです。
https://github.com/johnezang/JSONKit/issues/79#issuecomment-6322919

対策として一番簡単で確実な方法はJSONKitを使うのを今すぐやめてNSJSONSerializationに乗り換えることです。NSJSONSerializationはiOS 5から使用できるので、あなたが余程のパフォーマンス厨か、またはあなたのプロジェクトが数千万人以上のユーザを抱える巨大プロジェクトで、万一iOS 4系のサポートを止めると何故かあなたの会社ではなく携帯電話会社に「使えないんでなんとかしてください」と苦情が寄せられるような社会的インフラとなったアプリでもなければこの方法を取ることを強くオススメします。

それでも何らかの理由か大人の事情で万一JSONKitをサポートしなければならない場合は、もはやソースコードを書き換えるしか手がありません。幸いにしてXcodeがエラー箇所の修正提案を自動的に全て行ってくれるため、それに従ってコードをホイホイ書き換えれば簡単にビルドが通って使えるようになります。また、すでにそのようなパッチやプルリクエストが山ほどgithub上に用意されています。例えば以下の様なプロジェクトをオススメします。
https://github.com/ignazioc/JSONKit-NoWarning (JSONKit 1.5.2pre, 要するに最新版相当)
http://cocoapods.org/?q=jsonkit-nowarning (CocoaPodsでも使用可能です)

まとめ

CocoaPods爆発しろ