New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

OnDeviceSubscriptionExpired called when the device go off for a few hours #132

Closed
ozba opened this Issue Mar 27, 2013 · 12 comments

Comments

Projects
None yet
3 participants
@ozba

ozba commented Mar 27, 2013

As I understand OnDeviceSubscriptionExpired is called when apple tells the app to not send anymore push notifications because the device is not subscribed to the app anymore - i.e. deleted it.

But I get this event when the device go offline for a few hours (e.g. battery is dead), but the device is still subscribed to the app - the app is not removed.

Why is that? and can I tell if the device still has my app or by apple because the device went off for a few hours I should not send it anymore notifications from now on? it's absurd.

@Redth

This comment has been minimized.

Show comment
Hide comment
@Redth

Redth Mar 27, 2013

Owner

Are you talking about APNS specifically?

If so, not sure why Apple does this, but apparently they do, so best just follow along with their requests!

Owner

Redth commented Mar 27, 2013

Are you talking about APNS specifically?

If so, not sure why Apple does this, but apparently they do, so best just follow along with their requests!

@ozba

This comment has been minimized.

Show comment
Hide comment
@ozba

ozba Mar 27, 2013

yes, APNS.
but:

  1. Does anyone encountered that issue too?
  2. Is there a way to tell if the app was really removed or the device just went off?

ozba commented Mar 27, 2013

yes, APNS.
but:

  1. Does anyone encountered that issue too?
  2. Is there a way to tell if the app was really removed or the device just went off?
@normanhh3

This comment has been minimized.

Show comment
Hide comment
@normanhh3

normanhh3 Mar 28, 2013

If you are attempting to send a "high number" of notifications, and the
device is offline, it is likely that APNS has a policy that will kick in to
tell you that the device is unavailable. The documentation from Apple
pretty clearly states that whenever the app opens up it should call back to
the host server and update the backend with the push token. That would
take care of the issue of resuming the push notifications and is what I do
in the app I maintain.

On Wed, Mar 27, 2013 at 4:04 AM, ozba notifications@github.com wrote:

As I understand Events_OnDeviceSubscriptionExpired is called when apple
tells the app to not send anymore push notifications because the device is
not subscribed to the app anymore - i.e. deleted it.

But I get this event when the device go offline for a few hours (e.g.
battery is dead), but the device is still subscribed to the app - the app
is not removed.

Why is that? and can I tell if the device still has my app or by apple
because the device went off for a few hours I should not send it anymore
notifications from now on? it's absurd.


Reply to this email directly or view it on GitHubhttps://github.com//issues/132
.

normanhh3 commented Mar 28, 2013

If you are attempting to send a "high number" of notifications, and the
device is offline, it is likely that APNS has a policy that will kick in to
tell you that the device is unavailable. The documentation from Apple
pretty clearly states that whenever the app opens up it should call back to
the host server and update the backend with the push token. That would
take care of the issue of resuming the push notifications and is what I do
in the app I maintain.

On Wed, Mar 27, 2013 at 4:04 AM, ozba notifications@github.com wrote:

As I understand Events_OnDeviceSubscriptionExpired is called when apple
tells the app to not send anymore push notifications because the device is
not subscribed to the app anymore - i.e. deleted it.

But I get this event when the device go offline for a few hours (e.g.
battery is dead), but the device is still subscribed to the app - the app
is not removed.

Why is that? and can I tell if the device still has my app or by apple
because the device went off for a few hours I should not send it anymore
notifications from now on? it's absurd.


Reply to this email directly or view it on GitHubhttps://github.com//issues/132
.

@ozba

This comment has been minimized.

Show comment
Hide comment
@ozba

ozba Mar 28, 2013

I do that in my app too, but think about this scenario:
You use whatsup, than your device is offline for a few hours, people send you messages, than apple sends to whatsup - the device is unavailable, so whatsup don't send anymore notifications to you - EVER!
So your device is now back online, and you go by your daily life, and people now sending you messages, but because you don't know they do (no notifications ever remember?) you will get angry for whatsup - why I don't get my friends messages now that is online???
Is that scenario seems feasible? logic? That will get people angry at the app when it's apple fault

ozba commented Mar 28, 2013

I do that in my app too, but think about this scenario:
You use whatsup, than your device is offline for a few hours, people send you messages, than apple sends to whatsup - the device is unavailable, so whatsup don't send anymore notifications to you - EVER!
So your device is now back online, and you go by your daily life, and people now sending you messages, but because you don't know they do (no notifications ever remember?) you will get angry for whatsup - why I don't get my friends messages now that is online???
Is that scenario seems feasible? logic? That will get people angry at the app when it's apple fault

@Redth

This comment has been minimized.

Show comment
Hide comment
@Redth

Redth Mar 28, 2013

Owner

@ozba the app will get a new token (or possibly the same as before) the next time it registers for notifications, at which point you should tell your server just like you did the first time it registered for notifications just as @normanhh3 is suggesting.

Bottom line is that we have no control over what the feedback service sends us. We have no way to know if an app was uninstalled or the phone is just idle. So, this isn't really a problem of PushSharp but a problem of APNS. Unfortunately there's nothing I can do in PushSharp to help this scenario for you :(

Owner

Redth commented Mar 28, 2013

@ozba the app will get a new token (or possibly the same as before) the next time it registers for notifications, at which point you should tell your server just like you did the first time it registered for notifications just as @normanhh3 is suggesting.

Bottom line is that we have no control over what the feedback service sends us. We have no way to know if an app was uninstalled or the phone is just idle. So, this isn't really a problem of PushSharp but a problem of APNS. Unfortunately there's nothing I can do in PushSharp to help this scenario for you :(

@Redth

This comment has been minimized.

Show comment
Hide comment
@Redth

Redth Mar 28, 2013

Owner

@ozba I should mention, I don't believe that typically an 'offline' device causes apple to send feedback to it unless perhaps like @normanhh3 suggested that you're sending LOTS of notifications to it (maybe - it's hard to know what Apple is doing since they don't make it clear).

In my experience, I've had apps be 'offline' for hours or days even, and when I start them back up, they still are registered to the same token.

I'm not sure what's happening that's different in your experience, but one idea perhaps is, are you testing on the sandbox? I think things run a bit differently there than on production APNS.

Owner

Redth commented Mar 28, 2013

@ozba I should mention, I don't believe that typically an 'offline' device causes apple to send feedback to it unless perhaps like @normanhh3 suggested that you're sending LOTS of notifications to it (maybe - it's hard to know what Apple is doing since they don't make it clear).

In my experience, I've had apps be 'offline' for hours or days even, and when I start them back up, they still are registered to the same token.

I'm not sure what's happening that's different in your experience, but one idea perhaps is, are you testing on the sandbox? I think things run a bit differently there than on production APNS.

@ozba

This comment has been minimized.

Show comment
Hide comment
@ozba

ozba Mar 28, 2013

  1. I'm not testing in the sandbox, it's live.
  2. I'm not sending a lot, maybe couple of notifications for this to happen.
  3. After the user reenter the app I get the same token as before.
  4. The interesting part is that I get the apple feedback via OnDeviceSubscriptionExpired the moment the device is back online, not before.
  5. Can someone test it to see of it happens in his live app too?

ozba commented Mar 28, 2013

  1. I'm not testing in the sandbox, it's live.
  2. I'm not sending a lot, maybe couple of notifications for this to happen.
  3. After the user reenter the app I get the same token as before.
  4. The interesting part is that I get the apple feedback via OnDeviceSubscriptionExpired the moment the device is back online, not before.
  5. Can someone test it to see of it happens in his live app too?
@Redth

This comment has been minimized.

Show comment
Hide comment
@Redth

Redth Mar 28, 2013

Owner

Are you checking the date from the OnDeviceSubscriptionExpired event? You say that it's firing after the device comes back online. What you might want to try doing is taking note of when the device comes back online and send the token (even if it's the same) to the server. Keep track of the time on the server that the token was updated (even if it's the same token), and then when you receive feedback, look to see when that feedback was received compared to the last time the token was updated. If the feedback was received BEFORE the last time the token was updated, you can safely ignore the feedback.

Owner

Redth commented Mar 28, 2013

Are you checking the date from the OnDeviceSubscriptionExpired event? You say that it's firing after the device comes back online. What you might want to try doing is taking note of when the device comes back online and send the token (even if it's the same) to the server. Keep track of the time on the server that the token was updated (even if it's the same token), and then when you receive feedback, look to see when that feedback was received compared to the last time the token was updated. If the feedback was received BEFORE the last time the token was updated, you can safely ignore the feedback.

@ozba

This comment has been minimized.

Show comment
Hide comment
@ozba

ozba Mar 28, 2013

When I say online I mean return interent connection, not coming back to my app.
The scenario I experience is that:

  1. Device turn off.
  2. device gets notifications.
  3. Device turned on.
  4. apple sends feedback - don't send anymore notifications.

ozba commented Mar 28, 2013

When I say online I mean return interent connection, not coming back to my app.
The scenario I experience is that:

  1. Device turn off.
  2. device gets notifications.
  3. Device turned on.
  4. apple sends feedback - don't send anymore notifications.
@Redth

This comment has been minimized.

Show comment
Hide comment
@Redth

Redth Mar 28, 2013

Owner

Not sure what to tell you. Apple be crazy.

I've not experienced this myself ever.

Is the device jailbroken? That can cause weirdness in my experience. Are notifications for that specific app turned off in settings?

It sounds like this really only should happen after an app is uninstalled, not just offline, so this does seem odd. Unfortunately I'm at a loss as to what you could do next, except maybe filing a bug with Apple. PushSharp is just a dumb receiver of the feedback service info, and so if they're sending feedback for specific tokens, all it knows is what token was sent, and when the feedback is for.

Here are the official docs:

http://developer.apple.com/library/mac/#documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/ApplePushService/ApplePushService.html

Sometimes APNs might attempt to deliver notifications for an application on a device, but the device may repeatedly refuse delivery because there is no target application. This often happens when the user has uninstalled the application. In these cases, APNs informs the provider through a feedback service that the provider connects with. The feedback service maintains a list of devices per application for which there were recent, repeated failed attempts to deliver notifications. The provider should obtain this list of devices and stop sending notifications to them. For more on this service, see “The Feedback Service.”

and

http://developer.apple.com/library/mac/#documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/CommunicatingWIthAPS/CommunicatingWIthAPS.html#//apple_ref/doc/uid/TP40008194-CH101-SW3

If a provider attempts to deliver a push notification to an application, but the application no longer exists on the device, the device reports that fact to Apple Push Notification Service. This situation often happens when the user has uninstalled the application. If a device reports failed-delivery attempts for an application, APNs needs some way to inform the provider so that it can refrain from sending notifications to that device. Doing this reduces unnecessary message overhead and improves overall system performance.

Owner

Redth commented Mar 28, 2013

Not sure what to tell you. Apple be crazy.

I've not experienced this myself ever.

Is the device jailbroken? That can cause weirdness in my experience. Are notifications for that specific app turned off in settings?

It sounds like this really only should happen after an app is uninstalled, not just offline, so this does seem odd. Unfortunately I'm at a loss as to what you could do next, except maybe filing a bug with Apple. PushSharp is just a dumb receiver of the feedback service info, and so if they're sending feedback for specific tokens, all it knows is what token was sent, and when the feedback is for.

Here are the official docs:

http://developer.apple.com/library/mac/#documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/ApplePushService/ApplePushService.html

Sometimes APNs might attempt to deliver notifications for an application on a device, but the device may repeatedly refuse delivery because there is no target application. This often happens when the user has uninstalled the application. In these cases, APNs informs the provider through a feedback service that the provider connects with. The feedback service maintains a list of devices per application for which there were recent, repeated failed attempts to deliver notifications. The provider should obtain this list of devices and stop sending notifications to them. For more on this service, see “The Feedback Service.”

and

http://developer.apple.com/library/mac/#documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/CommunicatingWIthAPS/CommunicatingWIthAPS.html#//apple_ref/doc/uid/TP40008194-CH101-SW3

If a provider attempts to deliver a push notification to an application, but the application no longer exists on the device, the device reports that fact to Apple Push Notification Service. This situation often happens when the user has uninstalled the application. If a device reports failed-delivery attempts for an application, APNs needs some way to inform the provider so that it can refrain from sending notifications to that device. Doing this reduces unnecessary message overhead and improves overall system performance.

@ozba

This comment has been minimized.

Show comment
Hide comment
@ozba

ozba Mar 28, 2013

The devices I've checked are jailbroken... I might try this with an unjailbroken one and see if I get the same weird phenomenon.

ozba commented Mar 28, 2013

The devices I've checked are jailbroken... I might try this with an unjailbroken one and see if I get the same weird phenomenon.

@Redth

This comment has been minimized.

Show comment
Hide comment
@Redth

Redth Apr 8, 2013

Owner

Closing for now, reopen if there's more info to add!

Owner

Redth commented Apr 8, 2013

Closing for now, reopen if there's more info to add!

@Redth Redth closed this Apr 8, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment