<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jun 17, 2015 at 10:32 AM, Sebastien Blanc <span dir="ltr"><<a href="mailto:scm.blanc@gmail.com" target="_blank">scm.blanc@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">if #3 is possible (check&ignore the ack backed into the library) I would go for this option as well.</div></blockquote><div>The ACK is mostly ignored now. There is a log message saying that the GCM handler couldn't process it but otherwise the application is unaffected. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jun 17, 2015 at 4:28 PM, Matthias Wessendorf <span dir="ltr"><<a href="mailto:matzew@apache.org" target="_blank">matzew@apache.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi,<br><div class="gmail_extra"><br><div class="gmail_quote"><div><div>On Wed, Jun 17, 2015 at 4:03 PM, Summers Pittman <span dir="ltr"><<a href="mailto:supittma@redhat.com" target="_blank">supittma@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">Sooooo we have a 2.2.0 staged. Google has a ton of new functionality rolling out for GCM. <div><br></div><div>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.</div><div><br></div><div>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).</div><div><br></div><div>So the question to the list is :</div><div> 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?</div></div></blockquote><div><br></div></div></div><div>(assuming this is related to the NPE I am seeing in [1])<br></div><div><br></div><div>I think the ultimate goal for 2.2.0 should be to to not crash like in [1]. </div><div><br></div><div>I see three options:</div><div>1) document the work-around ([2]) and release the _existing_ 2.2.0, as is</div><div>-> 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)</div><div>2) delay the 2.2.0 and get full GCM 3.0 support in there</div><div>-> 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.</div><div>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</div><div>-> 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. </div><div><br></div><div><br></div><div>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</div><div><br></div><div>-Matthias</div><div><br></div><div>[1] <a href="https://issues.jboss.org/browse/AGDROID-425" target="_blank">https://issues.jboss.org/browse/AGDROID-425</a></div><div>[2] <a href="https://github.com/jboss-mobile/unified-push-helloworld/commit/077bfdce8980f86fde1662b490139573792c82fc" target="_blank">https://github.com/jboss-mobile/unified-push-helloworld/commit/077bfdce8980f86fde1662b490139573792c82fc</a></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><br></div><div><br></div></div>
<br>_______________________________________________<br>
aerogear-dev mailing list<br>
<a href="mailto:aerogear-dev@lists.jboss.org" target="_blank">aerogear-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><span><font color="#888888"><br></font></span></blockquote></div><span><font color="#888888"><br><br clear="all"><div><br></div>-- <br><div>Matthias Wessendorf <br><br>blog: <a href="http://matthiaswessendorf.wordpress.com/" target="_blank">http://matthiaswessendorf.wordpress.com/</a><br>sessions: <a href="http://www.slideshare.net/mwessendorf" target="_blank">http://www.slideshare.net/mwessendorf</a><br>twitter: <a href="http://twitter.com/mwessendorf" target="_blank">http://twitter.com/mwessendorf</a></div>
</font></span></div></div>
<br>_______________________________________________<br>
aerogear-dev mailing list<br>
<a href="mailto:aerogear-dev@lists.jboss.org" target="_blank">aerogear-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
aerogear-dev mailing list<br>
<a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br></blockquote></div><br></div></div>