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

[Corinne Krych]

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.

++
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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20150505/063fa586/attachment-0001.html