Hi, I noticed that the ctor, currently, takes the entire URL of the "registration" endpoint: https://github.com/secondsun/PushEEDemo/blob/master/src/com/example/pushe... That's ok, for now. but I think that ideally the application specific part (here "/rest/registry/device") should not be exposed. It could be changed, by PushEE. In the iOS SDK, we only "require" the URL + the name of the servlet context. For instance: https://github.com/aerogear/aerogear-push-ios-registration/blob/master/pu... (from a "mocked" test) So the SDK internally appends the "rest/registry/device": https://github.com/aerogear/aerogear-push-ios-registration/blob/master/pu... Would you think this is good for the Android-SDK as well ? Greetings. Matthias -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf

On 07/01/2013 03:30 AM, Matthias Wessendorf wrote: any comments ? Yeah it is probably a good idea. :) PushConfig could have endpoints added to it and default to /rest/resgistry/device. On Tue, Jun 25, 2013 at 6:37 PM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: > > Hi, > > I noticed that the ctor, currently, takes the entire URL of the > "registration" endpoint: > > https://github.com/secondsun/PushEEDemo/blob/master/src/com/example/pushe... > > That's ok, for now. but I think that ideally the application specific part > (here "/rest/registry/device") should not be exposed. It could be changed, > by PushEE. > > In the iOS SDK, we only "require" the URL + the name of the servlet > context. > > For instance: > > https://github.com/aerogear/aerogear-push-ios-registration/blob/master/pu... > (from a "mocked" test) > > So the SDK internally appends the "rest/registry/device": > > https://github.com/aerogear/aerogear-push-ios-registration/blob/master/pu... > > Would you think this is good for the Android-SDK as well ? > > > Greetings. > Matthias > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

+1 Daniel Passos wrote: > wdyt about create a jira for this? -- abstractj _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev