yeap, a new client API performing a PUt will do well
On 5 May 2015 at 11:17, Matthias Wessendorf <matzew(a)apache.org> wrote:
On Tue, May 5, 2015 at 11:09 AM, Christos Vasilakis <cvasilak(a)gmail.com>
wrote:
>
>
> On Tue, May 5, 2015 at 11:53 AM, Corinne Krych <corinnekrych(a)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/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)
>> - 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(a)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(a)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...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>
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>
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>
>>> wrote:
>>> >>>
>>> >>> Yeap
>>> >>> on it.
>>> >>>
>>> >>> On 30 April 2015 at 15:43, Sebastien Blanc
<scm.blanc(a)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(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
>>
>
>
> _______________________________________________
> 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