According to MSDN, MPNS will put the notification requests in queue for delivery, so there is always time delay for them to get to device. My problem is that, sometimes, for example when the device goes to Temp Disconnected mode, the time delay is so long that the toast notifications become outdated when they arrive. Is there a way to discard/ignore these old toast notifications without renew the current push channel? If not, is it all right for me to renew push channel every time I open app?
As far as I know, it's OK to renew the channel every time you open the app. If your app is not running and you don't have a background task getting these notifications, you will automatically be discarding them anyway. Also, if my memory serves me correctly, should you use the channel request with an object that has been previously used to receive stuff from the channel, you can get the same channel (I might be wrong here). In this case, if you get old messages, you probably have to handle the local discarding manually.
Related
We created a wallet pass and sent the wallet pass invitation email to end-users. However, there was an issue with the back-end APIs which prevented the Apple pass from automatically calling the device registration API.
The question I have is, do we need to re-inform all user to reinstall the Pass, or will the Pass automatically try re-registering by calling the device API.
Thank you.
The way you have worded your question possibly describes an impossible situation. A valid pass will always attempt to register. You state that your API was the issue, but an issue with a web service implementation would not prevent devices attempting to call it.
If the pass.json contains a valid https webServiceURL an authenticationToken, it will call the device registration endpoint after it has been added to the user's wallet. If the device does not get a 201 or 200 response, it will continue to retry, progressively backing off from every few seconds, to every few days for a period of around 2 weeks.
Therefore, if your pass.json contained the correct information; assuming that the issue was with your device registration endpoint and assuming that you picked up and addressed the issue quickly, then you should see device registrations coming in without having to do anything.
If it took longer than a couple of weeks or if you want to accelerate the process, you could ask your users to toggle the Automatic Notifications setting on the back of the pass. This will force the device to attempt a re-registration.
If however, the pass does not contain a webServiceURL, or if the webServiceURL was incorrect, then the device will not call back, or will call the incorrect endpoint. In this case, the only option is to have your users reinstall the pass. In this case, it is not your API that is causing the problem, but your passes.
context: So I've implemented a push notification system which records an FCM subscription from a Google Chrome browser and stores it in a PostgreSQL JSON field... pretty standard.
I try to send these everyday at 1pm and I realised it looks like no one is receiving them. This is most likely because no-one opens their browsers at this time and according to this FAQ, the notifications only work when the browser is open.
i.e. It seems like my best bet is to send the notification every hour hoping the browser is open at some point.
I would also love if someone could point me to documentation somewhere that tells me if push notifications are saved for when a user opens the browser, or that they expire after a certain amount of time
Thanks!
You have to set the TTL for notifications when you send it. Standard web push services use a TTL header expressed in seconds. If TTL is zero, then the notification is dropped if the device is not connected. If TTL is different from zero, the notification will expire after the TTL have passed.
We have deployed the chrome service worker on our website in July 2015 and have over 380K active subscribers of which over 90% are mobile devices.
But we are encountering issues with the service worker. When a user's cache gets cleared or when many of the mobile apps like cleanmaster and other utility apps on a phone clear cache on a user's mobile. In that case we do not have any access to device token of that user. And hence even with 380K active users for which google sends us message ids we only get 50K impressions which is a very low ratio.
Our push notification subscription is implemented on a seperate subdomain as we could not make the entire site https then.
I have 2 queries:
We would love to know if Google is working on setting up a canonical system (Which is there in GCM for mobile apps) through which even if the user's cache gets cleared via these apps he might be able to get push notifications. Our users have complained again and again that even after subscription they are not receiving push that's when we went deeper and figured this out.
Also is there a way through which we can ensure we get back those users ?
When a user clears their cache in Chrome, it also unregisters service workers and clears the window cache as well. By unregistering the service workers it will unsubscribe the push subscriptions.
I agree that it's hard to understand the link between clearing a cache / cookies and how that relates to service worker and push notifications from the UI - the Chrome team are aware of this.
The best advice with respect to getting those users back is to ensure that when ever a user enables notifications and you get a subscription object, keep track of that decision as their last known decision and when the user re-visits your site, if they should be subscribed and you have permission, you can get a new subscription and send that back to your server.
Update
I put together this blog post: https://gauntface.com/blog/2016/05/01/push-debugging-analytics
Looking at your site there are a few issues in your code:
it seems that you have several broken promise chains and and overall it's hard to reason with what is going on in the push event, I'd strongly recommend tidying it up.
There is a minor but obvious bug when the service worker start ups and tries to examine the push subscription, which doesn't exist.
You are registering two service workers but only one of them gets used for push.
Checkout the blog post above, it covers how I came to that conclusion and some advice on how to fix it.
I am new to WP8 Aync tasks and have a query-
In WP8, on backbutton press, since it basically pops the last screen from the stack, then why are the Async tasks not cancelled when back key is pressed?
Also, if I am using the HttpWebRequest response, is using Abort() the only way of cancelling the async tasks?
The reason is because Back is a UI concept but things like networking are typically decoupled from the UI. As an example, imagine the user hit "Save" in an app and that started a web request to send their data to the cloud. Then they hit the Back button to go back to the previous page; it would be unexpected for the web request to be aborted and the data to potentially not be saved.
If you have a need to stop tasks when your UI changes (eg, because of resource consumption concerns) then you can try to do that, but I have a vague recollection that Abort is a no-op for Windows Phone 8 (but I could be wrong).
I would like to know what is the clean & correct way to notify my WP8 app that the ChannelUri has changed?
I read that i need to handle this in the ChannelUpdatedUri method. But i have a few queries here. Doesn't this require my app to be running all the time?
Second query is suppose i use ChannelUpdatedUri to listen for changes to the Uri. If there is a change will the app be notified as soon as it launches? Or will it be notified at a later time?
The trouble is if the app is not notified on launch then there is a possibility that it may re-register for a new channel uri before ChannelUpdatedUri is invoked. Isnt it?
Please help!
You'll only get notified of a change in the ChannelUri when you have the listener attached and the app running.
The best approach is to always check for the current Uri and pass it to the server when the app starts. You could leave the listener attached for the lifetime of your app and get a new one if it's lost while the app is running but in reality it's far more likely that the channel will be dropped/disconnected when the phone isn't in use.
There is, of course, the scenario where a channelUri may expire when the app isn't in use but the utility of the app is primarily around sending notifications. Obviously you need the user to restart the app to get a new connection but you can't tell them to restart the app.
This is a generic problem: how do you tell someone that you can't talk to them?
The reality of this situation is that if you really need to tell someone to launch the app again you'll need another way to do it.
Unfortunately, it's not possible to get an updated channelUri from a background agent, but you could query your backend to see if you need one and then raise a toast to the user to prompt them to reopen the app. Or you could just update the tile from the agent when this happens.
Alternatively you'll need to send them the prompt in another way (e.g. email or SMS?) but this is reliant on you capturing and securely storing these details.
There is no perfect solution to this scenario other than creating an app that the user opens regularly regardless of whether there are notifications or not and simply having the notifications as an extra feature.