You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Apr 24, 2021. It is now read-only.
Sometimes subscriptions get deleted. I find it a useful pattern to have my push library always call subscribe() every time it is initialized/included, provided the permission is granted.
Perhaps that should be a default and we should support an initialization paramater to disable it for advanced users that want full predictability to handle cases like that themselves?
The text was updated successfully, but these errors were encountered:
The permission that we are going off is Notification, which could have been granted for a non-push use case - maybe the user doesn't want to subscribe for push messages? I think we might need more of a signal of user intent.
I think the permission api let's you specify push.
Bit confused at when a push subscription gets deleted though. Is that by chrome? If so it sounds like a bug and not something we should be coding around when it may be the correct behaviour in other browsers.
I don't know exactly how it happens, but Nathan from FB told me it happens often.
Could be to do with SW getting updated or something? Or just a GCM quirk.
Mat - I agree with your point, what if we just recorded that the developer told us to subscribe and hadn't more recently told us to unsubscribe? So basically if they told us to be in the subscribed state we work to stay there?
I think we should punt this for now as a low priority feature to discuss once we've launched a basic version.
Sometimes subscriptions get deleted. I find it a useful pattern to have my push library always call subscribe() every time it is initialized/included, provided the permission is granted.
Perhaps that should be a default and we should support an initialization paramater to disable it for advanced users that want full predictability to handle cases like that themselves?
The text was updated successfully, but these errors were encountered: