On Wed, Feb 26, 2014 at 11:26 AM, Matthias Wessendorf <matzew(a)apache.org>wrote:
On Wed, Feb 26, 2014 at 10:40 AM, Erik Jan de Wit <edewit(a)redhat.com>wrote:
> Hi,
>
> As you may have experienced or seen the cordova push plugin is not always
> simple to get started with, there are still some things that are platform
> specific even though compared to the 'original' it has improved there is
> room for improvement. Here are some suggestions to make it even simpler:
>
> Right now the API looks like this:
>
> var pushConfig = {
> // senderID is only used in the Android/GCM case
> senderID: "<senderID e.g Google Project ID only for android>",
> pushServerURL: "<pushServerURL e.g http(s)//host:port/context
>",
> variantID: "<variantID e.g. 1234456-234320>",
> variantSecret: "<variantSecret e.g. 1234456-234320>",
> alias: "<alias e.g. a username or an email address optional>"}
> //badge and sound are iOS specific, and ignored on
Androidpush.register(successHandler, errorHandler, {"badge": "true",
"sound": "true",
> "ecb": "onNotification", pushConfig: pushConfig});
>
> Suggestion number one, is to remove the successHandler and use that as
> the callback for notifications:
>
> push.register(onNotification, errorHandler, {"badge": "true",
"sound": "true", pushConfig: pushConfig});
>
> Now the Javascript can verify that the callback is a function because
> it's no longer a string and the need for a separate successHandler is
> overrated as you will either get messages or your errorHandler gets
> invoked.
>
I like the idea of passing in a function (instead of a string), for the
notification handling.
However, the successHandler was meant to give feedback if registration w/
UPS was successful or not. Should we really remove that hook ?
yes, we can: since error tells the app: something went wrong (with
registration). So pretty much good enough to only have that one. If that is
not invoked: well registration must have been successful :-)
> For iOS we have these badge and sound flags we could we get rid of those
> as well?
>
yes, good point. Internally we set the to true; and if the message does
not contain sound/badge -> oh well :)
Good idea for simplification!
> When you don't want a badge then just don't send it in the message!? Then
> the pushConfig can be inlined making it look like this:
>
> push.register(onNotification, errorHandler, {
> // senderID is only used in the Android/GCM case
> senderID: "<senderID e.g Google Project ID only for android>",
> pushServerURL: "<pushServerURL e.g http(s)//host:port/context
>",
> variantID: "<variantID e.g. 1234456-234320>",
> variantSecret: "<variantSecret e.g. 1234456-234320>",
> alias: "<alias e.g. a username or an email address optional>"
> });
>
> looks really compact now
> Till now all these changes can be made on the plugin, but we could take
> it even further. Two things that are still platform dependent the senderId
> and the variantID/secret. Now senderId is 'known' by UPS so why do we need
> to specify it here? We could make senderId part of the response when
> registering a device on UPS then the client doesn't need to specify it and
> all configuration is in one place.
>
It's optional on UPS, as only really Android clients need it. And I think
originally Luke just added the 'senderID' to UPS for having something handy
(copy/paste usage).
So, I am not sure on that one, as that means we now have to enforce
Android Variants always get the senderID attribute. Could be done, yes, but
I am not sure.
>
> That leaves variantID/secret and that is the boldest proposal. How about
> we make it possible to register for an application instead for a specific
> variant? Then based on the meta information (deviceType, operatingSystem
> and osVersion) we choose the right variant.
>
-1
we should never 'deploy' the masterSecret and the applicationID on
clients. If that information is stolen (easy on devices), you can start
sending dirty assaults to ALL the devices for that application. Same w/ all
the different providers like Parse, Stackmob etc: they all use a
MasterKey/Password for the actual send. And they _highly_ recommend NOT
applying that to the clients (it's easy to leak that information)
-Matthias
>
> If we do all of the above there will be no platform specific code at all
> and the final script could look as simple as this:
>
> push.register(function(event) {
> alert(event.alert);
> },
> function(error) {
> throw error;
> }, {
> pushServerURL: "<pushServerURL e.g http(s)//host:port/context
>",
> applicationID: "<applicationID e.g. 1234456-234320>",
> secret: "<secret e.g. 1234456-234320>",
> alias: "<alias e.g. a username or an email address optional>"
> });
>
>
> Push notifications in one statement for all devices :)
>
> WDYT
> Erik Jan
>
> _______________________________________________
> 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
--
Matthias Wessendorf
blog:
http://matthiaswessendorf.wordpress.com/
sessions:
http://www.slideshare.net/mwessendorf
twitter:
http://twitter.com/mwessendorf