プッシュ通知の確認ダイアログ自体は書いたとおり一度しか表示されない、というのは変わらないのです。が、特定の再通知条件を満たさない間に再インストールするとデバイストークンが取得できないというものです。特殊なパターンなので具体的な例で言えば、

1. enabledRemoteNotificationTypesをコールして現在のプッシュ通知が有効かどうかを調べる
2. 有効なtypeがない場合にregisterForRemoteNotificationTypesをコールして通知ダイアログを表示する
3. アプリケーションを再インストールする
4. enabledRemoteNotificationTypesの値は正常なのにデバイストークンの値が取れない

というパターン。確認する限りは、再インストールの場合は既に[設定]上にプッシュ通知が有効になっているものの再度enabledRemoteNotificationTypesをコールしないとdidRegisterForRemoteNotificationsWithDeviceTokenがコールされないようで、これがデバイストークンの値を取得できない要因となっていたようです。なので、解決策としては2.で既に有効になっていてもregisterForRemoteNotificationTypesをコールする、ってのが手っ取り早い模様。

何も考えずにそれをコールしていればこんなにハマることはなかったのでしょうが、何かを変えるということはそれだけリスクを伴う場合があるってことですね。いい勉強になりました。

プッシュ通知は重要ながらもチュートリアル的な実装をそのままコピペで実装してしまうと優れた機能も非常に残念なことになります。というのも、例えばよくあるパターンではゲームに対してプッシュ通知が実装されている場合、タイトル画面といった起動した瞬間に「○○はプッシュ通知を送信します。よろしいですか？」と出現するパターン(画像はあくまでサンプル画面ですが、実際に私が指摘する最悪なパターンを再現してくれたものです)。

少しはユーザのことを考えればわかることですが、これって開発側からのエゴの何物でもないですよね。だって、リアルな環境に置き換えるならば、試供品を受け取った段階で

とりあえずDM(ダイレクトメール)送りたいんだけど受け取りますか？

と言われているに近しいものだと思うのです。

因みに私はこのパターンは絶対にプッシュ通知を許可しません。だってウザったいかもしれない通知が来るかもしれないのにそれを許可する理由なんてないですから。

ってことで、長々とウンチクを垂れましたが、端的に言えばプッシュ通知をすべき場所を今一度見直して、細かく制御しましょうよ、と。プッシュ通知はUIAPplicationのインスタンスメソッドとして定義されていて以下の3つがあります。

• registerForRemoteNotificationTypes…プッシュ通知を有効にしようとします。ユーザにダイアログでプッシュ通知の確認が求められます
• unregisterForRemoteNotifications…登録されたプッシュ通知を破棄します
• enabledRemoteNotificationTypes…(どのような種類の)プッシュ通知が有効かどうかを取得します

なので、チュートリアル通りにapplication:didFinishLaunchingWithOptions:でregisterForRemoteNotificationTypesをコールするのではなくて、どのような目的でプッシュ通知を行いたいかを述べたうえで初めてregisterForRemoteNotificationTypesをコールしましょう、と。これをやっているのがGameloftの”レッツ！ゴルフ3”ですね。

・・・・、とここまでが前置き。そしてようやくタイトルの話になります。上述の通りにプッシュ通知のダイアログが出るタイミングというのは非常に貴重なもので、本当にこのタイミングでよいのかどうかを試験したい場合がありますが、一度この確認でどちらかを選択してしまうと開発中でも中々出てくれません。で、かるーくググってみると大好きなStackoverflowでこんな投稿がありました。

• Reset push notification settings for app (Stackoverflow)

相変わらずの精度が低いほげ脳内翻訳によれば

アプリケーションが初回にプッシュ通知を有効にしようとするならば、iOSはユーザにアプリケーションから通知を受け取るか否かを確認します。一度でもその警告(プッシュ通知の同意ダイアログ)に応答した場合は、デバイスをリストアするか、若しくはアンインストールを行ったうえで少なくとも1日以上経過する必要があるでしょう。

もしあなたが初回のプッシュ通知をシミュレートしたいとするならばアンインストールを行ったうえで1日経過させる必要があります。但し、システムクロックを1日以上経過させたうえで一度デバイスをシャットダウンし、再度デバイスを起動することで後者(=アンインストール後に1日以上経過するという条件)を満たすことができるでしょう。

と書いた本人ですが、実際に試していないのであしからず。

今回の記事をまとめるとこんな感じ

• プッシュ通知はアプリケーションが非アクティブ状態でもアプリ提供者側からユーザに情報通知が可能な数少ない手段です。
• ダイアログを表示することでプッシュ通知の同意を求める貴重なアプローチは1回のみです。もし本当にプッシュ通知を利用して欲しいのであればこのアプローチを行う前にユーザにプッシュ通知を行う利便性を説くべきでしょう。
• プッシュ通知は登録(登録要求)・解除・状態取得の3つのメソッドがあります。
• プッシュ通知の初回のアプローチはstackoverflowに書かれているような方法で再度確認を行うことができる(はず)です。アプリの提出前に本当にユーザが望ましい形でそのアプローチが行われているか確認しましょう。

あまり知られてはいないようなのですが、APNSを1回のSSLコネクションを通じて複数のユーザ・クライアントに飛ばすことが可能です。APNSで使用されるプロトコルは非常に有名なチュートリアルサイト

How to build an Apple Push Notification provider server (tutorial)で案内されている通りです。複数に送信する場合は、単純にこのメッセージ部を繰り返せばいいようです。プログラム的には以下の感じ。

$devices = (array)$devices;
foreach ($devices as $device) {
  $apnsMessage = chr(0) . 

    // token length
    pack('n', 32) . 

    // device token
    pack('H*', str_replace(' ', '', $deviceToken)) . 

    // payload length
    chr(0) . chr(strlen($payload)) . 

    // payload
    $payload;

  // send apns message
  fwrite($apns, $apnsMessage);
}


但し、注意ごととしては以下の通り。

(複数クライアント送信に限ったことではないですが)Payloadが256Byteを超えてはならない
1回の通信で全パケットが約7000Byteを超えるとサーバから切断される、らしい (←どこかで見た・・・)

なので、1メッセージが以下のような最長だとすると・・・・？

1byte – コマンド (token)
4byte – デバイストークン長
32byte – デバイストークン
1byte – コマンド (payload)
1byte – ペイロード長
256byte – ペイロード

295byteとなり、仮にサーバ切断となる7000byteまで達するには20人程なら余裕で許容できる範囲となるはずです。多分、10人程度なら超余裕ではないのかな、と。
APNSに関してはGameCenterやInApp-Purchaseの不具合とは異なってSandboxでも非常に安定をして動きます。なので、リリース(Distribution)前にしっかりと確認を行うことができるのでパフォーマンス調整を行ってみると良いかもしれません。
]]>
			http://lain.heavy.jp/lain/2011/11/14/312/feed
		0