[aerogear-dev] cordova push plugin simplification

[Matthias Wessendorf]

On Wed, Feb 26, 2014 at 11:26 AM, Matthias Wessendorf <matzew at apache.org>wrote:

>
>
>
> On Wed, Feb 26, 2014 at 10:40 AM, Erik Jan de Wit <edewit at 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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140226/8a59c285/attachment.html