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.
Also, do we have documented in some place what we are collecting?
"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.
@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
>