4:40 a.m.
Hi,
As you may have experienced or seen the cordova push plugin is not always simple to get
started with, there are still some things that are platform specific even though compared
to the ‘original’ it has improved there is room for improvement. Here are some suggestions
to make it even simpler:
Right now the API looks like this:
var pushConfig = {
// 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>"
}
//badge and sound are iOS specific, and ignored on Android
push.register(successHandler, errorHandler, {"badge": "true",
"sound": "true",
"ecb": "onNotification", pushConfig: pushConfig});
Suggestion number one, is to remove the successHandler and use that as the callback for
notifications:
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.
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:
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 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.
If we do all of the above there will be no platform specific code at all and the final
script could look as simple as this:
push.register(function(event) {
alert(event.alert);
},
function(error) {
throw error;
}, {
pushServerURL: "<pushServerURL e.g http(s)//host:port/context >",
applicationID: "<applicationID e.g. 1234456-234320>",
secret: "<secret e.g. 1234456-234320>",
alias: "<alias e.g. a username or an email address optional>"
});
Push notifications in one statement for all devices :)
WDYT
Erik Jan
5 a.m.
Great Ideas Erik !
Comments inline
On Wed, Feb 26, 2014 at 10:40 AM, Erik Jan de Wit <edewit(a)redhat.com> wrote:
Hi,
As you may have experienced or seen the cordova push plugin is not always
simple to get started with, there are still some things that are platform
specific even though compared to the 'original' it has improved there is
room for improvement. Here are some suggestions to make it even simpler:
Right now the API looks like this:
var pushConfig = {
// 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>"}
//badge and sound are iOS specific, and ignored on Androidpush.register(successHandler,
errorHandler, {"badge": "true", "sound": "true",
"ecb": "onNotification", pushConfig: pushConfig});
Suggestion number one, is to remove the successHandler and use that as the
callback for notifications:
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.
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 ?
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.
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.
If we do all of the above there will be no platform specific code at all
and the final script could look as simple as this:
push.register(function(event) {
alert(event.alert);
},
function(error) {
throw error;
}, {
pushServerURL: "<pushServerURL e.g http(s)//host:port/context >",
applicationID: "<applicationID e.g. 1234456-234320>",
secret: "<secret e.g. 1234456-234320>",
alias: "<alias e.g. a username or an email address optional>"
});
Push notifications in one statement for all devices :)
WDYT
Erik Jan
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
5:26 a.m.
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?
7:58 a.m.
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?
Enviado do meu iPhone
No dia 26/02/2014, às 10:26, Erik Jan de Wit <edewit(a)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/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
8:27 a.m.
On Wed, Feb 26, 2014 at 1:58 PM, Miguel Lemos <miguel21op(a)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(a)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/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
8:54 a.m.
Quite so. But onsucess, onerror is a pretty standard lingo...
Em 26/02/2014 13:27, "Matthias Wessendorf" <matzew(a)apache.org> escreveu:
On Wed, Feb 26, 2014 at 1:58 PM, Miguel Lemos <miguel21op(a)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(a)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/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
1:41 p.m.
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(a)gmail.com> wrote:
Quite so. But onsucess, onerror is a pretty standard lingo...
Em 26/02/2014 13:27, "Matthias Wessendorf" <matzew(a)apache.org> escreveu:
On Wed, Feb 26, 2014 at 1:58 PM, Miguel Lemos <miguel21op(a)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(a)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/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
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
1:54 p.m.
onSucess = the device has managed to register on the service. It's a one
time info, but priceless if we are still struggling to figure out how to
make the whole thing work. For the end user, no that has no use.
About the simplification: 130000% agree :)
About the sound: useless, if we want to make it ring, don't need the push
notification API to do it. The badge (I even don't know what those values -
1, 3, 7... - mean, not yet...)
2:20 p.m.
On Wednesday, February 26, 2014, Miguel Lemos <miguel21op(a)gmail.com> wrote:
onSucess = the device has managed to register on the service.
It's a one
time info, but priceless if we are still struggling to figure out how to
make the whole thing work. For the end user, no that has no use.
If dev registration is not successful: onError is called; IMO that's almost
same: dev does know: whoops something went wrong
About the simplification: 130000% agree :)
About the sound: useless, if we want to make it ring, don't need the push
notification API to do it. The badge (I even don't know what those values -
1, 3, 7... - mean, not yet...)
badge, as explained in our message format spec is apple keyword:
http://aerogear.org/docs/specs/aerogear-push-messages/
--
Sent from Gmail Mobile
2:28 p.m.
Yes of course.
But as I told in a previous post onsucess, onerror is a standard way to
"organize" things, only that.
People need to know they are walking on known territory, dealing as far as
possible with standard concepts. That's a small thing, not important at
all, but we must in general pay attention to that kind of issues.
On Wed, Feb 26, 2014 at 7:20 PM, Matthias Wessendorf <matzew(a)apache.org>wrote:
On Wednesday, February 26, 2014, Miguel Lemos <miguel21op(a)gmail.com>
wrote:
> onSucess = the device has managed to register on the service. It's a one
> time info, but priceless if we are still struggling to figure out how to
> make the whole thing work. For the end user, no that has no use.
>
If dev registration is not successful: onError is called; IMO that's
almost same: dev does know: whoops something went wrong
> About the simplification: 130000% agree :)
>
> About the sound: useless, if we want to make it ring, don't need the
> push notification API to do it. The badge (I even don't know what those
> values - 1, 3, 7... - mean, not yet...)
>
badge, as explained in our message format spec is apple keyword:
http://aerogear.org/docs/specs/aerogear-push-messages/
--
Sent from Gmail Mobile
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
3:08 p.m.
I can be wrong, but if the device was lost such permission should be revoked on the
server. There's nothing to do with "onSuccess"
On Feb 26, 2014, at 3:41 PM, Burr Sutter <bsutter(a)redhat.com>
wrote:
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.
3:15 p.m.
On Feb 26, 2014, at 3:08 PM, Bruno Oliveira <bruno(a)abstractj.org> wrote:
I can be wrong, but if the device was lost such permission should be
revoked on the server. There's nothing to do with "onSuccess"
True - I, the Cordova-based developer, am not sure how this "feature" works - I
need to have end-user's IDs married up with his/her device tokens. Perhaps that
happens auto-magically with UPS?
My helloworld efforts did not get into this specific use case.
> On Feb 26, 2014, at 3:41 PM, Burr Sutter <bsutter(a)redhat.com> wrote:
>
> 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.
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
5:26 a.m.
On Wed, Feb 26, 2014 at 10:40 AM, Erik Jan de Wit <edewit(a)redhat.com> wrote:
Hi,
As you may have experienced or seen the cordova push plugin is not always
simple to get started with, there are still some things that are platform
specific even though compared to the 'original' it has improved there is
room for improvement. Here are some suggestions to make it even simpler:
Right now the API looks like this:
var pushConfig = {
// 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>"}
//badge and sound are iOS specific, and ignored on Androidpush.register(successHandler,
errorHandler, {"badge": "true", "sound": "true",
"ecb": "onNotification", pushConfig: pushConfig});
Suggestion number one, is to remove the successHandler and use that as the
callback for notifications:
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.
I like the idea of passing in a function (instead of a string), for the
notification handling.
However, the successHandler was meant to give feedback if registration w/
UPS was successful or not. Should we really remove that hook ?
For iOS we have these badge and sound flags we could we get rid of
those
as well?
yes, good point. Internally we set the to true; and if the message does not
contain sound/badge -> oh well :)
Good idea for simplification!
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:
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>"
});
looks really compact now
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.
It's optional on UPS, as only really Android clients need it. And I think
originally Luke just added the 'senderID' to UPS for having something handy
(copy/paste usage).
So, I am not sure on that one, as that means we now have to enforce Android
Variants always get the senderID attribute. Could be done, yes, but I am
not sure.
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.
-1
we should never 'deploy' the masterSecret and the applicationID on clients.
If that information is stolen (easy on devices), you can start sending
dirty assaults to ALL the devices for that application. Same w/ all the
different providers like Parse, Stackmob etc: they all use a
MasterKey/Password for the actual send. And they _highly_ recommend NOT
applying that to the clients (it's easy to leak that information)
-Matthias
If we do all of the above there will be no platform specific code at all
and the final script could look as simple as this:
push.register(function(event) {
alert(event.alert);
},
function(error) {
throw error;
}, {
pushServerURL: "<pushServerURL e.g http(s)//host:port/context >",
applicationID: "<applicationID e.g. 1234456-234320>",
secret: "<secret e.g. 1234456-234320>",
alias: "<alias e.g. a username or an email address optional>"
});
Push notifications in one statement for all devices :)
WDYT
Erik Jan
_______________________________________________
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
5:30 a.m.
On Wed, Feb 26, 2014 at 11:26 AM, Matthias Wessendorf <matzew(a)apache.org>wrote:
On Wed, Feb 26, 2014 at 10:40 AM, Erik Jan de Wit <edewit(a)redhat.com>wrote:
> Hi,
>
> As you may have experienced or seen the cordova push plugin is not always
> simple to get started with, there are still some things that are platform
> specific even though compared to the 'original' it has improved there is
> room for improvement. Here are some suggestions to make it even simpler:
>
> Right now the API looks like this:
>
> var pushConfig = {
> // 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>"}
> //badge and sound are iOS specific, and ignored on
Androidpush.register(successHandler, errorHandler, {"badge": "true",
"sound": "true",
> "ecb": "onNotification", pushConfig: pushConfig});
>
> Suggestion number one, is to remove the successHandler and use that as
> the callback for notifications:
>
> 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.
>
I like the idea of passing in a function (instead of a string), for the
notification handling.
However, the successHandler was meant to give feedback if registration w/
UPS was successful or not. Should we really remove that hook ?
yes, we can: since error tells the app: something went wrong (with
registration). So pretty much good enough to only have that one. If that is
not invoked: well registration must have been successful :-)
> For iOS we have these badge and sound flags we could we get rid of those
> as well?
>
yes, good point. Internally we set the to true; and if the message does
not contain sound/badge -> oh well :)
Good idea for simplification!
> 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:
>
> 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>"
> });
>
> looks really compact now
> 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.
>
It's optional on UPS, as only really Android clients need it. And I think
originally Luke just added the 'senderID' to UPS for having something handy
(copy/paste usage).
So, I am not sure on that one, as that means we now have to enforce
Android Variants always get the senderID attribute. Could be done, yes, but
I am not sure.
>
> 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.
>
-1
we should never 'deploy' the masterSecret and the applicationID on
clients. If that information is stolen (easy on devices), you can start
sending dirty assaults to ALL the devices for that application. Same w/ all
the different providers like Parse, Stackmob etc: they all use a
MasterKey/Password for the actual send. And they _highly_ recommend NOT
applying that to the clients (it's easy to leak that information)
-Matthias
>
> If we do all of the above there will be no platform specific code at all
> and the final script could look as simple as this:
>
> push.register(function(event) {
> alert(event.alert);
> },
> function(error) {
> throw error;
> }, {
> pushServerURL: "<pushServerURL e.g http(s)//host:port/context
>",
> applicationID: "<applicationID e.g. 1234456-234320>",
> secret: "<secret e.g. 1234456-234320>",
> alias: "<alias e.g. a username or an email address optional>"
> });
>
>
> Push notifications in one statement for all devices :)
>
> WDYT
> Erik Jan
>
> _______________________________________________
> 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
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
5:38 a.m.
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.
I like the idea of passing in a function (instead of a string), for the notification
handling.
However, the successHandler was meant to give feedback if registration w/ UPS was
successful or not. Should we really remove that hook ?
Well you still will get that feedback, errorHandler will be invoked when it wan’t
successful
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.
It's optional on UPS, as only really Android clients need it. And I think originally
Luke just added the 'senderID' to UPS for having something handy (copy/paste
usage).
So, I am not sure on that one, as that means we now have to enforce Android Variants
always get the senderID attribute. Could be done, yes, but I am not sure.
Hmm, right it’s optional then this maybe not the greatest idea
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.
-1
we should never 'deploy' the masterSecret and the applicationID on clients. If
that information is stolen (easy on devices), you can start sending dirty assaults to ALL
the devices for that application. Same w/ all the different providers like Parse, Stackmob
etc: they all use a MasterKey/Password for the actual send. And they _highly_ recommend
NOT applying that to the clients (it's easy to leak that information)
Right didn’t think about that, this together with the objections that Sebastien has makes
this a definite no go.
5:39 a.m.
On Wed, Feb 26, 2014 at 11:38 AM, Erik Jan de Wit <edewit(a)redhat.com> wrote:
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.
>
I like the idea of passing in a function (instead of a string), for the
notification handling.
However, the successHandler was meant to give feedback if registration w/
UPS was successful or not. Should we really remove that hook ?
Well you still will get that feedback, errorHandler will be invoked when
it wan't successful
:-) figured that out after I sent my first mail :)))
> 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.
>
It's optional on UPS, as only really Android clients need it. And I think
originally Luke just added the 'senderID' to UPS for having something handy
(copy/paste usage).
So, I am not sure on that one, as that means we now have to enforce
Android Variants always get the senderID attribute. Could be done, yes, but
I am not sure.
Hmm, right it's optional then this maybe not the greatest idea
> 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.
>
-1
we should never 'deploy' the masterSecret and the applicationID on
clients. If that information is stolen (easy on devices), you can start
sending dirty assaults to ALL the devices for that application. Same w/ all
the different providers like Parse, Stackmob etc: they all use a
MasterKey/Password for the actual send. And they _highly_ recommend NOT
applying that to the clients (it's easy to leak that information)
Right didn't think about that, this together with the objections that
Sebastien has makes this a definite no go.
_______________________________________________
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
6:03 a.m.
Envoyé de mon iPhone
Le Feb 26, 2014 à 11:39, Matthias Wessendorf <matzew(a)apache.org> a écrit :
On Wed, Feb 26, 2014 at 11:38 AM, Erik Jan de Wit <edewit(a)redhat.com> wrote:
> 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.
>
>
> I like the idea of passing in a function (instead of a string), for the notification
handling.
>
> However, the successHandler was meant to give feedback if registration w/ UPS was
successful or not. Should we really remove that hook ?
Well you still will get that feedback, errorHandler will be invoked when it wan’t
successful
:-) figured that out after I sent my first mail :)))
Ok , having just the error
callback make sense, let's try that !
>
> 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.
>
> It's optional on UPS, as only really Android clients need it. And I think
originally Luke just added the 'senderID' to UPS for having something handy
(copy/paste usage).
>
> So, I am not sure on that one, as that means we now have to enforce Android Variants
always get the senderID attribute. Could be done, yes, but I am not sure.
>
Hmm, right it’s optional then this maybe not the greatest idea
>
> 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.
>
> -1
>
> we should never 'deploy' the masterSecret and the applicationID on clients.
If that information is stolen (easy on devices), you can start sending dirty assaults to
ALL the devices for that application. Same w/ all the different providers like Parse,
Stackmob etc: they all use a MasterKey/Password for the actual send. And they _highly_
recommend NOT applying that to the clients (it's easy to leak that information)
>
Right didn’t think about that, this together with the objections that Sebastien has makes
this a definite no go.
_______________________________________________
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
3:40 a.m.
Hi,
I was still thinking about those 2 last points (last night while baking pancakes) it seems
that we can’t make it optimal. So I would propose to do something like this:
push.register(function(event) {
alert(event.alert);
},
function(error) {
throw error;
}, {
pushServerURL: "<pushServerURL e.g http(s)//host:port/context >",
alias: "<alias e.g. a username or an email address optional>",
android: {
senderID: "<senderID e.g Google Project ID only for android>",
variantID: "<variantID e.g. 1234456-234320>",
variantSecret: "<variantSecret e.g. 1234456-234320>",
},
ios: {
variantID: "<variantID e.g. 1234456-234320>",
variantSecret: "<variantSecret e.g. 1234456-234320>",
}
});
Instead of leaving it to the user to find some sort of way to deal with the 2 variants we
supply him with a way to configure both. On iOS the plugin will use the iOS part of the
config and on android the android part plus a generic part.
And if you cordova app is only for one device maybe we could support this as well:
push.register(function(event) {
alert(event.alert);
},
function(error) {
throw error;
}, {
pushServerURL: "<pushServerURL e.g http(s)//host:port/context >",
alias: "<alias e.g. a username or an email address optional>",
senderID: "<senderID e.g Google Project ID only for android>",
variantID: "<variantID e.g. 1234456-234320>",
variantSecret: "<variantSecret e.g. 1234456-234320>"
});
This will just take the variantID and secret that are on the ‘root’ level regardless of
the device type, so it would only work on one. But maybe this will confuse people again.
WDYT,
Erik Jan
>
> 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.
>
> It's optional on UPS, as only really Android clients need it. And I think
originally Luke just added the 'senderID' to UPS for having something handy
(copy/paste usage).
>
> So, I am not sure on that one, as that means we now have to enforce Android Variants
always get the senderID attribute. Could be done, yes, but I am not sure.
>
Hmm, right it’s optional then this maybe not the greatest idea
>
> 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.
>
> -1
>
> we should never 'deploy' the masterSecret and the applicationID on clients.
If that information is stolen (easy on devices), you can start sending dirty assaults to
ALL the devices for that application. Same w/ all the different providers like Parse,
Stackmob etc: they all use a MasterKey/Password for the actual send. And they _highly_
recommend NOT applying that to the clients (it's easy to leak that information)
>
Right didn’t think about that, this together with the objections that Sebastien has makes
this a definite no go.
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
4:06 a.m.
On Thu, Feb 27, 2014 at 9:40 AM, Erik Jan de Wit <edewit(a)redhat.com> wrote:
Hi,
I was still thinking about those 2 last points (last night while baking
pancakes) it seems that we can't make it optimal. So I would propose to do
something like this:
push.register(function(event) {
alert(event.alert);
},
function(error) {
throw error;
}, {
pushServerURL: "<pushServerURL e.g http(s)//host:port/context >",
alias: "<alias e.g. a username or an email address optional>",
android: {
senderID: "<senderID e.g Google Project ID only for android>",
variantID: "<variantID e.g. 1234456-234320>",
variantSecret: "<variantSecret e.g. 1234456-234320>",
},
ios: {
variantID: "<variantID e.g. 1234456-234320>",
variantSecret: "<variantSecret e.g. 1234456-234320>",
}
});
Instead of leaving it to the user to find some sort of way to deal with
the 2 variants we supply him with a way to configure both. On iOS the
plugin will use the iOS part of the config and on android the android part
plus a generic part.
I like that but again, what if you have more than 1 variant for the ios
platform for instance. iPad free and iPhone Premium, what will I specify
here ?
And if you cordova app is only for one device maybe we could support this
as well:
push.register(function(event) {
alert(event.alert);
},
function(error) {
throw error;
}, {
pushServerURL: "<pushServerURL e.g http(s)//host:port/context >",
alias: "<alias e.g. a username or an email address optional>",
senderID: "<senderID e.g Google Project ID only for android>",
variantID: "<variantID e.g. 1234456-234320>",
variantSecret: "<variantSecret e.g. 1234456-234320>"
});
This will just take the variantID and secret that are on the 'root' level
regardless of the device type, so it would only work on one. But maybe this
will confuse people again.
WDYT,
Erik Jan
> 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.
>
It's optional on UPS, as only really Android clients need it. And I think
originally Luke just added the 'senderID' to UPS for having something handy
(copy/paste usage).
So, I am not sure on that one, as that means we now have to enforce
Android Variants always get the senderID attribute. Could be done, yes, but
I am not sure.
Hmm, right it's optional then this maybe not the greatest idea
> 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.
>
-1
we should never 'deploy' the masterSecret and the applicationID on
clients. If that information is stolen (easy on devices), you can start
sending dirty assaults to ALL the devices for that application. Same w/ all
the different providers like Parse, Stackmob etc: they all use a
MasterKey/Password for the actual send. And they _highly_ recommend NOT
applying that to the clients (it's easy to leak that information)
Right didn't think about that, this together with the objections that
Sebastien has makes this a definite no go.
_______________________________________________
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
4:12 a.m.
I like that but again, what if you have more than 1 variant for the ios platform for
instance. iPad free and iPhone Premium, what will I specify here ?
Well I would assume that one wouldn’t create a free version of an app using the same code,
but rather have 2 code basis one is the free app and one the paid one and both are cordova
apps using one app section under UPS. Does that make sense?
4:17 a.m.
On Thu, Feb 27, 2014 at 10:12 AM, Erik Jan de Wit <edewit(a)redhat.com> wrote:
>
> I like that but again, what if you have more than 1 variant for the ios
platform for instance. iPad free and iPhone Premium, what will I specify
here ?
Well I would assume that one wouldn't create a free version of an app
using the same code, but rather have 2 code basis one is the free app and
one the paid one and both are cordova apps using one app section under UPS.
Does that make sense?
Yeah :) You're right that make sense.
I was thinking of cases where people use the same code base/app even for
free or premium but even with that the "current" plugin can not deal with
it and the developer will have to customize that.
So yeah I'm +1 ,as long we can support the "generic" case as you showed .
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
5:33 a.m.
On Thu, Feb 27, 2014 at 9:40 AM, Erik Jan de Wit <edewit(a)redhat.com> wrote:
Hi,
I was still thinking about those 2 last points (last night while baking
pancakes) it seems that we can't make it optimal. So I would propose to do
something like this:
push.register(function(event) {
alert(event.alert);
},
function(error) {
throw error;
}, {
pushServerURL: "<pushServerURL e.g http(s)//host:port/context >",
alias: "<alias e.g. a username or an email address optional>",
android: {
senderID: "<senderID e.g Google Project ID only for android>",
variantID: "<variantID e.g. 1234456-234320>",
variantSecret: "<variantSecret e.g. 1234456-234320>",
},
ios: {
variantID: "<variantID e.g. 1234456-234320>",
variantSecret: "<variantSecret e.g. 1234456-234320>",
}
});
Instead of leaving it to the user to find some sort of way to deal with
the 2 variants we supply him with a way to configure both. On iOS the
plugin will use the iOS part of the config and on android the android part
plus a generic part.
I like that android/iOS config object!
And if you cordova app is only for one device maybe we could support this
as well:
push.register(function(event) {
alert(event.alert);
},
function(error) {
throw error;
}, {
pushServerURL: "<pushServerURL e.g http(s)//host:port/context >",
alias: "<alias e.g. a username or an email address optional>",
senderID: "<senderID e.g Google Project ID only for android>",
variantID: "<variantID e.g. 1234456-234320>",
variantSecret: "<variantSecret e.g. 1234456-234320>"
});
This will just take the variantID and secret that are on the 'root' level
regardless of the device type, so it would only work on one. But maybe this
will confuse people again.
perhaps :)
WDYT,
Erik Jan
> 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.
>
It's optional on UPS, as only really Android clients need it. And I think
originally Luke just added the 'senderID' to UPS for having something handy
(copy/paste usage).
So, I am not sure on that one, as that means we now have to enforce
Android Variants always get the senderID attribute. Could be done, yes, but
I am not sure.
Hmm, right it's optional then this maybe not the greatest idea
> 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.
>
-1
we should never 'deploy' the masterSecret and the applicationID on
clients. If that information is stolen (easy on devices), you can start
sending dirty assaults to ALL the devices for that application. Same w/ all
the different providers like Parse, Stackmob etc: they all use a
MasterKey/Password for the actual send. And they _highly_ recommend NOT
applying that to the clients (it's easy to leak that information)
Right didn't think about that, this together with the objections that
Sebastien has makes this a definite no go.
_______________________________________________
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
8:04 a.m.
On Feb 28, 2014, at 5:33 AM, Matthias Wessendorf <matzew(a)apache.org> wrote:
On Thu, Feb 27, 2014 at 9:40 AM, Erik Jan de Wit <edewit(a)redhat.com> wrote:
Hi,
I was still thinking about those 2 last points (last night while baking pancakes) it
seems that we can’t make it optimal. So I would propose to do something like this:
push.register(function(event) {
alert(event.alert);
},
function(error) {
throw error;
}, {
pushServerURL: "<pushServerURL e.g http(s)//host:port/context >",
alias: "<alias e.g. a username or an email address optional>",
android: {
senderID: "<senderID e.g Google Project ID only for android>",
variantID: "<variantID e.g. 1234456-234320>",
variantSecret: "<variantSecret e.g. 1234456-234320>",
},
ios: {
variantID: "<variantID e.g. 1234456-234320>",
variantSecret: "<variantSecret e.g. 1234456-234320>",
}
});
Instead of leaving it to the user to find some sort of way to deal with the 2 variants we
supply him with a way to configure both. On iOS the plugin will use the iOS part of the
config and on android the android part plus a generic part.
I like that android/iOS config object!
I like this better as well, verse having to
put in a if then else block based on mobile OS, which is error prone.
Question about the JS syntax above - it looks odd to have the configuration object below
the function(error), I assume I could have declared the config object above and used it as
a parameter to push.register(). When JS gets too creatively away from old school (e.g.
Java 1.5) syntax it tends to throw me off. :-)
How else could the block above be written to look more "straightforward"?
keeping in mind that our average user is a Struts/SpringMVC kind of developer.
And if you cordova app is only for one device maybe we could support this as well:
push.register(function(event) {
alert(event.alert);
},
function(error) {
throw error;
}, {
pushServerURL: "<pushServerURL e.g http(s)//host:port/context >",
alias: "<alias e.g. a username or an email address optional>",
senderID: "<senderID e.g Google Project ID only for android>",
variantID: "<variantID e.g. 1234456-234320>",
variantSecret: "<variantSecret e.g. 1234456-234320>"
});
This will just take the variantID and secret that are on the ‘root’ level regardless of
the device type, so it would only work on one. But maybe this will confuse people again.
perhaps :)
WDYT,
Erik Jan
>>
>> 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.
>>
>> It's optional on UPS, as only really Android clients need it. And I think
originally Luke just added the 'senderID' to UPS for having something handy
(copy/paste usage).
>>
>> So, I am not sure on that one, as that means we now have to enforce Android
Variants always get the senderID attribute. Could be done, yes, but I am not sure.
>>
>
> Hmm, right it’s optional then this maybe not the greatest idea
>
>>
>> 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.
>>
>> -1
>>
>> we should never 'deploy' the masterSecret and the applicationID on
clients. If that information is stolen (easy on devices), you can start sending dirty
assaults to ALL the devices for that application. Same w/ all the different providers like
Parse, Stackmob etc: they all use a MasterKey/Password for the actual send. And they
_highly_ recommend NOT applying that to the clients (it's easy to leak that
information)
>>
>
> Right didn’t think about that, this together with the objections that Sebastien has
makes this a definite no go.
>
>
> _______________________________________________
> 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
8:59 a.m.
I like this better as well, verse having to put in a if then else
block based on mobile OS, which is error prone.
Question about the JS syntax above - it looks odd to have the configuration object below
the function(error), I assume I could have declared the config object above and used it as
a parameter to push.register(). When JS gets too creatively away from old school (e.g.
Java 1.5) syntax it tends to throw me off. :-)
How else could the block above be written to look more "straightforward"?
keeping in mind that our average user is a Struts/SpringMVC kind of developer.
Of course we still can make it look like that, this is the same example but then without
everything inlined still our average user will have to get used that we are referencing
function ‘pointers’ here
var pushConfig = {
pushServerURL: "<pushServerURL e.g http(s)//host:port/context >",
alias: "<alias e.g. a username or an email address optional>",
android: {
senderID: "<senderID e.g Google Project ID only for android>",
variantID: "<variantID e.g. 1234456-234320>",
variantSecret: "<variantSecret e.g. 1234456-234320>"
},
ios: {
variantID: "<variantID e.g. 1234456-234320>",
variantSecret: "<variantSecret e.g. 1234456-234320>"
}
};
push.register(onNotification, errorHandler, pushConfig);
function onNotification(event) {
alert(event.alert);
}
function errorHandler(error) {
throw error;
}
9:11 a.m.
+1 ;-)
Em 28/02/2014 13:59, "Erik Jan de Wit" <edewit(a)redhat.com> escreveu:
I like this better as well, verse having to put in a if then else
block
based on mobile OS, which is error prone.
Question about the JS syntax above - it looks odd to have the
configuration object below the function(error), I assume I could have
declared the config object above and used it as a parameter to
push.register(). When JS gets too creatively away from old school (e.g.
Java 1.5) syntax it tends to throw me off. :-)
How else could the block above be written to look more "straightforward"?
keeping in mind that our average user is a Struts/SpringMVC kind of
developer.
Of course we still can make it look like that, this is the same example
but then without everything inlined still our average user will have to get
used that we are referencing function ‘pointers’ here
var pushConfig = {
pushServerURL: "<pushServerURL e.g http(s)//host:port/context >",
alias: "<alias e.g. a username or an email address optional>",
android: {
senderID: "<senderID e.g Google Project ID only for android>",
variantID: "<variantID e.g. 1234456-234320>",
variantSecret: "<variantSecret e.g. 1234456-234320>"
},
ios: {
variantID: "<variantID e.g. 1234456-234320>",
variantSecret: "<variantSecret e.g. 1234456-234320>"
}
};
push.register(onNotification, errorHandler, pushConfig);
function onNotification(event) {
alert(event.alert);
}
function errorHandler(error) {
throw error;
}
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
12:48 p.m.
On Feb 28, 2014, at 8:59 AM, Erik Jan de Wit <edewit(a)redhat.com> wrote:
> I like this better as well, verse having to put in a if then else
block based on mobile OS, which is error prone.
>
> Question about the JS syntax above - it looks odd to have the configuration object
below the function(error), I assume I could have declared the config object above and used
it as a parameter to push.register(). When JS gets too creatively away from old school
(e.g. Java 1.5) syntax it tends to throw me off. :-)
>
> How else could the block above be written to look more "straightforward"?
keeping in mind that our average user is a Struts/SpringMVC kind of developer.
Of course we still can make it look like that, this is the same example but then without
everything inlined still our average user will have to get used that we are referencing
function ‘pointers’ here
This is much more readable for me!
var pushConfig = {
pushServerURL: "<pushServerURL e.g http(s)//host:port/context >",
alias: "<alias e.g. a username or an email address optional>",
android: {
senderID: "<senderID e.g Google Project ID only for android>",
variantID: "<variantID e.g. 1234456-234320>",
variantSecret: "<variantSecret e.g. 1234456-234320>"
},
ios: {
variantID: "<variantID e.g. 1234456-234320>",
variantSecret: "<variantSecret e.g. 1234456-234320>"
}
};
push.register(onNotification, errorHandler, pushConfig);
function onNotification(event) {
alert(event.alert);
}
function errorHandler(error) {
throw error;
}
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
5:41 a.m.
On Fri, Feb 28, 2014 at 2:59 PM, Erik Jan de Wit <edewit(a)redhat.com> wrote:
Of course we still can make it look like that, this is the same example but
then without everything inlined still our average user will have to
get
used that we are referencing function 'pointers' here
var pushConfig = {
pushServerURL: "<pushServerURL e.g http(s)//host:port/context >",
alias: "<alias e.g. a username or an email address optional>",
android: {
senderID: "<senderID e.g Google Project ID only for android>",
variantID: "<variantID e.g. 1234456-234320>",
variantSecret: "<variantSecret e.g. 1234456-234320>"
},
ios: {
variantID: "<variantID e.g. 1234456-234320>",
variantSecret: "<variantSecret e.g. 1234456-234320>"
}
};
push.register(onNotification, errorHandler, pushConfig);
function onNotification(event) {
alert(event.alert);
}
function errorHandler(error) {
throw error;
}
This is the last version of the API ?
_______________________________________________
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
5:59 a.m.
This is the last version of the API ?
Yes see https://github.com/aerogear/aerogear-pushplugin-cordova/pull/17 for more details
_______________________________________________
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
11:02 p.m.
The only catch that I see with breaking out the attributes is that for new
device types (aka Windows, Amazon, some new xyz), a code change here will be
needed. I like not having to check the device type in my code in order to
populate the config. I guess depending on the added device, you might have
to add unique attributes anyway.
--
View this message in context:
http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-cordova-push-plugi...
Sent from the aerogear-dev mailing list archive at Nabble.com.
3:45 a.m.
Hi,
Currently the plugin supports only one set of varaintId and secret and if you want to
create an application for android and iOS you would have logic like
if (device.platform == ‘android’) {
variantId = "<variantID for android>";
} else {
variantId = "<variantID for iOS>";
}
so with this grouping you don’t have to have this if else logic anymore as you can just
add them in the config like so:
var pushConfig = {
pushServerURL: "<pushServerURL e.g http(s)//host:port/context >",
alias: "<alias e.g. a username or an email address optional>",
android: {
senderID: "<senderID e.g Google Project ID only for android>",
variantID: "<variantID e.g. 1234456-234320>",
variantSecret: "<variantSecret e.g. 1234456-234320>"
},
ios: {
variantID: "<variantID e.g. 1234456-234320>",
variantSecret: "<variantSecret e.g. 1234456-234320>"
}
};
And when a windows phone is added you’ll still have to change the code to add the
variantId for windows. As we don’t have a way to register for the application only for the
variant this is the compromise.
Cheers,
Erik Jan
6:39 a.m.
Good point. I hate having to do device checks.
On Mar 13, 2014, at 2:46 AM, "Erik Jan de Wit [via
aerogear-dev]" <ml-node+s1069024n6769h66(a)n5.nabble.com> wrote:
Hi,
Currently the plugin supports only one set of varaintId and secret and if you want to
create an application for android and iOS you would have logic like
if (device.platform == ‘android’) {
variantId = "<variantID for android>";
} else {
variantId = "<variantID for iOS>";
}
so with this grouping you don’t have to have this if else logic anymore as you can just
add them in the config like so:
var pushConfig = {
pushServerURL: "<pushServerURL e.g http(s)//host:port/context >",
alias: "<alias e.g. a username or an email address optional>",
android: {
senderID: "<senderID e.g Google Project ID only for android>",
variantID: "<variantID e.g. 1234456-234320>",
variantSecret: "<variantSecret e.g. 1234456-234320>"
},
ios: {
variantID: "<variantID e.g. 1234456-234320>",
variantSecret: "<variantSecret e.g. 1234456-234320>"
}
};
And when a windows phone is added you’ll still have to change the code to add the
variantId for windows. As we don’t have a way to register for the application only for the
variant this is the compromise.
Cheers,
Erik Jan
_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
If you reply to this email, your message will be added to the discussion below:
http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-cordova-push-plugi...
To unsubscribe from [aerogear-dev] cordova push plugin simplification, click here.
NAML
--
View this message in context:
http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-cordova-push-plugi...
Sent from the aerogear-dev mailing list archive at Nabble.com.
3695
days inactive
3710
days old
30 comments
8 participants
participants (8)
-
Bruno Oliveira -
Burr Sutter -
Erik Jan de Wit -
keithdmoore94 -
Matthias Wessendorf -
Miguel Lemos -
Sebastien Blanc -
Sébastien Blanc