[aerogear-dev] cordova push plugin simplification

Burr Sutter bsutter at redhat.com
Wed Feb 26 13:41:00 EST 2014 

Hi Miguel, can you think of a use case where you need to react to the onSuccess? 

The only thing that I can think of is...some form of logic to "marry" the end-user's loginID with his device token - to address the "my device was lost, please cancel my push subscriptions for that device" scenario.

As far as simplification goes, it is critical that the API be the same for both iOS and Android by default.   The badge/sound thing caused me lots of pain :-)   It seems to me that the end-user only needs to specify URL, variantID and variantSecret with everything else being optional and cleverly defaulted.



On Feb 26, 2014, at 8:54 AM, Miguel Lemos <miguel21op at gmail.com> wrote:

> Quite so. But onsucess, onerror is a pretty standard lingo...
> 
> Em 26/02/2014 13:27, "Matthias Wessendorf" <matzew at apache.org> escreveu:
> 
> 
> 
> On Wed, Feb 26, 2014 at 1:58 PM, Miguel Lemos <miguel21op at gmail.com> wrote:
> I think there's no problem with the success handler as it is. Besides, it's handy and important the information we get from it.  Why change what's working just fine?
> 
> Well, Eriks suggestion does make the plugin a lot simpler. As said in other emails: since there is an error-callback (for errors when during registration with the UnifiedPush Server), this is pretty much enough to know. success _and_ error is somewhat redundant.
> 
> -Matthias
>  
> 
> Enviado do meu iPhone
> 
> No dia 26/02/2014, às 10:26, Erik Jan de Wit <edewit at redhat.com> escreveu:
> 
>>> 
>>> 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. 
>>> 
>>> True but it would be nice if we can still pass optionally a function for the registration successHandler, depending on the developer needs maybe I still wants to do something with his backend once the registration is suceesful. But I agree to have a default "hidden" function for that ... but should be able to override it. 
>> 
>> Unfortunately we can’t have both, either we have a successHandler or not. But really what do you want to do with your backend that depends on the successful registration with UPS? 
>> 
>>> 
>>> For iOS we have these badge and sound flags we could we get rid of those as well? 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:
>>> 
>>> Not really understand here what you mean, could you elaborate a bit ?  
>> 
>> On iOS when you register you can add flags to enable badges (little numbers on the app icon) and sounds so if the message contains a badge but you have registered it with badge = false the badge will be ignored. The user can also change these settings. So I suggest to always set them to true and if you don’t want to use a badge just don’t put it in the message.
>>> 
>>> 
>>> 
>>> 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>"
>>> 
>>> 
>>> 
>>> });
>>> 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.
>>> 
>>> That will be a convention to skip the senderId when the variant is an Android "type", yeah why not, I like that. 
>> 
>> I’m not sure that I follow you, but what I meant is to change the android push registration logic see here:
>> https://github.com/aerogear/aerogear-android/blob/2db7eedd234aa8b2b970620f1c06467baafffcb8/src/org/jboss/aerogear/android/impl/unifiedpush/AeroGearGCMPushRegistrar.java#L102
>> 
>> It uses the senderId to register itself with GCM and afterward it registers with UPS. Now if it would do that the other way around and the response of UPS would contain the senderId the client wouldn’t need to specify it.
>> 
>> On the cordova plugin the senderId is ignore when you are on iOS it’s only used on Android so leaving it in is not a problem, just nicer to not have it at all.
>> 
>>> 
>>> 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.
>>> 
>>> I like the idea but that can be tricky since multiple variants can have the same meta information (like "Android Free"/"Android Premium"), we should think about a convention. But again I like the idea and it is worth thinking about it. 
>> 
>> Ahh didn’t think about that one, right so we could still have this when you have one variant of each type? 
>> 
> 
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> 
> _______________________________________________
> 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
> 
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140226/d31d4761/attachment-0001.html

More information about the aerogear-dev mailing list