[aerogear-dev] Advanced Analtyics, new PR and call to the client tech leads

Corinne Krych corinnekrych at gmail.com
Tue May 5 05:21:34 EDT 2015


yeap, a new client API performing a PUt will do well

On 5 May 2015 at 11:17, Matthias Wessendorf <matzew at apache.org> wrote:

>
>
> On Tue, May 5, 2015 at 11:09 AM, Christos Vasilakis <cvasilak at gmail.com>
> wrote:
>
>>
>>
>> On Tue, May 5, 2015 at 11: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)
>>> - 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.
>>>
>>> second option makes sense +1
>>
>
> +1 on separate endpoint for metrics collection
>
> regarding changing categories: Do you mean a new method on the client SDK,
> performing a PUT, containing the new categories for the device token, to
> the existing endpoint (but using PUT),  instead of getting a
> /updateInstallation endpoint?
>
>
>
>>
>> -
>> Christos
>>
>>>
>>>
>>> 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
>>>
>>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20150505/54efb6fc/attachment-0001.html 


More information about the aerogear-dev mailing list