[aerogear-dev] GCM 3.0 and Instance ID

[Sebastien Blanc]

if #3 is possible (check&ignore the ack backed into the library) I would go
for this option as well.

On Wed, Jun 17, 2015 at 4:28 PM, Matthias Wessendorf <matzew at apache.org>
wrote:

> Hi,
>
> On Wed, Jun 17, 2015 at 4:03 PM, Summers Pittman <supittma at redhat.com>
> wrote:
>
>> Sooooo we have a 2.2.0 staged.  Google has a ton of new functionality
>> rolling out for GCM.
>>
>> We think that 2.2.0 works with it mostly correctly but we are finding
>> some "gotchas".  Notably it looks like Google is sending some ACK messages
>> after we register that the library is ignoring.
>>
>> We will need to support InstanceID (tl;dr; Google is enhancing
>> registraiton_id).  Passos and I are still digesting the volumes of stuff
>> being rolled out from IO so we can't really give too many details right now
>> because we simply don't know them (And Google is still updating their docs,
>> fixing links, etc).
>>
>> So the question to the list is :
>>  Do we delay 2.2.0 and include support for InstanceID and any other best
>> practices Google has introduced or do we release 2.2.0, document / work
>> around any gotchas and then prioritize GCM 3.0 support for 2.3.0?
>>
>
> (assuming this is related to the NPE I am seeing in [1])
>
> I think the ultimate goal for 2.2.0 should be to to not crash like in [1].
>
> I see three options:
> 1) document the work-around ([2]) and release the _existing_ 2.2.0, as is
> -> The fact that the work-around needs to be added to (almost) all apps,
> makes it an odd work-around (not saying it's a no-go)
> 2) delay the 2.2.0 and get full GCM 3.0 support in there
> -> IMO it's unknown how long that takes, and ideally our 2.2.0
> AGDroid-Push should be out once we have the UPS released (early July); This
> also could mean a delay on our Cordova lib.
> 3) Update 2.2.0 to ignore the ACK sent from GCM 3.0, and get a 2.2.x (or
> 2.3.0) a bit later for full support on GCM 3.0
> -> IMO this allows us to release UPS 1.1.0 (and AGDroid-Push) in a
> reasonable timeframe and moves the work-around into our library, and not
> onto all the app developers.
>
>
> My vote would be going w/ option #3, given the above reasoning and the
> fact that we don't use any GCM 3.0 feature atm, it sounds fairly safe (at
> least to me) doing the working inside of our library
>
> -Matthias
>
> [1] https://issues.jboss.org/browse/AGDROID-425
> [2]
> https://github.com/jboss-mobile/unified-push-helloworld/commit/077bfdce8980f86fde1662b490139573792c82fc
>
>
>
>>
>>
>>
>> _______________________________________________
>> 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/20150617/f0a28328/attachment.html