Re: [aerogear-dev] cordova push plugin simplification

On Wed, Feb 26, 2014 at 1:58 PM, Miguel Lemos <miguel21op(a)gmail.com&gt;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(a)redhat.com&gt; > 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/2db7eedd234aa8b2b970620... > > 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(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 > -- 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