[aerogear-dev] cordova push plugin simplification

Wed Feb 26 08:54:58 EST 2014

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140226/17cbf941/attachment-0001.html 