[aerogear-dev] Metrics Endpoint (was: Re: Advanced Analtyics, new PR and call to the client tech leads)

Wed May 6 05:38:02 EDT 2015

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/sender/src/main/java/org/jboss/aerogear/unifiedpush/message/sender/APNsPushNotificationSender.java#L107-L108

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/jaxrs/src/main/java/org/jboss/aerogear/unifiedpush/rest/registry/installations/InstallationRegistrationEndpoint.java#L128-L133

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

On Tue, May 5, 2015 at 7:53 PM, Matthias Wessendorf <matzew at apache.org>
wrote:

>
>
> On Tue, May 5, 2015 at 10:53 AM, Corinne Krych <corinnekrych at gmail.com>
> 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/AGPushPlugin.m#L82
>> 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 at redhat.com> 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 at gmail.com>
>>> 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...corinnekrych:AGPUSH-1232.analytics.push.notification?expand=1
>>> >
>>> > This client could be tested with HelloWorld. See:
>>> >
>>> >
>>> https://github.com/jboss-mobile/unified-push-helloworld/compare/jboss-mobile:swift...corinnekrych:AGPUSH-1232.analytics.push.notification?expand=1
>>> >
>>> > 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/f7d0a7e093327f9a84041910c4c2892280c88ffb/ios-swift/HelloWorldSwift/AppDelegate.swift#L152
>>> >
>>> > 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 at gmail.com> 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 at gmail.com> 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 at gmail.com> wrote:
>>> >>>
>>> >>> Yeap
>>> >>> on it.
>>> >>>
>>> >>> On 30 April 2015 at 15:43, Sebastien Blanc <scm.blanc at gmail.com>
>>> 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 at lists.jboss.org
>>> >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>> >>>
>>> >>>
>>> >>
>>> >> _______________________________________________
>>> >> aerogear-dev mailing list
>>> >> aerogear-dev at lists.jboss.org
>>> >> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>> >>
>>> >>
>>> >> _______________________________________________
>>> >> aerogear-dev mailing list
>>> >> aerogear-dev at lists.jboss.org
>>> >> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>> >
>>> >
>>> >
>>> > _______________________________________________
>>> > aerogear-dev mailing list
>>> > aerogear-dev at lists.jboss.org
>>> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>
>>>
>>>
>>> --
>>> Cheers,
>>>        Erik Jan
>>>
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>
>>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
>

-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20150506/9c89fa5f/attachment-0001.html 