<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, May 6, 2015 at 11:52 AM, 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"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Wed, May 6, 2015 at 11:47 AM, Sébastien 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="auto"><div><br><br>Envoyé de mon iPhone</div><span><div><br>Le 6 mai 2015 à 11:38, Matthias Wessendorf <<a href="mailto:matzew@apache.org" target="_blank">matzew@apache.org</a>> a écrit :<br><br></div><blockquote type="cite"><div><div dir="ltr"><div>Hi,<br></div><div><br></div><div>as discussed on the previous thread, there will be a new endpoint to 'track' the "App opened/launched due to received push notification".</div><div><br></div><div>Internally, on the UPS, the Push Message has an ID, which get's append to the payload of the notification, like here:</div><div><a href="https://github.com/matzew/aerogear-unifiedpush-server/blob/analytics/push/sender/src/main/java/org/jboss/aerogear/unifiedpush/message/sender/APNsPushNotificationSender.java#L107-L108" target="_blank">https://github.com/matzew/aerogear-unifiedpush-server/blob/analytics/push/sender/src/main/java/org/jboss/aerogear/unifiedpush/message/sender/APNsPushNotificationSender.java#L107-L108</a></div><div><br></div><div>On the client SDKs this will be read and a HTTP call made to the soon introduced MetricsEndpoint. Currently this info is send to the RegistrationEndpoint, including the deviceToken/registrationId. However, I think that the deviceToken/registrationId is currently not needed for metrics, since we are just interested in anonymous "app launched/opened due to push", and not a specific "DEVICE X did open, while DEVICE Y did not yet open".</div><div><br></div><div>So all we really need is the ID of the push notification, to be processed by our Metrics Service</div><div><a href="https://github.com/matzew/aerogear-unifiedpush-server/blob/analytics/jaxrs/src/main/java/org/jboss/aerogear/unifiedpush/rest/registry/installations/InstallationRegistrationEndpoint.java#L128-L133" target="_blank">https://github.com/matzew/aerogear-unifiedpush-server/blob/analytics/jaxrs/src/main/java/org/jboss/aerogear/unifiedpush/rest/registry/installations/InstallationRegistrationEndpoint.java#L128-L133</a></div><div><br></div><div>Therefore my proposal is have an endpoint:</div><div><br></div><div>PUT /metrics/pushmessage/{pushMessageID}</div><div><br></div><div>I think PUT is good/best, because there is nothing really created on the server, it's more updating the 'counter' on the existing PushMessageInformation object.</div><div><br></div><div>Thoughts?</div></div></div></blockquote></span>Let's make sure it's still protected by basic auth using the variantId, we need to know which variant is hit. </div></blockquote><div><br></div></span><div>yes :-) </div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div><br><div>Skipping the registration endpoint we might miss metadata, like os version etc ... But for this first version it should not be a issue. </div></div></div></blockquote><div><br></div></span><div>I think that would be nice to have percentage of OS/OS version - it would be not too hard to have that included.</div></div></div></div></blockquote><div><br></div><div>the variant gives us at least the platform - which would be good enough ;-) But perhaps, at some point, a version string would be nice.</div><div><br></div><div>However, on iOS SDK that is a bit of an issue, since that means the push registration SDK needs to use UIDevice APIs for automatic submit of the version ;-/</div><div>Today, this is done on the user code, on the Delegate - which is better. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>Are we, today, are already having a relationship between "app opened" and OS/OS_version? I don't really see that on the PR </div><div><div class="h5"><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div><div><div><div><br><blockquote type="cite"><div><div dir="ltr"><div>-Matthias</div><div><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 5, 2015 at 7:53 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: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"><br><div class="gmail_extra"><br><div class="gmail_quote"><span>On Tue, May 5, 2015 at 10:53 AM, Corinne Krych <span dir="ltr"><<a href="mailto:corinnekrych@gmail.com" target="_blank">corinnekrych@gmail.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">To give a bit of background on this background to foreground issue :))<div><br></div><div>Push Cordova plugin matches Cordova life cycle by storing some information locally see:</div><div><a href="https://github.com/aerogear/aerogear-cordova-push/blob/master/src/ios/AGPushPlugin.m#L82" target="_blank">https://github.com/aerogear/aerogear-cordova-push/blob/master/src/ios/AGPushPlugin.m#L82</a><br></div><div>Doing so allows you to call multiple time registration, even when an app comes back from background to foreground. you can do it because you have stored locally all the information neede for registration.</div><div><br></div><div>But when dealing directly with native apps, the life cycle does not always goes through a registration.</div><div><br></div><div>To sort out this issue,we can:</div><div>- either store locally at the ios-push lib level instead of doing it in Cordova plugin and then call registration API on all delegate methods (even though we don't want to register but just send the metrics)</div></div></blockquote><div><br></div></span><div>based on summers comments, I thought about this - perhaps this is the way to go.</div><div>For sending metrics, we do not need to run the registration again, with the new endpoint in place. The iOS push SDK could call a (private) method and just deliver the metrics related info - that's splits the concerns and removes the need to call register endpoint on places where we do not really need it</div><span><font color="#888888"><div><br></div><div>-M</div></font></span><div><div><div><br></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>- or leave the ios-push lib without any storage and provide a separate endpoint for sending metrics or changing categories. </div><div><br></div><div>I'd go for the second option.</div><div><br></div><div>++</div><div><span><font color="#888888">Corinne</font></span><div><div><br><div class="gmail_extra"><br><div class="gmail_quote">On 5 May 2015 at 10:39, Erik Jan de Wit <span dir="ltr"><<a href="mailto:edewit@redhat.com" target="_blank">edewit@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">I agree with this and maybe we want even more functionality moved,<br>
because also updating the categories is strange in a 'register'<br>
method. Say for instance you want to change the categories your<br>
interested in a developer has to call register again? And if I<br>
understand Corinnes mail that will currently not even work on iOS.<br>
<br>
For cordova I store the device info, because the lifecycle is<br>
different, but that is okay it's an integration problem.<br>
<br>
So updating the installation details should be a separate method that<br>
also contains updating the categories. That way we have a better split<br>
between a device that registers itself with UPS and updating the<br>
subscription data.<br>
<div><div><br>
<br>
On Tue, May 5, 2015 at 9:26 AM, Corinne Krych <<a href="mailto:corinnekrych@gmail.com" target="_blank">corinnekrych@gmail.com</a>> wrote:<br>
> Hello Sebi,<br>
><br>
><br>
> I've done an initial work on aerogear-ios-push [swift branch], adding a new<br>
> parameter when doing the registration to pass the ag-push-id. See:<br>
><br>
> <a href="https://github.com/aerogear/aerogear-ios-push/compare/aerogear:master...corinnekrych:AGPUSH-1232.analytics.push.notification?expand=1" target="_blank">https://github.com/aerogear/aerogear-ios-push/compare/aerogear:master...corinnekrych:AGPUSH-1232.analytics.push.notification?expand=1</a><br>
><br>
> This client could be tested with HelloWorld. See:<br>
><br>
> <a href="https://github.com/jboss-mobile/unified-push-helloworld/compare/jboss-mobile:swift...corinnekrych:AGPUSH-1232.analytics.push.notification?expand=1" target="_blank">https://github.com/jboss-mobile/unified-push-helloworld/compare/jboss-mobile:swift...corinnekrych:AGPUSH-1232.analytics.push.notification?expand=1</a><br>
><br>
> What is not covered is the background app coming to foreground through a<br>
> push notification. If you look at HelloWorld:<br>
><br>
> <a href="https://github.com/jboss-mobile/unified-push-helloworld/blob/f7d0a7e093327f9a84041910c4c2892280c88ffb/ios-swift/HelloWorldSwift/AppDelegate.swift#L152" target="_blank">https://github.com/jboss-mobile/unified-push-helloworld/blob/f7d0a7e093327f9a84041910c4c2892280c88ffb/ios-swift/HelloWorldSwift/AppDelegate.swift#L152</a><br>
><br>
> In iOS, when we go from background to foreground we don't go through<br>
> registration API. The iOS push lib doesn't store locally (as opposed to<br>
> windows sdk for ex) the device information. So i can't really make another<br>
> call to registration API. What i'd suggest is to have a separate endpoint<br>
> for metrics instead of having it coupled with registration endpoint. wdyt?<br>
><br>
> ++<br>
><br>
> Corinne<br>
><br>
> On 4 May 2015 at 19:07, Sébastien Blanc <<a href="mailto:scm.blanc@gmail.com" target="_blank">scm.blanc@gmail.com</a>> wrote:<br>
>><br>
>> Hi Corinne !<br>
>> We want to collect for both situations you described :)<br>
>><br>
>> Envoyé de mon iPhone<br>
>><br>
>> Le 4 mai 2015 à 17:53, Corinne Krych <<a href="mailto:corinnekrych@gmail.com" target="_blank">corinnekrych@gmail.com</a>> a écrit :<br>
>><br>
>> Hello Sebi,<br>
>><br>
>> After giving it a closer look, I've got a question for you: do we want to<br>
>> collect metrics only when an app is opened via push notification or do we<br>
>> also want to collect metrics when an app is brought to foreground by a push<br>
>> notification?<br>
>><br>
>> ++<br>
>> Corinne<br>
>><br>
>><br>
>> On 4 May 2015 at 10:21, Corinne Krych <<a href="mailto:corinnekrych@gmail.com" target="_blank">corinnekrych@gmail.com</a>> wrote:<br>
>>><br>
>>> Yeap<br>
>>> on it.<br>
>>><br>
>>> On 30 April 2015 at 15:43, Sebastien Blanc <<a href="mailto:scm.blanc@gmail.com" target="_blank">scm.blanc@gmail.com</a>> wrote:<br>
>>>><br>
>>>> Hi,<br>
>>>><br>
>>>> The Advanced Analytics task[1] has a new PR[2] that has been rebased on<br>
>>>> the latest master and got a lot of polishing.<br>
>>>><br>
>>>> Could the Client Tech Leads take a look at it [3] and review ? The only<br>
>>>> "breaking" change is the rename of the header's name that identifies a Push<br>
>>>> Notification, it's called now "aerogear-push-id"<br>
>>>><br>
>>>> Seb<br>
>>>><br>
>>>><br>
>>>><br>
>>>> [1] <a href="https://issues.jboss.org/browse/AGPUSH-971" target="_blank">https://issues.jboss.org/browse/AGPUSH-971</a><br>
>>>> [2] <a href="https://github.com/aerogear/aerogear-unifiedpush-server/pull/540" target="_blank">https://github.com/aerogear/aerogear-unifiedpush-server/pull/540</a><br>
>>>> [3] Subtasks of <a href="https://issues.jboss.org/browse/AGPUSH-971" target="_blank">https://issues.jboss.org/browse/AGPUSH-971</a><br>
>>>><br>
>>>><br>
>>>><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" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
>>><br>
>>><br>
>><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" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
>><br>
>><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" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
><br>
><br>
><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" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
<br>
<br>
<br>
</div></div><span><font color="#888888">--<br>
Cheers,<br>
Erik Jan<br>
</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" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a></div></div></blockquote></div><br></div></div></div></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" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br></blockquote></div></div></div><br><br clear="all"><div><br></div>-- <br><span><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>
</span></div></div>
</blockquote></div><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>
</div></div>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>aerogear-dev mailing list</span><br><span><a href="mailto:aerogear-dev@lists.jboss.org" target="_blank">aerogear-dev@lists.jboss.org</a></span><br><span><a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a></span></div></blockquote></div></div></div></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" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br></blockquote></div></div></div><div><div class="h5"><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>
</div></div></div></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">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>
</div></div>