苹果推送通知 - 让从生产应用空推令牌 - 将推后修复的provisioning profile问题令牌发送 [英] Apple push notifications - getting empty push token from production app - will push tokens be sent after fix provisioning profile issue

问题描述

我们增加接收推送通知到一个iPhone应用程序。一切都在测试/沙盒环境中工作，我们从应用程序获得令牌的ID，可以从我们的服务器发送推送通知。

We added receiving push notifications to an iPhone app. Everything was working in the test/sandbox environment, we were getting token id's from the app and could send push notifications from our server.

但是，现在的应用程序获得批准，并走出了苹果商店中我们得到空的推令牌/通知的ID发送到我们​​的服务器。我们已经有超过他们的600 ...请注意，最终用户便得到批准的应用程序接收通知的弹出，应用程序只是发送空令牌批准后，我们​​的服务器。所以大概空令牌是由APNS服务器分发。

But now the app is approved and came out of the Appstore we were getting empty push tokens/notifications id's send to our server. We already have over 600 of them... Note that end users do get the popup to approve of receiving notifications in the app, the app is just sending empty tokens to our server after approval. So probably empty tokens are handed out by the APNS server.

下面的问题向我们表明这可能是由于缺少我们用来做构建的应用程序商店的供应配置文件推送通知的权利：
<一href=\"http://stackoverflow.com/questions/8747539/how-do-i-check-if-an-ios-distribution-provisioning-profile-has-push-notification\">How我做检查，如果在iOS发行配置文件已推送通知启用？

The following issue showed us that this is probably due to missing 'push notification' entitlement in the provisioning profile we used to make the build for the app store: How do I check if an iOS distribution provisioning profile has push notifications enabled?

缺少的权利是由于苹果的provisiong门脉网站中的错误，但经过修改任何现有的配置文件下载新的人之前如下面的文章中提到的
<一href=\"http://developer.apple.com/library/mac/#documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/ProvisioningDevelopment/ProvisioningDevelopment.html\" rel=\"nofollow\">http://developer.apple.com/library/mac/#documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/ProvisioningDevelopment/ProvisioningDevelopment.html

The missing entitlement was due to a bug in Apple's provisiong protal website, but after 'Modify any existing profile before you download the new one' as mentioned in the following article http://developer.apple.com/library/mac/#documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/ProvisioningDevelopment/ProvisioningDevelopment.html

我们现在有正确的权利在我们的文件名为.mobileprovision：

We now have the correct entitlement in our .mobileprovision file:

<key>Entitlements</key>
<dict>
 ..   
 <key>aps-environment</key>
 <string>production</string>
 ..

因此​​，我们正在重建我们的应用程序并将其添加到店里来。并希望能得到推送通知即可。

So we are rebuilding our app and adding it to the store. And hoping to get push notifications then.

我希望以上可以帮助一些人。但现在要到我实际的问题：我们将开始接收新推的标记也已经下载了最新版本时，他们安装的下一个更新走出商店的600多用户？还是我们需要一些初始code加入到我们的应用程序？该registerForRemoteNotifications方法是正确的，现在只能叫上应用程序的启动。将它当推令牌ID是空的（''）更改为实际令牌也被触发？当然，我们不希望再等（小）本周新批准的AppStore，然后才发现，推送通知仍然没有工作了一些用户。我希望一些专家在那里可以告诉我们。

I hope the above might help some others. But now to get to my actual question: Will we start receiving new push tokens also for the 600+ users that already downloaded the current version when they install the next update out of the store? Or do we need to add some initial code to our app? The registerForRemoteNotifications method is right now only called on application startup. Will it also be triggered when the push token id is changed from empty ('') to an actual token? Of course we do not want to wait another (small) week for the new AppStore approval and only then find out that push notification still aren't working for some users. I'm hoping some expert out there can tell us.

请注意：我们正在使用的MonoTouch开发的iPhone应用程序，并使用（旧）APNS夏普库从我们的服务器发送通知，但我不认为这些细节是相关的这个问题。

Note: We are using an iPhone app developed in MonoTouch, and using the (old) APNS-Sharp library to send the notifications from our server, but I don't think those details are relevant for this issue.

推荐答案

在那些600+用户安装的下一个更新，并再次运行应用程序，应用程序将调用 registerForRemoteNotifications （因为你说你怎么称呼它在启动时），并且将获得非空的设备令牌（当应用程序：didRegisterForRemoteNotificationsWithDeviceToken：被调用）。
在他们的苹果文档的状态，你应该始终调用在启动，而不是使用设备令牌的缓存副本这个方法，因为该设备令牌不能保证保持不变。所以，你不应该有任何问题。

When those 600+ users install the next update and run the application again, your application will call registerForRemoteNotifications (since you said you call it on startup), and will get the non empty device token (when application:didRegisterForRemoteNotificationsWithDeviceToken: is called). Apple state in their docs that you should always call this method at startup instead of using a cached copy of the device token, because the device token is not guaranteed to remain the same. So you shouldn't have any problem.

下面是从APNS文档相关报价：

Here's the relevant quote from the APNS docs :

应用程序应该注册每次启动时，给其
  供应商目前的令牌。它要求
  该registerForRemoteNotificationTypes：方法来揭开序幕
  注册过程。这个方法的参数取
  UIRemoteNotificationType（或对于OS X，一个NSRemoteNotificationType）
  位掩码，指定初始通知类型的的
  应用程序希望接收例如，图标徽章和声音，
  但不是警报消息。在iOS中，用户可以随后修改
  启用通知类型的通知] preference
  设置应用程序。在iOS和OS X，你可以检索
  目前通过调用启用的通知类型
  enabledRemoteNotificationTypes方法。操作系统不
  徽章的图标，显示警报消息，或播放声音警报如果任何
  这些通知类型没有启用，即使他们指定
  在通知有效载荷

An application should register every time it launches and give its provider the current token. It calls the registerForRemoteNotificationTypes: method to kick off the registration process. The parameter of this method takes a UIRemoteNotificationType (or, for OS X, a NSRemoteNotificationType) bit mask that specifies the initial types of notifications that the application wishes to receive—for example, icon-badging and sounds, but not alert messages. In iOS, users can thereafter modify the enabled notification types in the Notifications preference of the Settings application. In both iOS and OS X, you can retrieve the currently enabled notification types by calling the enabledRemoteNotificationTypes method. The operating system does not badge icons, display alert messages, or play alert sounds if any of these notifications types are not enabled, even if they are specified in the notification payload.

这也是相关的：

通过请求设备令牌，并将其传递给每一个供应商
  计时您的应用程序启动，你帮助确保供应商
  有该设备的当前令牌。如果用户恢复一个备份到
  设备或计算机比备份为创建的一个其它
  （例如，用户将数据迁移到新的设备或计算机），他
  或她必须至少一次启动应用程序，它接收
  再次通知。如果用户备份数据还原到一个新的设备
  或计算机，或重新安装操作系统，设备令牌
  变化。而且，从来没有缓存的设备令牌，并把那个给你
  供应商;总是从系统中获得令牌，只要你需要它。
  如果你的应用程序已经previously注册，呼叫
  registerForRemoteNotificationTypes：结果在操作系统
  立即通过设备令牌委托，而不会产生
  额外的开销。

By requesting the device token and passing it to the provider every time your application launches, you help to ensure that the provider has the current token for the device. If a user restores a backup to a device or computer other than the one that the backup was created for (for example, the user migrates data to a new device or computer), he or she must launch the application at least once for it to receive notifications again. If the user restores backup data to a new device or computer, or reinstalls the operating system, the device token changes. Moreover, never cache a device token and give that to your provider; always get the token from the system whenever you need it. If your application has previously registered, calling registerForRemoteNotificationTypes: results in the operating system passing the device token to the delegate immediately without incurring additional overhead.

这篇关于苹果推送通知 - 让从生产应用空推令牌 - 将推后修复的provisioning profile问题令牌发送的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！