On Mon, May 11, 2015 at 10:56 PM, Bruno Oliveira <bruno(a)abstractj.org>
wrote:
On 2015-05-11, Sebastien Blanc wrote:
> Let's start with the "semi-automatic" approach ;)
I think by "semi-automatic" you mean "it's up to the developer",
right?
If yes, +1.
Another question is: Is another HTTP request required only
to feed metrics? I'm thinking about people with very limited data plans.
If yes, that's definitely must be optional.
Yes since we have to collect when a specific action occurs (open an app or
bring to foreground) the only way is do a http request
We are not collecting anything with this advanced metrics, we are just
"counting" anonymously.
>From our guide I have:
"For analytic purposes on our Dashboard we store the content of the
alert key sent to the UnifiedPush Server. The content of the alert key
belongs to the metadata, which is deleted after 30 days, using a nightly
job within the UnifiedPush Server."
If we reach an agreement on it, test the endpoint against DDoS might be
required.
Agreed.
we should even test DDoS against all our "open" endpoints (registration,
import, sender)
> @passos : maybe you can use the same method's name to keep it unified ?
(we
> can always change the names later)
>
>
> On Mon, May 11, 2015 at 3:48 PM, Corinne Krych <corinnekrych(a)gmail.com>
> wrote:
>
> > Yeap all is in "semi".
> > for iOs we'll have 2 public static methods:
> >
> > AGPushAnalytics.sendMetricWhenAppLaunched(serverURL: NSURL,
> > launchOptions: [NSObject:AnyObject]?)
> > AGPushAnalytics.sendMetricsWhenAppAwoken(serverURL: NSURL,
> > applicationState: UIApplicationState, userInfo: [NSObject:AnyObject])
> >
> > If we want all automation we have to provide more wrapping around
native
> > life cycle, which can be quite intrusive.
> >
> > ++
> > Corinne
> >
> > On 11 May 2015 at 15:44, Matthias Wessendorf <matzew(a)apache.org>
wrote:
> >
> >> iOS is also semi automatic ;-)
> >>
> >> On Mon, May 11, 2015 at 3:41 PM, Daniel Passos <dpassos(a)redhat.com>
> >> wrote:
> >>
> >>> Of course. My point was just to be clear we can't do it
"automatic"
:)
> >>>
> >>> On Mon, May 11, 2015 at 10:39 AM, Erik Jan de Wit
<edewit(a)redhat.com
>
> >>> wrote:
> >>>
> >>>> but the android sdk could have a method for uploading the metrics,
so
> >>>> that a developer can opt for having that displayed on the
dashboard.
> >>>>
> >>>> This method can then also be used for cordova ;)
> >>>>
> >>>> On Mon, May 11, 2015 at 3:30 PM, Daniel Passos
<dpassos(a)redhat.com>
> >>>> wrote:
> >>>> > On Fri, May 8, 2015 at 2:10 AM, Matthias Wessendorf <
> >>>> matzew(a)apache.org>
> >>>> > wrote:
> >>>> >>
> >>>> >>
> >>>> >>
> >>>> >> On Thu, May 7, 2015 at 11:58 PM, Daniel Passos <
dpassos(a)redhat.com>
> >>>> wrote:
> >>>> >>>
> >>>> >>> Just to be clear, we are talking about metrics for
messages
> >>>> delivered
> >>>> >>> (received on device) or about really read/open?
> >>>> >>>
> >>>> >>> Because in Android land is not possible know when
message was
> >>>> >>> read/opened. We delegate how the message will be
delivered/showed
> >>>> to the
> >>>> >>> MessageHandler[1] and we don't have access to it.
> >>>> >>
> >>>> >>
> >>>> >> when the user clicks on the message, the app opens.
That's what
we
> >>>> track
> >>>> >> w/ this PR, not the actual: I read the message - more
"App was
> >>>> opened due to
> >>>> >> push", see:
> >>>> >>
https://issues.jboss.org/browse/AGPUSH-971
> >>>> >
> >>>> >
> >>>> > I can't do that. I can't do an action when app was
opened. To do
that
> >>>> we
> >>>> > would need to create our own application[1] class, and all
projects
> >>>> would
> >>>> > need to extend it. As I have told in my previous email, for
now I
> >>>> only can
> >>>> > do something when the message is delivered to the device.
> >>>> >
> >>>> > [1]
> >>>>
http://developer.android.com/reference/android/app/Application.html
> >>>> >
> >>>> >>
> >>>> >>>
> >>>> >>>
> >>>> >>> Today we only have access when the message is
delivered.
Basically
> >>>> we
> >>>> >>> receive the message in a AeroGearGCMMessageReceiver[2]
do some
> >>>> checks and
> >>>> >>> push the message for all Handles registered[3][4]
> >>>> >>>
> >>>> >>> [1]
> >>>> >>>
> >>>>
https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-an...
> >>>> >>> [2]
> >>>> >>>
> >>>>
https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-an...
> >>>> >>> [3]
> >>>> >>>
> >>>>
https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-an...
> >>>> >>> [4]
> >>>> >>>
> >>>>
https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-an...
> >>>> >>>
> >>>> >>> -- Passos
> >>>> >>>
> >>>> >>>
> >>>> >>> On Wed, May 6, 2015 at 6:38 AM, Matthias Wessendorf
<
> >>>> matzew(a)apache.org>
> >>>> >>> wrote:
> >>>> >>>>
> >>>> >>>> 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...
> >>>> >>>>
> >>>> >>>> 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/jaxr...
> >>>> >>>>
> >>>> >>>> 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
> >>>> >>>
> >>>> >>>
> >>>> >>> _______________________________________________
> >>>> >>> 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
> >>>> >
> >>>> >
> >>>> >
> >>>> >
> >>>> > --
> >>>> > -- Passos
> >>>> >
> >>>> > _______________________________________________
> >>>> > 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
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>> -- Passos
> >>>
> >>> _______________________________________________
> >>> 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
> >>
> >
> >
> > _______________________________________________
> > 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
--
abstractj
PGP: 0x84DC9914
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev