In the mean time, I've create a JIRA to track this: https://issues.jboss.org/browse/AGIOS-487

-Matthias

On Mon, Apr 18, 2016 at 12:51 PM, Matthias Wessendorf <matzew@apache.org> wrote:
There is one more thing:

Since the users might decide to unregister at any point of lifetime in the app, the app also has to know the token, in order to actually perform that HTTP_DELETE 


On Mon, Apr 18, 2016 at 9:53 AM, Matthias Wessendorf <matzew@apache.org> wrote:


On Mon, Apr 18, 2016 at 9:34 AM, Yves Nicolas <yves.nicolas@dynamease.com> wrote:
looks good, will try the aerogear push helper from mfischelmayer.
Was actually aware for the Android one, looking for the equivalent in Apple.
Definitely agree with you regarding the difference, it makes sense for the App to keep being registered at the APN level (user doesnt need to authorize the remote notifications again) but we want the user to be unregistered from the server, although this is not a high priority use case.

There are a few things we need to be aware of:
* when app issues such an unregister call, the UPS won't be sending push notifications
* each launch of the application will hit 'application:didRegisterForRemoteNotificationsWithDeviceToken', meaning the previously removed token will be readded. Local state on the app needs to be around, to deviced if the registration w/ UPS should be called or not.

-Matthias





Le 18/04/2016 09:27, Matthias Wessendorf a écrit :
Hi Yves,

On Mon, Apr 18, 2016 at 9:15 AM, Yves Nicolas <yves.nicolas@dynamease.com> wrote:
API deletion is ok. Use case for deletion by Alias : Java written
backoffice doesnt know about device tokens, we want to be able to
deregister users from the backoffice. API management, or from the java
library. our other use case for unregistration are from the devices
themselves, they know about the token. We can manage with the Rest api,

Or, you can use this nice library that a different AeroGear user created!


 
is there a plan to include the unregistration inside the android and IOS
library?

Android:
there is this method:

which does both:
* 'unregister' from the GCM service, as well as from the UPS.

Perhaps that's something you can leverage ? 


On iOS, we don't have this, because Apple does not recommend to have users manually unregister from push on the app. Their preferred way is disabling push on the global setting.

However, I think it's arguable that unregistering from UPS, for an app, is not equals to completely unregister from APNs, for the same app. Worth to explore this on a different thread  :-) 

 
Thxs Message: 3 Date: Fri, 15 Apr 2016 19:18:47 +0200 From:
Matthias Wessendorf <matzew@apache.org> Subject: Re: [Aerogear-users]
what is the good way to delete an alias entry in aerogear unified push
servers To: "aerogear-users@lists.jboss.org"
<aerogear-users@lists.jboss.org> Message-ID:
<CAAg5f2QR0MZ9nk1GjxMpHwNd6Zu_o7DrhAURO9yKJP+9O66R8w@mail.gmail.com>
Content-Type: text/plain; charset="utf-8" remove the entire installation
entry:
https://aerogear.org/docs/specs/aerogear-unifiedpush-rest/index.html#417932897
what's the use-case - perhaps we can improve our story? On Fri, Apr 15,
2016 at 6:09 PM, Yves Nicolas <yves.nicolas@dynamease.com> wrote:

> The user interface enable to uncheck the alias so that it doesn't
> receive notification anymore but what is the good way to delete the
> alias/device token from the aerogear database?
>
> Thanks
> Yves
>
> _______________________________________________
> Aerogear-users mailing list
> Aerogear-users@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-users
>
_______________________________________________
Aerogear-users mailing list
Aerogear-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-users



--


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


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




--



--
Matthias Wessendorf

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