Envoyé de mon iPhone Le 6 mai 2015 à 11:38, Matthias Wessendorf <matzew(a)apache.org&gt; a écrit : Hi, as discussed on the previous thread, there will be a new endpoint to 'track' the "App opened/launched due to received push notification". Internally, on the UPS, the Push Message has an ID, which get's append to the payload of the notification, like here: https://github.com/matzew/aerogear-unifiedpush-server/blob/analytics/push... 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". So all we really need is the ID of the push notification, to be processed by our Metrics Service https://github.com/matzew/aerogear-unifiedpush-server/blob/analytics/jaxr... Therefore my proposal is have an endpoint: PUT /metrics/pushmessage/{pushMessageID} 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. Thoughts? Let's make sure it's still protected by basic auth using the variantId, we need to know which variant is hit.

Skipping the registration endpoint we might miss metadata, like os version etc ... But for this first version it should not be a issue.

-Matthias On Tue, May 5, 2015 at 7:53 PM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: > > > On Tue, May 5, 2015 at 10:53 AM, Corinne Krych <corinnekrych(a)gmail.com&gt; > wrote: > >> To give a bit of background on this background to foreground issue :)) >> >> Push Cordova plugin matches Cordova life cycle by storing some >> information locally see: >> >> https://github.com/aerogear/aerogear-cordova-push/blob/master/src/ios/AGP... >> 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. >> >> But when dealing directly with native apps, the life cycle does not >> always goes through a registration. >> >> To sort out this issue,we can: >> - 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) >> > > based on summers comments, I thought about this - perhaps this is the way > to go. > 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 > > -M > > > > >> - or leave the ios-push lib without any storage and provide a separate >> endpoint for sending metrics or changing categories. >> >> I'd go for the second option. >> >> ++ >> Corinne >> >> >> On 5 May 2015 at 10:39, Erik Jan de Wit <edewit(a)redhat.com&gt; wrote: >> >>> I agree with this and maybe we want even more functionality moved, >>> because also updating the categories is strange in a 'register' >>> method. Say for instance you want to change the categories your >>> interested in a developer has to call register again? And if I >>> understand Corinnes mail that will currently not even work on iOS. >>> >>> For cordova I store the device info, because the lifecycle is >>> different, but that is okay it's an integration problem. >>> >>> So updating the installation details should be a separate method that >>> also contains updating the categories. That way we have a better split >>> between a device that registers itself with UPS and updating the >>> subscription data. >>> >>> >>> On Tue, May 5, 2015 at 9:26 AM, Corinne Krych <corinnekrych(a)gmail.com&gt; >>> wrote: >>> > Hello Sebi, >>> > >>> > >>> > I've done an initial work on aerogear-ios-push [swift branch], adding >>> a new >>> > parameter when doing the registration to pass the ag-push-id. See: >>> > >>> > >>> https://github.com/aerogear/aerogear-ios-push/compare/aerogear:master...c... >>> > >>> > This client could be tested with HelloWorld. See: >>> > >>> > >>> https://github.com/jboss-mobile/unified-push-helloworld/compare/jboss-mob... >>> > >>> > What is not covered is the background app coming to foreground >>> through a >>> > push notification. If you look at HelloWorld: >>> > >>> > >>> https://github.com/jboss-mobile/unified-push-helloworld/blob/f7d0a7e09332... >>> > >>> > In iOS, when we go from background to foreground we don't go through >>> > registration API. The iOS push lib doesn't store locally (as opposed >>> to >>> > windows sdk for ex) the device information. So i can't really make >>> another >>> > call to registration API. What i'd suggest is to have a separate >>> endpoint >>> > for metrics instead of having it coupled with registration endpoint. >>> wdyt? >>> > >>> > ++ >>> > >>> > Corinne >>> > >>> > On 4 May 2015 at 19:07, Sébastien Blanc <scm.blanc(a)gmail.com&gt; wrote: >>> >> >>> >> Hi Corinne ! >>> >> We want to collect for both situations you described :) >>> >> >>> >> Envoyé de mon iPhone >>> >> >>> >> Le 4 mai 2015 à 17:53, Corinne Krych <corinnekrych(a)gmail.com&gt; a >>> écrit : >>> >> >>> >> Hello Sebi, >>> >> >>> >> After giving it a closer look, I've got a question for you: do we >>> want to >>> >> collect metrics only when an app is opened via push notification or >>> do we >>> >> also want to collect metrics when an app is brought to foreground by >>> a push >>> >> notification? >>> >> >>> >> ++ >>> >> Corinne >>> >> >>> >> >>> >> On 4 May 2015 at 10:21, Corinne Krych <corinnekrych(a)gmail.com&gt; >>> wrote: >>> >>> >>> >>> Yeap >>> >>> on it. >>> >>> >>> >>> On 30 April 2015 at 15:43, Sebastien Blanc <scm.blanc(a)gmail.com&gt; >>> wrote: >>> >>>> >>> >>>> Hi, >>> >>>> >>> >>>> The Advanced Analytics task[1] has a new PR[2] that has been >>> rebased on >>> >>>> the latest master and got a lot of polishing. >>> >>>> >>> >>>> Could the Client Tech Leads take a look at it [3] and review ? The >>> only >>> >>>> "breaking" change is the rename of the header's name that >>> identifies a Push >>> >>>> Notification, it's called now "aerogear-push-id" >>> >>>> >>> >>>> Seb >>> >>>> >>> >>>> >>> >>>> >>> >>>> [1] https://issues.jboss.org/browse/AGPUSH-971 >>> >>>> [2] >>> https://github.com/aerogear/aerogear-unifiedpush-server/pull/540 >>> >>>> [3] Subtasks of https://issues.jboss.org/browse/AGPUSH-971 >>> >>>> >>> >>>> >>> >>>> >>> >>>> _______________________________________________ >>> >>>> 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 >>> >> >>> >> >>> >> _______________________________________________ >>> >> 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 >>> >>> >>> >>> -- >>> Cheers, >>> Erik Jan >>> >>> _______________________________________________ >>> 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 >> > > > > -- > 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

Le 6 mai 2015 à 11:52, Matthias Wessendorf <matzew(a)apache.org&gt; a écrit : > On Wed, May 6, 2015 at 11:47 AM, Sébastien Blanc <scm.blanc(a)gmail.com&gt; wrote: > > > Envoyé de mon iPhone > >> Le 6 mai 2015 à 11:38, Matthias Wessendorf <matzew(a)apache.org&gt; a écrit : >> >> Hi, >> >> as discussed on the previous thread, there will be a new endpoint to 'track' the "App opened/launched due to received push notification". >> >> Internally, on the UPS, the Push Message has an ID, which get's append to the payload of the notification, like here: >> https://github.com/matzew/aerogear-unifiedpush-server/blob/analytics/push... >> >> 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". >> >> So all we really need is the ID of the push notification, to be processed by our Metrics Service >> https://github.com/matzew/aerogear-unifiedpush-server/blob/analytics/jaxr... >> >> Therefore my proposal is have an endpoint: >> >> PUT /metrics/pushmessage/{pushMessageID} >> >> 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. >> >> Thoughts? > Let's make sure it's still protected by basic auth using the variantId, we need to know which variant is hit. yes :-) > > Skipping the registration endpoint we might miss metadata, like os version etc ... But for this first version it should not be a issue. I think that would be nice to have percentage of OS/OS version - it would be not too hard to have that included. Are we, today, are already having a relationship between "app opened" and OS/OS_version? I don't really see that on the PR

> >> -Matthias >> >> >>> On Tue, May 5, 2015 at 7:53 PM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: >>> >>> >>>> On Tue, May 5, 2015 at 10:53 AM, Corinne Krych <corinnekrych(a)gmail.com&gt; wrote: >>>> To give a bit of background on this background to foreground issue :)) >>>> >>>> Push Cordova plugin matches Cordova life cycle by storing some information locally see: >>>> https://github.com/aerogear/aerogear-cordova-push/blob/master/src/ios/AGP... >>>> 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. >>>> >>>> But when dealing directly with native apps, the life cycle does not always goes through a registration. >>>> >>>> To sort out this issue,we can: >>>> - 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) >>> >>> based on summers comments, I thought about this - perhaps this is the way to go. >>> 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 >>> >>> -M >>> >>> >>> >>>> - or leave the ios-push lib without any storage and provide a separate endpoint for sending metrics or changing categories. >>>> >>>> I'd go for the second option. >>>> >>>> ++ >>>> Corinne >>>> >>>> >>>>> On 5 May 2015 at 10:39, Erik Jan de Wit <edewit(a)redhat.com&gt; wrote: >>>>> I agree with this and maybe we want even more functionality moved, >>>>> because also updating the categories is strange in a 'register' >>>>> method. Say for instance you want to change the categories your >>>>> interested in a developer has to call register again? And if I >>>>> understand Corinnes mail that will currently not even work on iOS. >>>>> >>>>> For cordova I store the device info, because the lifecycle is >>>>> different, but that is okay it's an integration problem. >>>>> >>>>> So updating the installation details should be a separate method that >>>>> also contains updating the categories. That way we have a better split >>>>> between a device that registers itself with UPS and updating the >>>>> subscription data. >>>>> >>>>> >>>>> On Tue, May 5, 2015 at 9:26 AM, Corinne Krych <corinnekrych(a)gmail.com&gt; wrote: >>>>> > Hello Sebi, >>>>> > >>>>> > >>>>> > I've done an initial work on aerogear-ios-push [swift branch], adding a new >>>>> > parameter when doing the registration to pass the ag-push-id. See: >>>>> > >>>>> > https://github.com/aerogear/aerogear-ios-push/compare/aerogear:master...c... >>>>> > >>>>> > This client could be tested with HelloWorld. See: >>>>> > >>>>> > https://github.com/jboss-mobile/unified-push-helloworld/compare/jboss-mob... >>>>> > >>>>> > What is not covered is the background app coming to foreground through a >>>>> > push notification. If you look at HelloWorld: >>>>> > >>>>> > https://github.com/jboss-mobile/unified-push-helloworld/blob/f7d0a7e09332... >>>>> > >>>>> > In iOS, when we go from background to foreground we don't go through >>>>> > registration API. The iOS push lib doesn't store locally (as opposed to >>>>> > windows sdk for ex) the device information. So i can't really make another >>>>> > call to registration API. What i'd suggest is to have a separate endpoint >>>>> > for metrics instead of having it coupled with registration endpoint. wdyt? >>>>> > >>>>> > ++ >>>>> > >>>>> > Corinne >>>>> > >>>>> > On 4 May 2015 at 19:07, Sébastien Blanc <scm.blanc(a)gmail.com&gt; wrote: >>>>> >> >>>>> >> Hi Corinne ! >>>>> >> We want to collect for both situations you described :) >>>>> >> >>>>> >> Envoyé de mon iPhone >>>>> >> >>>>> >> Le 4 mai 2015 à 17:53, Corinne Krych <corinnekrych(a)gmail.com&gt; a écrit : >>>>> >> >>>>> >> Hello Sebi, >>>>> >> >>>>> >> After giving it a closer look, I've got a question for you: do we want to >>>>> >> collect metrics only when an app is opened via push notification or do we >>>>> >> also want to collect metrics when an app is brought to foreground by a push >>>>> >> notification? >>>>> >> >>>>> >> ++ >>>>> >> Corinne >>>>> >> >>>>> >> >>>>> >> On 4 May 2015 at 10:21, Corinne Krych <corinnekrych(a)gmail.com&gt; wrote: >>>>> >>> >>>>> >>> Yeap >>>>> >>> on it. >>>>> >>> >>>>> >>> On 30 April 2015 at 15:43, Sebastien Blanc <scm.blanc(a)gmail.com&gt; wrote: >>>>> >>>> >>>>> >>>> Hi, >>>>> >>>> >>>>> >>>> The Advanced Analytics task[1] has a new PR[2] that has been rebased on >>>>> >>>> the latest master and got a lot of polishing. >>>>> >>>> >>>>> >>>> Could the Client Tech Leads take a look at it [3] and review ? The only >>>>> >>>> "breaking" change is the rename of the header's name that identifies a Push >>>>> >>>> Notification, it's called now "aerogear-push-id" >>>>> >>>> >>>>> >>>> Seb >>>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> >>>> [1] https://issues.jboss.org/browse/AGPUSH-971 >>>>> >>>> [2] https://github.com/aerogear/aerogear-unifiedpush-server/pull/540 >>>>> >>>> [3] Subtasks of https://issues.jboss.org/browse/AGPUSH-971 >>>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> >>>> _______________________________________________ >>>>> >>>> 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 >>>>> >> >>>>> >> >>>>> >> _______________________________________________ >>>>> >> 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 >>>>> >>>>> >>>>> >>>>> -- >>>>> Cheers, >>>>> Erik Jan >>>>> >>>>> _______________________________________________ >>>>> 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 >>> >>> >>> >>> -- >>> 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 -- 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

Just to be clear, we are talking about metrics for messages delivered (received on device) or about really read/open? Because in Android land is not possible know when message was read/opened. We delegate how the message will be delivered/showed to the MessageHandler[1] and we don't have access to it.

Today we only have access when the message is delivered. Basically we receive the message in a AeroGearGCMMessageReceiver[2] do some checks and push the message for all Handles registered[3][4] [1] https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-an... [2] https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-an... [3] https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-an... [4] https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-an... -- Passos On Wed, May 6, 2015 at 6:38 AM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: > Hi, > > as discussed on the previous thread, there will be a new endpoint to > 'track' the "App opened/launched due to received push notification". > > Internally, on the UPS, the Push Message has an ID, which get's append to > the payload of the notification, like here: > > https://github.com/matzew/aerogear-unifiedpush-server/blob/analytics/push... > > 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". > > So all we really need is the ID of the push notification, to be processed > by our Metrics Service > > https://github.com/matzew/aerogear-unifiedpush-server/blob/analytics/jaxr... > > Therefore my proposal is have an endpoint: > > PUT /metrics/pushmessage/{pushMessageID} > > 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. > > Thoughts? > -Matthias > _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

On Fri, May 8, 2015 at 2:10 AM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: > > > On Thu, May 7, 2015 at 11:58 PM, Daniel Passos <dpassos(a)redhat.com&gt; > wrote: > >> Just to be clear, we are talking about metrics for messages delivered >> (received on device) or about really read/open? >> >> Because in Android land is not possible know when message was >> read/opened. We delegate how the message will be delivered/showed to the >> MessageHandler[1] and we don't have access to it. >> > > when the user clicks on the message, the app opens. That's what we track > w/ this PR, not the actual: I read the message - more "App was opened due > to push", see: > https://issues.jboss.org/browse/AGPUSH-971 > I can't do that. I can't do an action when app was opened. To do that we would need to create our own application[1] class, and all projects would need to extend it. As I have told in my previous email, for now I only can do something when the message is delivered to the device.

[1] http://developer.android.com/reference/android/app/Application.html > >> >> Today we only have access when the message is delivered. Basically we >> receive the message in a AeroGearGCMMessageReceiver[2] do some checks and >> push the message for all Handles registered[3][4] >> >> [1] >> https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-an... >> [2] >> https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-an... >> [3] >> https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-an... >> [4] >> https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-an... >> >> -- Passos >> >> >> On Wed, May 6, 2015 at 6:38 AM, Matthias Wessendorf <matzew(a)apache.org&gt; >> wrote: >> >>> Hi, >>> >>> as discussed on the previous thread, there will be a new endpoint to >>> 'track' the "App opened/launched due to received push notification". >>> >>> Internally, on the UPS, the Push Message has an ID, which get's append >>> to the payload of the notification, like here: >>> >>> https://github.com/matzew/aerogear-unifiedpush-server/blob/analytics/push... >>> >>> 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". >>> >>> So all we really need is the ID of the push notification, to be >>> processed by our Metrics Service >>> >>> https://github.com/matzew/aerogear-unifiedpush-server/blob/analytics/jaxr... >>> >>> Therefore my proposal is have an endpoint: >>> >>> PUT /metrics/pushmessage/{pushMessageID} >>> >>> 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. >>> >>> Thoughts? >>> -Matthias >>> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- -- Passos _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

but the android sdk could have a method for uploading the metrics, so that a developer can opt for having that displayed on the dashboard. This method can then also be used for cordova ;) On Mon, May 11, 2015 at 3:30 PM, Daniel Passos <dpassos(a)redhat.com&gt; wrote: > On Fri, May 8, 2015 at 2:10 AM, Matthias Wessendorf <matzew(a)apache.org&gt; > wrote: >> >> >> >> On Thu, May 7, 2015 at 11:58 PM, Daniel Passos <dpassos(a)redhat.com&gt; wrote: >>> >>> Just to be clear, we are talking about metrics for messages delivered >>> (received on device) or about really read/open? >>> >>> Because in Android land is not possible know when message was >>> read/opened. We delegate how the message will be delivered/showed to the >>> MessageHandler[1] and we don't have access to it. >> >> >> when the user clicks on the message, the app opens. That's what we track >> w/ this PR, not the actual: I read the message - more "App was opened due to >> push", see: >> https://issues.jboss.org/browse/AGPUSH-971 > > > I can't do that. I can't do an action when app was opened. To do that we > would need to create our own application[1] class, and all projects would > need to extend it. As I have told in my previous email, for now I only can > do something when the message is delivered to the device. > > [1] http://developer.android.com/reference/android/app/Application.html > >> >>> >>> >>> Today we only have access when the message is delivered. Basically we >>> receive the message in a AeroGearGCMMessageReceiver[2] do some checks and >>> push the message for all Handles registered[3][4] >>> >>> [1] >>> https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-an... >>> [2] >>> https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-an... >>> [3] >>> https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-an... >>> [4] >>> https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-an... >>> >>> -- Passos >>> >>> >>> On Wed, May 6, 2015 at 6:38 AM, Matthias Wessendorf <matzew(a)apache.org > >>> wrote: >>>> >>>> Hi, >>>> >>>> as discussed on the previous thread, there will be a new endpoint to >>>> 'track' the "App opened/launched due to received push notification". >>>> >>>> Internally, on the UPS, the Push Message has an ID, which get's append >>>> to the payload of the notification, like here: >>>> >>>> https://github.com/matzew/aerogear-unifiedpush-server/blob/analytics/push... >>>> >>>> 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". >>>> >>>> So all we really need is the ID of the push notification, to be >>>> processed by our Metrics Service >>>> >>>> https://github.com/matzew/aerogear-unifiedpush-server/blob/analytics/jaxr... >>>> >>>> Therefore my proposal is have an endpoint: >>>> >>>> PUT /metrics/pushmessage/{pushMessageID} >>>> >>>> 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. >>>> >>>> Thoughts? >>>> -Matthias >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev(a)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(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > -- > -- Passos > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -- Cheers, Erik Jan _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

iOS is also semi automatic ;-) On Mon, May 11, 2015 at 3:41 PM, Daniel Passos <dpassos(a)redhat.com&gt; wrote: > Of course. My point was just to be clear we can't do it "automatic" :) > > On Mon, May 11, 2015 at 10:39 AM, Erik Jan de Wit <edewit(a)redhat.com&gt; > wrote: > >> but the android sdk could have a method for uploading the metrics, so >> that a developer can opt for having that displayed on the dashboard. >> >> This method can then also be used for cordova ;) >> >> On Mon, May 11, 2015 at 3:30 PM, Daniel Passos <dpassos(a)redhat.com&gt; >> wrote: >> > On Fri, May 8, 2015 at 2:10 AM, Matthias Wessendorf <matzew(a)apache.org >> > >> > wrote: >> >> >> >> >> >> >> >> On Thu, May 7, 2015 at 11:58 PM, Daniel Passos <dpassos(a)redhat.com&gt; >> wrote: >> >>> >> >>> Just to be clear, we are talking about metrics for messages delivered >> >>> (received on device) or about really read/open? >> >>> >> >>> Because in Android land is not possible know when message was >> >>> read/opened. We delegate how the message will be delivered/showed to >> the >> >>> MessageHandler[1] and we don't have access to it. >> >> >> >> >> >> when the user clicks on the message, the app opens. That's what we >> track >> >> w/ this PR, not the actual: I read the message - more "App was opened >> due to >> >> push", see: >> >> https://issues.jboss.org/browse/AGPUSH-971 >> > >> > >> > I can't do that. I can't do an action when app was opened. To do that >> we >> > would need to create our own application[1] class, and all projects >> would >> > need to extend it. As I have told in my previous email, for now I only >> can >> > do something when the message is delivered to the device. >> > >> > [1] >> http://developer.android.com/reference/android/app/Application.html >> > >> >> >> >>> >> >>> >> >>> Today we only have access when the message is delivered. Basically we >> >>> receive the message in a AeroGearGCMMessageReceiver[2] do some >> checks and >> >>> push the message for all Handles registered[3][4] >> >>> >> >>> [1] >> >>> >> https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-an... >> >>> [2] >> >>> >> https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-an... >> >>> [3] >> >>> >> https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-an... >> >>> [4] >> >>> >> https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-an... >> >>> >> >>> -- Passos >> >>> >> >>> >> >>> On Wed, May 6, 2015 at 6:38 AM, Matthias Wessendorf < >> matzew(a)apache.org&gt; >> >>> wrote: >> >>>> >> >>>> Hi, >> >>>> >> >>>> as discussed on the previous thread, there will be a new endpoint to >> >>>> 'track' the "App opened/launched due to received push notification". >> >>>> >> >>>> Internally, on the UPS, the Push Message has an ID, which get's >> append >> >>>> to the payload of the notification, like here: >> >>>> >> >>>> >> https://github.com/matzew/aerogear-unifiedpush-server/blob/analytics/push... >> >>>> >> >>>> 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". >> >>>> >> >>>> So all we really need is the ID of the push notification, to be >> >>>> processed by our Metrics Service >> >>>> >> >>>> >> https://github.com/matzew/aerogear-unifiedpush-server/blob/analytics/jaxr... >> >>>> >> >>>> Therefore my proposal is have an endpoint: >> >>>> >> >>>> PUT /metrics/pushmessage/{pushMessageID} >> >>>> >> >>>> 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. >> >>>> >> >>>> Thoughts? >> >>>> -Matthias >> >>> >> >>> >> >>> _______________________________________________ >> >>> aerogear-dev mailing list >> >>> aerogear-dev(a)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(a)lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > >> > >> > >> > >> > -- >> > -- Passos >> > >> > _______________________________________________ >> > aerogear-dev mailing list >> > aerogear-dev(a)lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> >> -- >> Cheers, >> Erik Jan >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > > -- > -- Passos > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

Let's start with the "semi-automatic" approach ;) @passos : maybe you can use the same method's name to keep it unified ? (we can always change the names later)

On Mon, May 11, 2015 at 3:48 PM, Corinne Krych <corinnekrych(a)gmail.com&gt; wrote: > Yeap all is in "semi". > for iOs we'll have 2 public static methods: > > AGPushAnalytics.sendMetricWhenAppLaunched(serverURL: NSURL, > launchOptions: [NSObject:AnyObject]?) > AGPushAnalytics.sendMetricsWhenAppAwoken(serverURL: NSURL, > applicationState: UIApplicationState, userInfo: [NSObject:AnyObject]) > > If we want all automation we have to provide more wrapping around native > life cycle, which can be quite intrusive. > > ++ > Corinne > > On 11 May 2015 at 15:44, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: > >> iOS is also semi automatic ;-) >> >> On Mon, May 11, 2015 at 3:41 PM, Daniel Passos <dpassos(a)redhat.com&gt; >> wrote: >> >>> Of course. My point was just to be clear we can't do it "automatic" :) >>> >>> On Mon, May 11, 2015 at 10:39 AM, Erik Jan de Wit <edewit(a)redhat.com&gt; >>> wrote: >>> >>>> but the android sdk could have a method for uploading the metrics, so >>>> that a developer can opt for having that displayed on the dashboard. >>>> >>>> This method can then also be used for cordova ;) >>>> >>>> On Mon, May 11, 2015 at 3:30 PM, Daniel Passos <dpassos(a)redhat.com&gt; >>>> wrote: >>>> > On Fri, May 8, 2015 at 2:10 AM, Matthias Wessendorf < >>>> matzew(a)apache.org&gt; >>>> > wrote: >>>> >> >>>> >> >>>> >> >>>> >> On Thu, May 7, 2015 at 11:58 PM, Daniel Passos <dpassos(a)redhat.com&gt; >>>> wrote: >>>> >>> >>>> >>> Just to be clear, we are talking about metrics for messages >>>> delivered >>>> >>> (received on device) or about really read/open? >>>> >>> >>>> >>> Because in Android land is not possible know when message was >>>> >>> read/opened. We delegate how the message will be delivered/showed >>>> to the >>>> >>> MessageHandler[1] and we don't have access to it. >>>> >> >>>> >> >>>> >> when the user clicks on the message, the app opens. That's what we >>>> track >>>> >> w/ this PR, not the actual: I read the message - more "App was >>>> opened due to >>>> >> push", see: >>>> >> https://issues.jboss.org/browse/AGPUSH-971 >>>> > >>>> > >>>> > I can't do that. I can't do an action when app was opened. To do >>>> that we >>>> > would need to create our own application[1] class, and all projects >>>> would >>>> > need to extend it. As I have told in my previous email, for now I >>>> only can >>>> > do something when the message is delivered to the device. >>>> > >>>> > [1] >>>> http://developer.android.com/reference/android/app/Application.html >>>> > >>>> >> >>>> >>> >>>> >>> >>>> >>> Today we only have access when the message is delivered. Basically >>>> we >>>> >>> receive the message in a AeroGearGCMMessageReceiver[2] do some >>>> checks and >>>> >>> push the message for all Handles registered[3][4] >>>> >>> >>>> >>> [1] >>>> >>> >>>> https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-an... >>>> >>> [2] >>>> >>> >>>> https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-an... >>>> >>> [3] >>>> >>> >>>> https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-an... >>>> >>> [4] >>>> >>> >>>> https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-an... >>>> >>> >>>> >>> -- Passos >>>> >>> >>>> >>> >>>> >>> On Wed, May 6, 2015 at 6:38 AM, Matthias Wessendorf < >>>> matzew(a)apache.org&gt; >>>> >>> wrote: >>>> >>>> >>>> >>>> Hi, >>>> >>>> >>>> >>>> as discussed on the previous thread, there will be a new endpoint >>>> to >>>> >>>> 'track' the "App opened/launched due to received push >>>> notification". >>>> >>>> >>>> >>>> Internally, on the UPS, the Push Message has an ID, which get's >>>> append >>>> >>>> to the payload of the notification, like here: >>>> >>>> >>>> >>>> >>>> https://github.com/matzew/aerogear-unifiedpush-server/blob/analytics/push... >>>> >>>> >>>> >>>> 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". >>>> >>>> >>>> >>>> So all we really need is the ID of the push notification, to be >>>> >>>> processed by our Metrics Service >>>> >>>> >>>> >>>> >>>> https://github.com/matzew/aerogear-unifiedpush-server/blob/analytics/jaxr... >>>> >>>> >>>> >>>> Therefore my proposal is have an endpoint: >>>> >>>> >>>> >>>> PUT /metrics/pushmessage/{pushMessageID} >>>> >>>> >>>> >>>> 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. >>>> >>>> >>>> >>>> Thoughts? >>>> >>>> -Matthias >>>> >>> >>>> >>> >>>> >>> _______________________________________________ >>>> >>> aerogear-dev mailing list >>>> >>> aerogear-dev(a)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(a)lists.jboss.org >>>> >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> > >>>> > >>>> > >>>> > >>>> > -- >>>> > -- Passos >>>> > >>>> > _______________________________________________ >>>> > aerogear-dev mailing list >>>> > aerogear-dev(a)lists.jboss.org >>>> > https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>>> >>>> >>>> -- >>>> Cheers, >>>> Erik Jan >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>> >>> >>> >>> -- >>> -- Passos >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev(a)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(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 > _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

On 2015-05-11, Sebastien Blanc wrote: > Let's start with the "semi-automatic" approach ;) I think by "semi-automatic" you mean "it's up to the developer", right?

If yes, +1. Another question is: Is another HTTP request required only to feed metrics? I'm thinking about people with very limited data plans. If yes, that's definitely must be optional.

Also, do we have documented in some place what we are collecting?

>From our guide I have: "For analytic purposes on our Dashboard we store the content of the alert key sent to the UnifiedPush Server. The content of the alert key belongs to the metadata, which is deleted after 30 days, using a nightly job within the UnifiedPush Server." If we reach an agreement on it, test the endpoint against DDoS might be required.

> @passos : maybe you can use the same method's name to keep it unified ? (we > can always change the names later) > > > On Mon, May 11, 2015 at 3:48 PM, Corinne Krych <corinnekrych(a)gmail.com&gt; > wrote: > > > Yeap all is in "semi". > > for iOs we'll have 2 public static methods: > > > > AGPushAnalytics.sendMetricWhenAppLaunched(serverURL: NSURL, > > launchOptions: [NSObject:AnyObject]?) > > AGPushAnalytics.sendMetricsWhenAppAwoken(serverURL: NSURL, > > applicationState: UIApplicationState, userInfo: [NSObject:AnyObject]) > > > > If we want all automation we have to provide more wrapping around native > > life cycle, which can be quite intrusive. > > > > ++ > > Corinne > > > > On 11 May 2015 at 15:44, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: > > > >> iOS is also semi automatic ;-) > >> > >> On Mon, May 11, 2015 at 3:41 PM, Daniel Passos <dpassos(a)redhat.com&gt; > >> wrote: > >> > >>> Of course. My point was just to be clear we can't do it "automatic" :) > >>> > >>> On Mon, May 11, 2015 at 10:39 AM, Erik Jan de Wit <edewit(a)redhat.com > > >>> wrote: > >>> > >>>> but the android sdk could have a method for uploading the metrics, so > >>>> that a developer can opt for having that displayed on the dashboard. > >>>> > >>>> This method can then also be used for cordova ;) > >>>> > >>>> On Mon, May 11, 2015 at 3:30 PM, Daniel Passos <dpassos(a)redhat.com&gt; > >>>> wrote: > >>>> > On Fri, May 8, 2015 at 2:10 AM, Matthias Wessendorf < > >>>> matzew(a)apache.org&gt; > >>>> > wrote: > >>>> >> > >>>> >> > >>>> >> > >>>> >> On Thu, May 7, 2015 at 11:58 PM, Daniel Passos < dpassos(a)redhat.com&gt; > >>>> wrote: > >>>> >>> > >>>> >>> Just to be clear, we are talking about metrics for messages > >>>> delivered > >>>> >>> (received on device) or about really read/open? > >>>> >>> > >>>> >>> Because in Android land is not possible know when message was > >>>> >>> read/opened. We delegate how the message will be delivered/showed > >>>> to the > >>>> >>> MessageHandler[1] and we don't have access to it. > >>>> >> > >>>> >> > >>>> >> when the user clicks on the message, the app opens. That's what we > >>>> track > >>>> >> w/ this PR, not the actual: I read the message - more "App was > >>>> opened due to > >>>> >> push", see: > >>>> >> https://issues.jboss.org/browse/AGPUSH-971 > >>>> > > >>>> > > >>>> > I can't do that. I can't do an action when app was opened. To do that > >>>> we > >>>> > would need to create our own application[1] class, and all projects > >>>> would > >>>> > need to extend it. As I have told in my previous email, for now I > >>>> only can > >>>> > do something when the message is delivered to the device. > >>>> > > >>>> > [1] > >>>> http://developer.android.com/reference/android/app/Application.html > >>>> > > >>>> >> > >>>> >>> > >>>> >>> > >>>> >>> Today we only have access when the message is delivered. Basically > >>>> we > >>>> >>> receive the message in a AeroGearGCMMessageReceiver[2] do some > >>>> checks and > >>>> >>> push the message for all Handles registered[3][4] > >>>> >>> > >>>> >>> [1] > >>>> >>> > >>>> https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-an... > >>>> >>> [2] > >>>> >>> > >>>> https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-an... > >>>> >>> [3] > >>>> >>> > >>>> https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-an... > >>>> >>> [4] > >>>> >>> > >>>> https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-an... > >>>> >>> > >>>> >>> -- Passos > >>>> >>> > >>>> >>> > >>>> >>> On Wed, May 6, 2015 at 6:38 AM, Matthias Wessendorf < > >>>> matzew(a)apache.org&gt; > >>>> >>> wrote: > >>>> >>>> > >>>> >>>> Hi, > >>>> >>>> > >>>> >>>> as discussed on the previous thread, there will be a new endpoint > >>>> to > >>>> >>>> 'track' the "App opened/launched due to received push > >>>> notification". > >>>> >>>> > >>>> >>>> Internally, on the UPS, the Push Message has an ID, which get's > >>>> append > >>>> >>>> to the payload of the notification, like here: > >>>> >>>> > >>>> >>>> > >>>> https://github.com/matzew/aerogear-unifiedpush-server/blob/analytics/push... > >>>> >>>> > >>>> >>>> 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". > >>>> >>>> > >>>> >>>> So all we really need is the ID of the push notification, to be > >>>> >>>> processed by our Metrics Service > >>>> >>>> > >>>> >>>> > >>>> https://github.com/matzew/aerogear-unifiedpush-server/blob/analytics/jaxr... > >>>> >>>> > >>>> >>>> Therefore my proposal is have an endpoint: > >>>> >>>> > >>>> >>>> PUT /metrics/pushmessage/{pushMessageID} > >>>> >>>> > >>>> >>>> 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. > >>>> >>>> > >>>> >>>> Thoughts? > >>>> >>>> -Matthias > >>>> >>> > >>>> >>> > >>>> >>> _______________________________________________ > >>>> >>> aerogear-dev mailing list > >>>> >>> aerogear-dev(a)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(a)lists.jboss.org > >>>> >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > -- > >>>> > -- Passos > >>>> > > >>>> > _______________________________________________ > >>>> > aerogear-dev mailing list > >>>> > aerogear-dev(a)lists.jboss.org > >>>> > https://lists.jboss.org/mailman/listinfo/aerogear-dev > >>>> > >>>> > >>>> > >>>> -- > >>>> Cheers, > >>>> Erik Jan > >>>> _______________________________________________ > >>>> aerogear-dev mailing list > >>>> aerogear-dev(a)lists.jboss.org > >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev > >>>> > >>> > >>> > >>> > >>> -- > >>> -- Passos > >>> > >>> _______________________________________________ > >>> aerogear-dev mailing list > >>> aerogear-dev(a)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(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 > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -- abstractj PGP: 0x84DC9914 _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

On Mon, May 11, 2015 at 10:56 PM, Bruno Oliveira <bruno(a)abstractj.org&gt; wrote: > On 2015-05-11, Sebastien Blanc wrote: > > Let's start with the "semi-automatic" approach ;) > > I think by "semi-automatic" you mean "it's up to the developer", right? > right :) > If yes, +1. > > Another question is: Is another HTTP request required only > to feed metrics? I'm thinking about people with very limited data plans. > If yes, that's definitely must be optional. > Yes since we have to collect when a specific action occurs (open an app or bring to foreground) the only way is do a http request > > Also, do we have documented in some place what we are collecting? > We are not collecting anything with this advanced metrics, we are just "counting" anonymously. > >From our guide I have: > > "For analytic purposes on our Dashboard we store the content of the > alert key sent to the UnifiedPush Server. The content of the alert key > belongs to the metadata, which is deleted after 30 days, using a nightly > job within the UnifiedPush Server." > > If we reach an agreement on it, test the endpoint against DDoS might be > required. > Agreed. we should even test DDoS against all our "open" endpoints (registration, import, sender) > > > @passos : maybe you can use the same method's name to keep it unified ? > (we > > can always change the names later) > > > > > > On Mon, May 11, 2015 at 3:48 PM, Corinne Krych <corinnekrych(a)gmail.com&gt; > > wrote: > > > > > Yeap all is in "semi". > > > for iOs we'll have 2 public static methods: > > > > > > AGPushAnalytics.sendMetricWhenAppLaunched(serverURL: NSURL, > > > launchOptions: [NSObject:AnyObject]?) > > > AGPushAnalytics.sendMetricsWhenAppAwoken(serverURL: NSURL, > > > applicationState: UIApplicationState, userInfo: [NSObject:AnyObject]) > > > > > > If we want all automation we have to provide more wrapping around > native > > > life cycle, which can be quite intrusive. > > > > > > ++ > > > Corinne > > > > > > On 11 May 2015 at 15:44, Matthias Wessendorf <matzew(a)apache.org&gt; > wrote: > > > > > >> iOS is also semi automatic ;-) > > >> > > >> On Mon, May 11, 2015 at 3:41 PM, Daniel Passos <dpassos(a)redhat.com&gt; > > >> wrote: > > >> > > >>> Of course. My point was just to be clear we can't do it "automatic" > :) > > >>> > > >>> On Mon, May 11, 2015 at 10:39 AM, Erik Jan de Wit <edewit(a)redhat.com > > > > >>> wrote: > > >>> > > >>>> but the android sdk could have a method for uploading the metrics, > so > > >>>> that a developer can opt for having that displayed on the dashboard. > > >>>> > > >>>> This method can then also be used for cordova ;) > > >>>> > > >>>> On Mon, May 11, 2015 at 3:30 PM, Daniel Passos <dpassos(a)redhat.com&gt; > > >>>> wrote: > > >>>> > On Fri, May 8, 2015 at 2:10 AM, Matthias Wessendorf < > > >>>> matzew(a)apache.org&gt; > > >>>> > wrote: > > >>>> >> > > >>>> >> > > >>>> >> > > >>>> >> On Thu, May 7, 2015 at 11:58 PM, Daniel Passos < > dpassos(a)redhat.com&gt; > > >>>> wrote: > > >>>> >>> > > >>>> >>> Just to be clear, we are talking about metrics for messages > > >>>> delivered > > >>>> >>> (received on device) or about really read/open? > > >>>> >>> > > >>>> >>> Because in Android land is not possible know when message was > > >>>> >>> read/opened. We delegate how the message will be > delivered/showed > > >>>> to the > > >>>> >>> MessageHandler[1] and we don't have access to it. > > >>>> >> > > >>>> >> > > >>>> >> when the user clicks on the message, the app opens. That's what > we > > >>>> track > > >>>> >> w/ this PR, not the actual: I read the message - more "App was > > >>>> opened due to > > >>>> >> push", see: > > >>>> >> https://issues.jboss.org/browse/AGPUSH-971 > > >>>> > > > >>>> > > > >>>> > I can't do that. I can't do an action when app was opened. To do > that > > >>>> we > > >>>> > would need to create our own application[1] class, and all > projects > > >>>> would > > >>>> > need to extend it. As I have told in my previous email, for now I > > >>>> only can > > >>>> > do something when the message is delivered to the device. > > >>>> > > > >>>> > [1] > > >>>> http://developer.android.com/reference/android/app/Application.html > > >>>> > > > >>>> >> > > >>>> >>> > > >>>> >>> > > >>>> >>> Today we only have access when the message is delivered. > Basically > > >>>> we > > >>>> >>> receive the message in a AeroGearGCMMessageReceiver[2] do some > > >>>> checks and > > >>>> >>> push the message for all Handles registered[3][4] > > >>>> >>> > > >>>> >>> [1] > > >>>> >>> > > >>>> > https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-an... > > >>>> >>> [2] > > >>>> >>> > > >>>> > https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-an... > > >>>> >>> [3] > > >>>> >>> > > >>>> > https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-an... > > >>>> >>> [4] > > >>>> >>> > > >>>> > https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-an... > > >>>> >>> > > >>>> >>> -- Passos > > >>>> >>> > > >>>> >>> > > >>>> >>> On Wed, May 6, 2015 at 6:38 AM, Matthias Wessendorf < > > >>>> matzew(a)apache.org&gt; > > >>>> >>> wrote: > > >>>> >>>> > > >>>> >>>> Hi, > > >>>> >>>> > > >>>> >>>> as discussed on the previous thread, there will be a new > endpoint > > >>>> to > > >>>> >>>> 'track' the "App opened/launched due to received push > > >>>> notification". > > >>>> >>>> > > >>>> >>>> Internally, on the UPS, the Push Message has an ID, which get's > > >>>> append > > >>>> >>>> to the payload of the notification, like here: > > >>>> >>>> > > >>>> >>>> > > >>>> > https://github.com/matzew/aerogear-unifiedpush-server/blob/analytics/push... > > >>>> >>>> > > >>>> >>>> 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". > > >>>> >>>> > > >>>> >>>> So all we really need is the ID of the push notification, to be > > >>>> >>>> processed by our Metrics Service > > >>>> >>>> > > >>>> >>>> > > >>>> > https://github.com/matzew/aerogear-unifiedpush-server/blob/analytics/jaxr... > > >>>> >>>> > > >>>> >>>> Therefore my proposal is have an endpoint: > > >>>> >>>> > > >>>> >>>> PUT /metrics/pushmessage/{pushMessageID} > > >>>> >>>> > > >>>> >>>> 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. > > >>>> >>>> > > >>>> >>>> Thoughts? > > >>>> >>>> -Matthias > > >>>> >>> > > >>>> >>> > > >>>> >>> _______________________________________________ > > >>>> >>> aerogear-dev mailing list > > >>>> >>> aerogear-dev(a)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(a)lists.jboss.org > > >>>> >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > >>>> > > > >>>> > > > >>>> > > > >>>> > > > >>>> > -- > > >>>> > -- Passos > > >>>> > > > >>>> > _______________________________________________ > > >>>> > aerogear-dev mailing list > > >>>> > aerogear-dev(a)lists.jboss.org > > >>>> > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > >>>> > > >>>> > > >>>> > > >>>> -- > > >>>> Cheers, > > >>>> Erik Jan > > >>>> _______________________________________________ > > >>>> aerogear-dev mailing list > > >>>> aerogear-dev(a)lists.jboss.org > > >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > >>>> > > >>> > > >>> > > >>> > > >>> -- > > >>> -- Passos > > >>> > > >>> _______________________________________________ > > >>> aerogear-dev mailing list > > >>> aerogear-dev(a)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(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 > > > > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev(a)lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > -- > > abstractj > PGP: 0x84DC9914 > _______________________________________________ > 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

On Mon, May 11, 2015 at 10:56 PM, Bruno Oliveira <bruno(a)abstractj.org&gt; wrote: > On 2015-05-11, Sebastien Blanc wrote: > > Let's start with the "semi-automatic" approach ;) > > I think by "semi-automatic" you mean "it's up to the developer", right? > If yes, +1. > > Another question is: Is another HTTP request required only > to feed metrics? I'm thinking about people with very limited data plans. > If yes, that's definitely must be optional. > > Also, do we have documented in some place what we are collecting? > >From our guide I have: > > "For analytic purposes on our Dashboard we store the content of the > alert key sent to the UnifiedPush Server. The content of the alert key > belongs to the metadata, which is deleted after 30 days, using a nightly > job within the UnifiedPush Server." > the collecting of pay, which you quoted is documented, yes (it is true for 1.0.3 already) That we collect the open is NOT yet documented. It is part of 1.1.0.Fianl doc, of the new UI. I will update the "warning" section on the begining as well, not just mention the new stats on the UI parts. makes sense ?

> > If we reach an agreement on it, test the endpoint against DDoS might be > required. > > > @passos : maybe you can use the same method's name to keep it unified ? > (we > > can always change the names later) > > > > > > On Mon, May 11, 2015 at 3:48 PM, Corinne Krych <corinnekrych(a)gmail.com&gt; > > wrote: > > > > > Yeap all is in "semi". > > > for iOs we'll have 2 public static methods: > > > > > > AGPushAnalytics.sendMetricWhenAppLaunched(serverURL: NSURL, > > > launchOptions: [NSObject:AnyObject]?) > > > AGPushAnalytics.sendMetricsWhenAppAwoken(serverURL: NSURL, > > > applicationState: UIApplicationState, userInfo: [NSObject:AnyObject]) > > > > > > If we want all automation we have to provide more wrapping around > native > > > life cycle, which can be quite intrusive. > > > > > > ++ > > > Corinne > > > > > > On 11 May 2015 at 15:44, Matthias Wessendorf <matzew(a)apache.org&gt; > wrote: > > > > > >> iOS is also semi automatic ;-) > > >> > > >> On Mon, May 11, 2015 at 3:41 PM, Daniel Passos <dpassos(a)redhat.com&gt; > > >> wrote: > > >> > > >>> Of course. My point was just to be clear we can't do it "automatic" > :) > > >>> > > >>> On Mon, May 11, 2015 at 10:39 AM, Erik Jan de Wit <edewit(a)redhat.com > > > > >>> wrote: > > >>> > > >>>> but the android sdk could have a method for uploading the metrics, > so > > >>>> that a developer can opt for having that displayed on the dashboard. > > >>>> > > >>>> This method can then also be used for cordova ;) > > >>>> > > >>>> On Mon, May 11, 2015 at 3:30 PM, Daniel Passos <dpassos(a)redhat.com&gt; > > >>>> wrote: > > >>>> > On Fri, May 8, 2015 at 2:10 AM, Matthias Wessendorf < > > >>>> matzew(a)apache.org&gt; > > >>>> > wrote: > > >>>> >> > > >>>> >> > > >>>> >> > > >>>> >> On Thu, May 7, 2015 at 11:58 PM, Daniel Passos < > dpassos(a)redhat.com&gt; > > >>>> wrote: > > >>>> >>> > > >>>> >>> Just to be clear, we are talking about metrics for messages > > >>>> delivered > > >>>> >>> (received on device) or about really read/open? > > >>>> >>> > > >>>> >>> Because in Android land is not possible know when message was > > >>>> >>> read/opened. We delegate how the message will be > delivered/showed > > >>>> to the > > >>>> >>> MessageHandler[1] and we don't have access to it. > > >>>> >> > > >>>> >> > > >>>> >> when the user clicks on the message, the app opens. That's what > we > > >>>> track > > >>>> >> w/ this PR, not the actual: I read the message - more "App was > > >>>> opened due to > > >>>> >> push", see: > > >>>> >> https://issues.jboss.org/browse/AGPUSH-971 > > >>>> > > > >>>> > > > >>>> > I can't do that. I can't do an action when app was opened. To do > that > > >>>> we > > >>>> > would need to create our own application[1] class, and all > projects > > >>>> would > > >>>> > need to extend it. As I have told in my previous email, for now I > > >>>> only can > > >>>> > do something when the message is delivered to the device. > > >>>> > > > >>>> > [1] > > >>>> http://developer.android.com/reference/android/app/Application.html > > >>>> > > > >>>> >> > > >>>> >>> > > >>>> >>> > > >>>> >>> Today we only have access when the message is delivered. > Basically > > >>>> we > > >>>> >>> receive the message in a AeroGearGCMMessageReceiver[2] do some > > >>>> checks and > > >>>> >>> push the message for all Handles registered[3][4] > > >>>> >>> > > >>>> >>> [1] > > >>>> >>> > > >>>> > https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-an... > > >>>> >>> [2] > > >>>> >>> > > >>>> > https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-an... > > >>>> >>> [3] > > >>>> >>> > > >>>> > https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-an... > > >>>> >>> [4] > > >>>> >>> > > >>>> > https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-an... > > >>>> >>> > > >>>> >>> -- Passos > > >>>> >>> > > >>>> >>> > > >>>> >>> On Wed, May 6, 2015 at 6:38 AM, Matthias Wessendorf < > > >>>> matzew(a)apache.org&gt; > > >>>> >>> wrote: > > >>>> >>>> > > >>>> >>>> Hi, > > >>>> >>>> > > >>>> >>>> as discussed on the previous thread, there will be a new > endpoint > > >>>> to > > >>>> >>>> 'track' the "App opened/launched due to received push > > >>>> notification". > > >>>> >>>> > > >>>> >>>> Internally, on the UPS, the Push Message has an ID, which get's > > >>>> append > > >>>> >>>> to the payload of the notification, like here: > > >>>> >>>> > > >>>> >>>> > > >>>> > https://github.com/matzew/aerogear-unifiedpush-server/blob/analytics/push... > > >>>> >>>> > > >>>> >>>> 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". > > >>>> >>>> > > >>>> >>>> So all we really need is the ID of the push notification, to be > > >>>> >>>> processed by our Metrics Service > > >>>> >>>> > > >>>> >>>> > > >>>> > https://github.com/matzew/aerogear-unifiedpush-server/blob/analytics/jaxr... > > >>>> >>>> > > >>>> >>>> Therefore my proposal is have an endpoint: > > >>>> >>>> > > >>>> >>>> PUT /metrics/pushmessage/{pushMessageID} > > >>>> >>>> > > >>>> >>>> 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. > > >>>> >>>> > > >>>> >>>> Thoughts? > > >>>> >>>> -Matthias > > >>>> >>> > > >>>> >>> > > >>>> >>> _______________________________________________ > > >>>> >>> aerogear-dev mailing list > > >>>> >>> aerogear-dev(a)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(a)lists.jboss.org > > >>>> >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > >>>> > > > >>>> > > > >>>> > > > >>>> > > > >>>> > -- > > >>>> > -- Passos > > >>>> > > > >>>> > _______________________________________________ > > >>>> > aerogear-dev mailing list > > >>>> > aerogear-dev(a)lists.jboss.org > > >>>> > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > >>>> > > >>>> > > >>>> > > >>>> -- > > >>>> Cheers, > > >>>> Erik Jan > > >>>> _______________________________________________ > > >>>> aerogear-dev mailing list > > >>>> aerogear-dev(a)lists.jboss.org > > >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > >>>> > > >>> > > >>> > > >>> > > >>> -- > > >>> -- Passos > > >>> > > >>> _______________________________________________ > > >>> aerogear-dev mailing list > > >>> aerogear-dev(a)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(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 > > > > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev(a)lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > -- > > abstractj > PGP: 0x84DC9914 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev