[aerogear-dev] Differences between Firefox OS "native" Push lib and AeroGear's Push adapter
Tadeas Kriz
tkriz at redhat.com
Thu Jul 24 09:28:08 EDT 2014
—
Tadeas Kriz
On 24 Jul 2014, at 03:20 pm, Matthias Wessendorf <matzew at apache.org> wrote:
>
>
>
> On Thu, Jul 24, 2014 at 3:17 PM, Lucas Holmquist <lholmqui at redhat.com> wrote:
>
> On Jul 24, 2014, at 9:14 AM, Matthias Wessendorf <matzew at apache.org> wrote:
>
>>
>>
>>
>> On Thu, Jul 24, 2014 at 2:41 PM, Lucas Holmquist <lholmqui at redhat.com> wrote:
>>
>> On Jul 24, 2014, at 6:19 AM, Tadeas Kriz <tkriz at redhat.com> wrote:
>>
>>>
>>> —
>>> Tadeas Kriz
>>>
>>> On 23 Jul 2014, at 09:56 pm, Lucas Holmquist <lholmqui at redhat.com> wrote:
>>>
>>>>
>>>> so there is this issue, , about not being able to delete a simplePush installation.
>>>>
>>>> using the UPS js client, i registered the “deviceToken” with the push server, but when trying to use CURL or even the JS lib, i was getting a 404, and i noticed that it would never actually hit the server( i was in debug mode in IntelliJ )
>>>>
>>>> this was a demo that i had working back in april https://github.com/lholmquist/mobileweek/blob/master/mobileweek-ffos/js/app.js#L17
>>>>
>>>> i noticed that when i registered the deviceToken, i was doing a encodeURIComponent before sending it to the UPS.
>>>>
>>>> i modified the UPS JS client to do it this way, and then when i tried to do the remove, i actually hit the breakpoints i set. but the server could not find the installation doing
>>>>
>>>> Installation installation =
>>>> clientInstallationService.findInstallationForVariantByDeviceToken(variant.getVariantID(), token);
>>>>
>>>>
>>>> I changed the JS client to only do 1 encode instead of 2 but it still couldn’t find the installation.
>>>>
>>>> I’m not really familiar with JPA and all that, so i don’t know how the query stuff works in this case
>>>>
>>>>
>>>> But i do think we should be encoding the deviceToken( which is the pushEndpointURL ) when registering with the UPS, or else i don’t think we can ever get access to that endpoint
>>>>
>>>
>>> I’d rather not require this. I mean, if there is no other way, then yes, let’s encode, but I can’t see the reason why would that be a problem. Basically, when you put it into the JSON when registering, it’s just a string and string can have any possible character, no matter what. Then the request. When it’s encoded one time, so it can be put into the URL, it should be enough for the server to use it and to search an installation in the database.
>>
>> The problem is that you are not able to access the endpoint.
>>
>> /shortenedURLForBrevity/http://localhost:7777/simplepush/owejfoiwjfooijf994lkmsf239sflkwekjnkhwf
>>
>> basically, that is the endpoint you need to send a DELETE to. which isn’t possible
>>
>>
>> I guess on Android that's never a problem because the endpoint there looks like:
>> /shortenedURLForBrevity/+MY_GCM_TOKEN
>
> right, same for iOS, it’s just SimplePush that has the issue, since the token is a URL
>
> I also wonder if our Hibernate layer has issues w/ and URL as the token :) Hadn't had the time to check that yet
>
> -M
>
It should not. For hibernate, it’s just a string like any other. The problem might be in the configuration of JAX.RS/RestEasy. If I’ll have some time today evening, I’ll try to fix it, it should be an easy fix.
>
>>
>>
>> Passos, can you confirm ?
>>
>> -M
>>
>>
>>
>> We could also encode on the server side before storing, and the libs/CURL would need to encode for a DELETE?
>>
>>>
>>> Is is possible that there are some Hibernate’s restrictions for the “deviceToken” field?
>>>
>>>>
>>>> On Jul 14, 2014, at 9:52 AM, Lucas Holmquist <lholmqui at redhat.com> wrote:
>>>>
>>>>>
>>>>> On Jul 11, 2014, at 6:33 AM, Matthias Wessendorf <matzew at apache.org> wrote:
>>>>>
>>>>>> Hey Luke,
>>>>>>
>>>>>> I created this JIRA:
>>>>>> https://issues.jboss.org/browse/AGPUSH-802
>>>>>>
>>>>>> As I plan working on AGPUSH-532 next week, to make sure we have the 'right' model in place for 1.0.0. I think once the server bits are merged, we should address AGPUSH-802
>>>>>
>>>>> kk
>>>>>
>>>>>>
>>>>>> -Matthias
>>>>>>
>>>>>>
>>>>>> On Thu, Apr 10, 2014 at 5:22 PM, Lucas Holmquist <lholmqui at redhat.com> wrote:
>>>>>> so after testing this thing out with encodeURIComponent, the delete does work, however, we need to "double up" the encode.
>>>>>>
>>>>>> this works:
>>>>>>
>>>>>> https://gist.github.com/lholmquist/10393357
>>>>>>
>>>>>>
>>>>>> this doesn't:
>>>>>>
>>>>>> https://gist.github.com/lholmquist/10393450
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Apr 7, 2014, at 2:09 PM, Lucas Holmquist <lholmqui at redhat.com> wrote:
>>>>>>
>>>>>>>
>>>>>>> On Apr 7, 2014, at 12:52 PM, Matthias Wessendorf <matzew at apache.org> wrote:
>>>>>>>
>>>>>>>> Ok,
>>>>>>>>
>>>>>>>> So as token, we use the endpointURL, and on client we perform the encodeURIComponent() function ?
>>>>>>>
>>>>>>> i think so( as suggested 2 months ago :) ) i just need to see how this will affect how we store stuff in LS.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> -Matthias
>>>>>>>>
>>>>>>>> On Monday, April 7, 2014, Lucas Holmquist <lholmqui at redhat.com> wrote:
>>>>>>>> so i went back to look at what i had,
>>>>>>>>
>>>>>>>>
>>>>>>>> i don't think we need to get to complicated here,
>>>>>>>>
>>>>>>>> reading the spec stuff, and this example
>>>>>>>>
>>>>>>>> https://wiki.mozilla.org/WebAPI/SimplePush#Client_.28WebApp.29_code
>>>>>>>>
>>>>>>>> they show sending the pushEndpoint to the "App server", so i think we could just use and keep it simple
>>>>>>>>
>>>>>>>> it is also recommended that the channelID is never exposed to the application.
>>>>>>>>
>>>>>>>>
>>>>>>>> On Apr 1, 2014, at 3:34 PM, Lucas Holmquist <lholmqui at redhat.com> wrote:
>>>>>>>>
>>>>>>>>> i had something, now i forgot what it was, need to go back and check
>>>>>>>>> On Apr 1, 2014, at 3:05 PM, Matthias Wessendorf <matzew at apache.org> wrote:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Fri, Feb 14, 2014 at 2:06 PM, Lucas Holmquist <lholmqui at redhat.com> wrote:
>>>>>>>>>> still exploring
>>>>>>>>>>
>>>>>>>>>> :-) any recent thoughts on 'encodeURIComponent()' ?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Feb 13, 2014, at 3:39 PM, Sebastien Blanc <scm.blanc at gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Wed, Feb 12, 2014 at 2:30 PM, Lucas Holmquist <lholmqui at redhat.com> wrote:
>>>>>>>>>>> i might have a couple thoughts, but i need to try some things out first
>>>>>>>>>>>
>>>>>>>>>>> Any update on that or does the solution proposed by Matzew (using encodeURIComponent() ) could be enough ?
>>>>>>>>>>>
>>>>>>>>>>> On Feb 12, 2014, at 3:53 AM, Sebastien Blanc <scm.blanc at gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Tue, Feb 11, 2014 at 7:15 PM, Sebastien Blanc <scm.blanc at gmail.com> wrote:
>>>>>>>>>>>> Ok,
>>>>>>>>>>>> I've been doing some tests by using the PushEndpoint as device token. For registration it works but I just faced an issue by trying to unregister because the URL for the DELETE looks like :
>>>>>>>>>>>>
>>>>>>>>>>>> https://judconpush-sblanc.rhcloud.com/rest/registry/device/https://updates.push.services.mozilla.com/update/my_personnal_psuhendpoint_id [
>>>>>>>>>>>>
>>>>>>>>>>>> And the REST endpoint get a bit crazy by the extra "/" present in the endpoint URL. Therefore, I think we must just use the last URL fragment as deviceToken.
>>>>>>>>>>>>
>>>>>>>>>>>> Ok answering to myself ;) That won't work neither since if we do that UPS won't have the compllete push endpoint URL.
>>>>>>>>>>>> So how do we deal with that ?
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Thu, Feb 6, 2014 at 3:27 PM, Matthias Wessendorf <matzew at apache.org> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Thu, Feb 6, 2014 at 3:11 PM, Sebastien Blanc
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Sent from Gmail Mobile
>>>>>>>> _______________________________________________
>>>>>>>> aerogear-dev mailing list
>>>>>>>> aerogear-dev at lists.jboss.org
>>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> aerogear-dev mailing list
>>>>>>> aerogear-dev at lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> aerogear-dev mailing list
>>>>>> aerogear-dev at 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 at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>
>>>>> _______________________________________________
>>>>> aerogear-dev mailing list
>>>>> aerogear-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>
>>>> _______________________________________________
>>>> aerogear-dev mailing list
>>>> aerogear-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at 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 at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140724/69fdd348/attachment-0001.html
More information about the aerogear-dev
mailing list