[aerogear-dev] cordova push plugin simplification

[Matthias Wessendorf]

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