Quite so. But onsucess, onerror is a pretty standard lingo...

Em 26/02/2014 13:27, "Matthias Wessendorf" <matzew@apache.org> escreveu:



On Wed, Feb 26, 2014 at 1:58 PM, Miguel Lemos <miguel21op@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@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:

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@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



--
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