On Mon, Jul 15, 2013 at 3:03 PM, TadeasKriz <tkriz@redhat.com> wrote:
I know that Apple is kinda strict about this but if they have it in system it's kinda different story than with Android, which doesn't have this and leave it all to developers.

yes - that's why the server does support the endpoint - on the client side, it's optional :) 

 
So at least for Android it's definitely needed feature. And well that was my point from at the first place, that aerogear-android should have this feature. And you're right that this is what's the JIRA ticket for, the device-side call to server for unregistration.

perfect :) 
 

On Jul 15, 2013, at 2:32 PM, Matthias Wessendorf <matzew@apache.org> wrote:




On Mon, Jul 15, 2013 at 1:59 PM, TadeasKriz <tkriz@redhat.com> wrote:
I've created the JIRA subtask:


You said some push networks recommend not to unregister from device. Well, I was more thinking about it like the device will send information to the unified push server and the server will then remove the device from the list of available tokens.


Well - Apple is pretty strict about "not following" best practices.

In iOS there is a notification centre. There the user will disable "notification" per app (and users know that). And that's exactly why Apple has a Feedback Service to query for "invalid" tokens.

Regardless if we all love things or not, I guess for the iOS SDK we will not see a "unregister" hook (for those above reasons). 

Kinda sucks if a developer's app got's rejected because AeroGear-iOS, and its developers :-)
 
Also the device would unregister from the push network if it should (I think it's valid way with GCM, don't know about others).

From the API side, I think it might be added as a method of Registrar. So there would be Registrar#register and Registrar#unregister. What do you think?

yes, I guess that's what the JIRA ticket is for, right ? 


The UnifiedPush Server does have this API endpoint already:

 


On Jul 15, 2013, at 12:57 PM, Matthias Wessendorf <matzew@apache.org> wrote:

it is opional, since some push networks recommend not performing "in app unregister" themselves. (eg APNs). There are (APNs)hooks to query for invalid tokens (aka feedback service).

For Android SDK, can u file JIRA sub task of AGDROID-35 ?

Thanks,
Matthias

PS: there is no real harm, if payload to push network contains "outdated" tokens.




On Monday, July 15, 2013, TadeasKriz wrote:
Hey,

I'm now trying the unified push with Android and I've noticed, that there is no way (or I didn't find it?) to unregister the device. Example real usage: in application settings there might be a checkbox to disable notifications, so the user probably won't like receiving push messages which would then be discarded by the device (it'd be a waste of his data package). It seems to me like it wasn't left out on purpose, but rather forgotten to be added. Any thoughts on this?

Thanks
_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev


--
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev



--
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev



--
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf