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

Tue May 5 13:47:35 EDT 2015

On Tue, May 5, 2015 at 6:24 PM, Summers Pittman <supittma at redhat.com> wrote:

>
>
> On Tue, May 5, 2015 at 12:08 PM, Matthias Wessendorf <matzew at apache.org>
> wrote:
>
>>
>>
>> On Tue, May 5, 2015 at 5:51 PM, Summers Pittman <supittma at redhat.com>
>> wrote:
>>
>>>
>>>
>>> On Tue, May 5, 2015 at 5:17 AM, 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?
>>>>
>>>
>>> Adding a separate method on Android seems kind of weird. Android is
>>> rather spammy (intentionally and by design and according to big papa G's
>>> best practices) with the registration call.  Basically best practice on
>>> Android is call registration every time the application is opened.
>>>
>>
>> I see - that relates to your earlier comment, of calling 'register' all
>> the time on Android/iOS as well - instead of having a update() hook.
>>
>> I do believe that having an updateDeviceMetadata() (e.g. to update the
>> used categories, as the end-user is no longer interested in 'rihanna') does
>> make sense.
>>
>
> I'm conflicted.  I see the utility but I also want to keep the amount of
> mutable state to a minimum.
>
> I still think with the way Android is architected re-registering is a less
> error prone approach for developers.
>
> In this model when a users category changes they will regenerate the
> configuration using the new categories and register.  This will be the same
> if the user is registering for the first time or not.
>

Right, that's the original idea - and looks like works best on Android :-)

>
> If we add an update method the developer will need to EITHER make sure the
> categories are added to the config object when it is generated when the
> application loads anyway OR not include category information in the
> registration and then call update metadata with the proper categories.
>

right, it's not that great

>
>
>
>
>>
>> What about the metrics endpoint? Instead of sending that through the
>> registration endpoint? Agree on that or not?
>>
>
> I (mostly) agree on that point.  Registration is an intention to subscribe
> not a general data submission pipeline.  The thing which does metrics
> should probably not be part of the PushRegistrar at all.
>

Ah, right, I understand

> It might make sense to make it a composite object which embeds a registrar
> though.
>

and than internally it would deliver the metrics data to a different
endpoint - independent from the actual registration calls

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