IBM Worklight - How to detect that the application has been uninstalled and stop sending notifications?

1
votes

Within the application the user can subscribe to notifications or unsubscribe. This events are handled by a Worklight adapter that register or delete in the database the users subscriptions.

But in case the app is uninstalled without unsubscribing, in the database will remain the user subscription.

How can this be handled?
Is there any way to notify Worklight of the application uninstall?

As explained in the Idan answer, the subscription will be removed by Worklight automatically after a not specific amount of time depending on the notification provider.

http://developer.android.com/google/gcm/adv.html#unreg

https://developer.apple.com/library/mac/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/Chapters/CommunicatingWIthAPS.html Look for "General Provider Requirements" and "The Feedback Service"

For Apple how proceeds Worklight? Does it check each day the feedback service and then removes the corresponding notifications?

I have tested with Android and a trace appears in the WL Server console saying that the subscription has been removed "because the notification was rejected by the server (NotRegistered)".

This was after two hours since I uninstalled the application and I sent 23 notifications with the application uninstalled.

Is it possible to add a custom handler for this "event"?

Reading the documentation, in the WL.Server.createEventSource method, the "onDeviceUnsubscribe" property of the "options" parameters says:

"The name of the JavaScript function that is called when the device subscription is removed by a client request or by the cleanup task"

What is a cleanup task? My first thought was that this callback would be invoked in the use case we are discussing but I have tried it and when the notification is automatically removed this callback is not called.

Currently I'm sending SMS to my customers, when the customer installs the application I will send notifications instead of SMS but in case the customer uninstalls the application I need to know it for starting to send SMS again.

1
ibm-mobilefirst

1 Answers

0
votes

The Worklight Server cannot be notified (by you) that the application has been uninstalled - this is a user action that you do not have any control over.

That said, you do not need to worry about this, because this exact scenario is being handled for you.
This is the flow:

In case a push-enabled application has been uninstalled, and you are sending a notification... this notification arrives to the APNS/GCM/MPNS server, which then send the notification to the device, to be displayed in the app.

Because the app is no longer installed, the device OS will provide feedback to the APNS/GCM/MPNS server that the notification failed to display.

Eventually, what that will happen is that the APNS/GCM/MPNS server will notify the Worklight Server that the token is no longer valid and the subscription will be removed from the database.

Worklight cannot control when will the APNS/GCM/MPNS server notify the above, though. For more information, consult with the respective service documentation.

The additions to your edited question are not totally clear, but here goes:

  • APNS token invalidation - only Apple can tell you about it. It could take minutes, hours, days, weeks... there are all sort of scenarios, so no specific time frame can be guaranteed.

  • The cleanup task is likely a task done by Worklight Server to remove stale subscriptions. It runs every 1 hour and connects to APNS feedback service to retrieve a list of inactive devices. On receiving the list of devices, it removes the device subscriptions from the database.

  • onDeviceUnsubscribe - Once the device is unsubscribed onDeviceUnsubscribe will be triggered. The idea of this callback is to allow the developer to notify the enterprise backend system that the device is no longer able to receive push notifications so that the backend will no longer try to send them. This is where you could tell your backend system to send SMS instead. But, did you actually implement it (the callback)?