On Mon, May 11, 2015 at 10:56 PM, Bruno Oliveira <bruno@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?
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  

Also, do we have documented in some place what we are collecting?
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@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@apache.org> wrote:
> >
> >> iOS is also semi automatic ;-)
> >>
> >> On Mon, May 11, 2015 at 3:41 PM, Daniel Passos <dpassos@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@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@redhat.com>
> >>>> wrote:
> >>>> > On Fri, May 8, 2015 at 2:10 AM, Matthias Wessendorf <
> >>>> matzew@apache.org>
> >>>> > wrote:
> >>>> >>
> >>>> >>
> >>>> >>
> >>>> >> On Thu, May 7, 2015 at 11:58 PM, Daniel Passos <dpassos@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-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/MessageHandler.java
> >>>> >>> [2]
> >>>> >>>
> >>>> https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/gcm/AeroGearGCMMessageReceiver.java
> >>>> >>> [3]
> >>>> >>>
> >>>> https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/RegistrarManager.java#L118
> >>>> >>> [4]
> >>>> >>>
> >>>> https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/RegistrarManager.java#L130
> >>>> >>>
> >>>> >>> -- Passos
> >>>> >>>
> >>>> >>>
> >>>> >>> On Wed, May 6, 2015 at 6:38 AM, Matthias Wessendorf <
> >>>> matzew@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/sender/src/main/java/org/jboss/aerogear/unifiedpush/message/sender/APNsPushNotificationSender.java#L107-L108
> >>>> >>>>
> >>>> >>>> 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/jaxrs/src/main/java/org/jboss/aerogear/unifiedpush/rest/registry/installations/InstallationRegistrationEndpoint.java#L128-L133
> >>>> >>>>
> >>>> >>>> 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@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@lists.jboss.org
> >>>> >> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >>>> >
> >>>> >
> >>>> >
> >>>> >
> >>>> > --
> >>>> > -- Passos
> >>>> >
> >>>> > _______________________________________________
> >>>> > aerogear-dev mailing list
> >>>> > aerogear-dev@lists.jboss.org
> >>>> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> Cheers,
> >>>>        Erik Jan
> >>>> _______________________________________________
> >>>> aerogear-dev mailing list
> >>>> aerogear-dev@lists.jboss.org
> >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>> -- Passos
> >>>
> >>> _______________________________________________
> >>> aerogear-dev mailing list
> >>> aerogear-dev@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@lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >>
> >
> >
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev@lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >

> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev


--

abstractj
PGP: 0x84DC9914
_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev