Appleの公式ドキュメントの内容が物足りないので
JavaPNSのドキュメントを読んでみる。
英語弱者なので翻訳は鵜呑みにしないでください。
読むドキュメントはこれ。
https://code.google.com/p/javapns/wiki/FeedbackService
原文
The feedback method's first parameter is a reference to your keystore; it can be either a java.io.File, a java.lang.String (path to your keystore file), a java.io.InputStream or a byte[] array. The second parameter is your keystore's password. The third parameter selects the production (true) or sandbox (false) service.
訳
フィードバックメソッドの最初のパラメータはキーストアです。
java.io.Fileオブジェクトか、ファイルへのパス、java.io.InputStreamオブジェクト、バイト配列のいずれかの形式で指定可能です。
2個目のパラメータはキーストアのパスワードです。
3個目のパラメータはBool値で本番（True）かテスト（False）かを指定出来ます。
原文
The Feedback Service is one of two error reporting systems involved in push notification. The other one is error-response packets. You must not rely exclusively on the Feedback Service to remove invalid devices; you must also use error responses while pushing notifications (see Managing errors) to detect different notification errors.
訳
フィードバックサービスはAPNSの二つ有るエラー通知機能の一つです。
もう一つはAPNSプッシュ時のエラーレスポンスパケットです。
無効デバイスの削除をする際は、フィードバックサービスだけを頼ってはいけません。
APNSプッシュ時のエラーレスポンスも併用して異なる通知を探してください。
（管理用エラーも参考にね）
原文
Important notes
訳
以下、重要でっせ
原文
１．Feedback Service vs Error-response packets: Both systems are designed to report problems with a particular token or notification. The error-response packets provide immediate error reports when pushing notifications, while the feedback service provides on-demand error reports. Although Apple's documentation is quite vague about the complementarity or redundancy of the two systems, hands-on experience suggests that they are designed to detect and report different errors, and that you must handle errors from both sources.
訳
フィードバックサービス VS エラーレスポンスパケット
いずれの機能も、特定のプッシュトークンや通知内容のエラーを検出するために設計されてます。
エラーレスポンスパケットはAPNSプッシュ時に随時エラーが検出されます。
フィードバックサービスは要求に応じてエラーを検出します。
アップルのドキュメントではこの二つの機能の相補性や冗長性については結構曖昧に記述されてます。
実際に動かしてみると、それぞれの機能は異なったエラーを検出するように設計されているようです。
つまり、両方の機能を使ってエラーを検出するといい感じです。
原文
The error-response packets are returned for obvious and immediately identifiable issues such as for invalid tokens, while the feedback service lists devices which are eventually considered inactive because of repeated failed notification attempts over some period of time. Consequently, you must deal with problematic device tokens in two separate occasions: when an error-response packet is returned for a given token, and when you query the feedback service for inactive devices.
訳
エラーレスポンスパケットは無効なトークンを識別可能な情報を、明確な形式で即座に返してくれます。
それに対して、フィードバックサービスは、ある一定の期間プッシュ通知を試みたものの、
失敗を繰り返し、非アクティブと判断されたデバイスリストを返します。
つーわけで、エラーレスポンスパケットを受け取った時と、
フィードバックサービスから非アクティブなデバイスを照会する時の
それぞれの機会で問題のあるトークンに対処しなければなりません。
原文
You should not assume that the feedback service will list a device if that device's token has previously been targeted by an error-response packet. If an error-response packet indicates that a device token is invalid, you should delete it immediately from your notification lists, and you most definitely should not wait for that token to be listed by the feedback service because it will most likely never be listed since you received an error-response packet for it.
訳
エラーレスポンスパケットにてエラーが検出されたデバイスが有ったとしても、
フィードバックサービスのデバイスリストに必ずしも含まれるとは限らないことを
念頭に置いておいてください。
あるデバイスにおいて、エラーレスポンスパケットを受け取ったら、即座にプッシュ対象から除外して大丈夫です。
つまり、そのデバイスがフィードバックサービスのリストに含まれることを待たなくても良いということです。
原文
２．Delays involving the Feedback service: Since Apple does not specify precisely when a device will end up on the Feedback list (ie how many failed push must occur or how much time must elapse before it is marked as inactive), it is not possible to predict reliably when a device will get listed by Apple's Feedback Service. The whole purpose of having an asynchronous Feedback Service to detect inactive devices is because Apple has a lot of factors to consider before listing a device as inactive... If a notification can't be pushed, it can be because of network issues, device issues, bad reception issues, configuration issues, etc. but if any of these problems arise, it does not necessarily mean that the device is permanently inactive... it may simply be a temporary situation.
訳
フィードバックサービスの遅延について。
デバイスがフィードバックリストに載る契機をAppleが正確に明記していないので
フィードバックリストに載ることを予測することができません。
フィードバックサービスの全体的な目的は、非アクティブなデバイスを検出することです。
プッシュ通知に失敗する要因は色々あります。
デバイスの問題だったり、ネットワークの問題だったり、設定の問題だったり色々。
でもそれは、必ずしもデバイスが永久的に非アクティブである根拠ではないです。
一時的な理由だったりもします。そういう考慮をしてるから非同期ってこと。
原文
３．Sandbox Feedback Service not listing device after app is removed: iOS needs to inform the feedback service when a notification-enabled application is uninstalled, so that the device can be listed instantly by that service. HOWEVER, from various bits and pieces of information around the web, we learn that apparently there needs to remain at least one other notification-enabled application on the device so that iOS can inform the Feedback Service of the uninstallation. If the application you uninstall was the last notification-enabled app, iOS apparently cannot tell the Feedback Service about the uninstallation, and your device doesn't get listed right away (although it most likely will after some number of failed pushes and some time has elapsed). This information suggests that not only do you need to have at least one other notification-enabled app on your device so that your own app uninstallation will be broadcasted, but that other app needs to be configured to talk to the SAME Feedback service (sandbox or production).
訳
sandbox版の場合、アプリをアンインストールした時にフィードバックサービスはリストに含めません。
iOSはプッシュ通知に対応したアプリがアンインストールされたときに、
フィードバックサービスに通知する必要がある。
その通知を受けるとフィードバックサービスは対象のデバイスをリストに含めることができる。
ただし、これはインターネッツの断片的な情報を元に解かったことだが、
フィードバックサービスに通知を行うには、最低でも一つのプッシュ通知に対応した他のアプリが、残っていなければならない。
つまり、一つしか無いプッシュ通知アプリをアンインストールした場合、
フィードバックサービスには通知されない。
二つ以上プッシュ通知アプリが有ったとしても、同じ環境じゃないと通知はされない。
同じ環境っていうのは、本番かsandboxかってこと。
なるほど。
なるほどなるほど。