[Aerogear-users] Unified Push Server - Anyway to delete notifications when in background?

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

[Aerogear-users] Unified Push Server - Anyway to delete notifications when in background?

Rob Willett
Hi,

We’ve got the Unified Push Server working on the OpenShift platform.
No real issues once we’d understood the point of aliases.

We can send notifications quite happily and see whats going on. We use
Perl for our backend servers and so we wrote a small Perl interface. If
anybody wants the code for the Perl interface let me know and we’ll
pass it on. We can’t claim a lot of credit for a simple piece of code
:)

Anyway, one of edge use-cases would be to delete notification or set of
notifications when the app is running but in the background on iOS.

We want to do this as the user can receive a high number of
notifications (> 10) when the app is in the background. Notifications
come in groups and provide traffic updates, so a user may get a new
group of 3-4 traffic updates, this new group completely supersedes ANY
previous update. Our data is valuable when fresh and useless when over
10 minutes old.

Whilst we can simply ignore old notifications, UX testing has shown the
users don’t like having old notifications sitting round. We know that
the users can delete them individually or delete the lot from the
notification drawer OR can simply bring the app out of the background
BUT they don’t like doing that.

So what we want to do is delete old notifications, we were hoping for
the ability to call a JavaScript function with say a parameter to
identify notifications by a group or something, but we could accept
deleting the lot and inserting local notifications instead.

We know that we can send content-available and have stuff pulled from a
server in the background. This option is quite difficult for us and has
some complexity identifying when the app is not started up. The simplest
option is delete some or all of the notifications.

Does anybody know if this is possible or any other suggestions?

Thanks

Rob
_______________________________________________
Aerogear-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-users
Reply | Threaded
Open this post in threaded view
|

Re: [Aerogear-users] Unified Push Server - Anyway to delete notifications when in background?

Matthias Wessendorf


On Wed, Nov 25, 2015 at 10:14 AM, Rob Willett <[hidden email]> wrote:
Hi,

We’ve got the Unified Push Server working on the OpenShift platform.
No real issues once we’d understood the point of aliases.

We can send notifications quite happily and see whats going on. We use
Perl for our backend servers and so we wrote a small Perl interface. If
anybody wants the code for the Perl interface let me know and we’ll
pass it on. We can’t claim a lot of credit for a simple piece of code
:)

sure, I think that would be awesome, if you could publish it on github.
We will promote if for other perl users! 
 

Anyway, one of edge use-cases would be to delete notification or set of
notifications when the app is running but in the background on iOS.

We want to do this as the user can receive a high number of
notifications (> 10) when the app is in the background. Notifications
come in groups and provide traffic updates, so a user may get a new
group of 3-4 traffic updates, this new group completely supersedes ANY
previous update. Our data is valuable when fresh and useless when over
10 minutes old.

Whilst we can simply ignore old notifications, UX testing has shown the
users don’t like having old notifications sitting round. We know that
the users can delete them individually or delete the lot from the
notification drawer OR can simply bring the app out of the background
BUT they don’t like doing that.

So what we want to do is delete old notifications, we were hoping for
the ability to call a JavaScript function with say a parameter to
identify notifications by a group or something, but we could accept
deleting the lot and inserting local notifications instead.

We know that we can send content-available and have stuff pulled from a
server in the background. This option is quite difficult for us and has
some complexity identifying when the app is not started up. The simplest
option is delete some or all of the notifications.

Does anybody know if this is possible or any other suggestions?

I think that's an interesting idea. Erik Jan recently did an update for message, on Cordova, to actually stack em:

Perhaps we could have a 'delete' feature too. Mind filing a JIRA against: https://issues.jboss.org/projects/AGCORDOVA
(you need to have an account in order create tickets)

Cheers!
Matthias
 

Thanks

Rob
_______________________________________________
Aerogear-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-users



--

_______________________________________________
Aerogear-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-users
Reply | Threaded
Open this post in threaded view
|

Re: [Aerogear-users] Unified Push Server - Anyway to delete notifications when in background?

Erik Jan de Wit
Hi Rob,

Like Matthias already told you on Android managing notifications and changing how they look is much simpler then on iOS. On iOS you can cancel all the remote notifications, but not some.

Corrine had this idea: send your notifications as 'background notifications' (e.g. 'content-available' flag set) then your app will be notified, but nothing will show up in the Notification area. You can use local notifications to create the notification in the notification area, because these you can cancel. You decide how they show up and even group them. The cordova plugin to create local notifications is called 'cordova-plugin-local-notifications' [1]

So you will have to deal with the complexities of background notifications for this to work, but to determine if the app is in the foreground when the background notification arrives there is a boolean on the notification to help [2]

Although I must advise you sending large volumes of messages might not be a great way to use push notifications, it's meant to inform the user that something important has happened it should be personal and engage the users. Users could also opt to turn off the push notifications so you can't use it to transfer data.

Hope this helps


On Wed, Nov 25, 2015 at 11:07 AM, Matthias Wessendorf <[hidden email]> wrote:


On Wed, Nov 25, 2015 at 10:14 AM, Rob Willett <[hidden email]> wrote:
Hi,

We’ve got the Unified Push Server working on the OpenShift platform.
No real issues once we’d understood the point of aliases.

We can send notifications quite happily and see whats going on. We use
Perl for our backend servers and so we wrote a small Perl interface. If
anybody wants the code for the Perl interface let me know and we’ll
pass it on. We can’t claim a lot of credit for a simple piece of code
:)

sure, I think that would be awesome, if you could publish it on github.
We will promote if for other perl users! 
 

Anyway, one of edge use-cases would be to delete notification or set of
notifications when the app is running but in the background on iOS.

We want to do this as the user can receive a high number of
notifications (> 10) when the app is in the background. Notifications
come in groups and provide traffic updates, so a user may get a new
group of 3-4 traffic updates, this new group completely supersedes ANY
previous update. Our data is valuable when fresh and useless when over
10 minutes old.

Whilst we can simply ignore old notifications, UX testing has shown the
users don’t like having old notifications sitting round. We know that
the users can delete them individually or delete the lot from the
notification drawer OR can simply bring the app out of the background
BUT they don’t like doing that.

So what we want to do is delete old notifications, we were hoping for
the ability to call a JavaScript function with say a parameter to
identify notifications by a group or something, but we could accept
deleting the lot and inserting local notifications instead.

We know that we can send content-available and have stuff pulled from a
server in the background. This option is quite difficult for us and has
some complexity identifying when the app is not started up. The simplest
option is delete some or all of the notifications.

Does anybody know if this is possible or any other suggestions?

I think that's an interesting idea. Erik Jan recently did an update for message, on Cordova, to actually stack em:

Perhaps we could have a 'delete' feature too. Mind filing a JIRA against: https://issues.jboss.org/projects/AGCORDOVA
(you need to have an account in order create tickets)

Cheers!
Matthias
 

Thanks

Rob
_______________________________________________
Aerogear-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-users



--

_______________________________________________
Aerogear-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-users




--
Cheers,
       Erik Jan

_______________________________________________
Aerogear-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-users
Reply | Threaded
Open this post in threaded view
|

Re: [Aerogear-users] Unified Push Server - Anyway to delete notifications when in background?

Rob Willett
In reply to this post by Matthias Wessendorf

Matthias,

Thanks for the prompt and helpful reply.

We had a quick look at the stacking, as expected it seems to be for Android (which is no surprise at all). I am not an expert on iOS (or anything else) but as far as I know, stacking is impossible on iOS. We’re spending more and more time on getting the notifications right, its turned out to be significantly more complicated than we thought and one of the areas where we have two distinct lines of code in our Cordova app.

I’ll raise JIRA for our ideas and let people ponder on that. In the last three weeks, we’ve tried four biggish vendors for Push notifications and we’ve had issues with all of them. Amazon, Parse, Urban Airship, OneSignal. Some are money issues (thats always the way), some are incredibly inflexible (Amazon), some don’t handle content-available, some don’t really support Cordova. Its been hardwork and we really, really want UPS to work for us. We’re tired of testing notifications on yet another system :)

I’ll put in on github but the code is pretty simple so I’ll put it here as well as we’re not big users off github and it might takes us a while to work it out. We’re rather old-school and like Emacs, Perl and dead simple stuff like that. We’ll try and work it out though

Best wisher,

Rob

This is untested code as-is, we just pulled it straight out the testing file. We know it works in our system but I haven’t tested this simplified version. The github one will be tested though.

#!/usr/bin/perl -w

use strict;
use warnings;
use Net::Curl::Easy qw(/^CURLOPT_.*/);
use JSON;

sub SendAeroGearNotification
{
    my ($url , $username , $password , $config) = @_;
    my $curl = Net::Curl::Easy->new;
    my $json = JSON->new();
    my $response_body;

    my $json_string = $json->encode($config);

    print "json string $json_string\n";

    $curl->setopt( CURLOPT_URL, $url);
    $curl->setopt( CURLOPT_SSL_VERIFYHOST , 0);
    $curl->setopt( CURLOPT_SSL_VERIFYPEER , 0);

    $curl->setopt( CURLOPT_USERPWD , "$username:$password");
    $curl->setopt( CURLOPT_HTTPHEADER, ['Content-Type: application/json' ,
                                        'Accept: application/json']);
    $curl->setopt( CURLOPT_POST , 1);
    $curl->setopt( CURLOPT_POSTFIELDS , $json_string);

    $curl->setopt( CURLOPT_WRITEDATA , \$response_body);

    $curl->perform;
    print "AeroGear Reponse=".Dumper($response_body);
}

    my $notification_config = {
                 variants => [ “<<VARIANT ID>>“ ] ,
                 alias => [ “alias1” , “alias2” , “alias3” ] ,
                 ttl => 600 ,
                 message => {
                    alert => $contents ,
                     'content-available' => JSON::true ,
                     data => {
                        key1 => value1 , 
                        key2 => value2
                     }
                 }
             };

    SendAeroGearNotification("https://<<OPENSHIFT GEAR NAME>>.rhcloud.com/ag-push/rest/sender" ,
                             “<<USERNAME>>“ ,
                             “<<PASSWORD>>” , $notification_config);

On 25 Nov 2015, at 10:07, Matthias Wessendorf wrote:

On Wed, Nov 25, 2015 at 10:14 AM, Rob Willett <
[hidden email]> wrote:

Hi,

We’ve got the Unified Push Server working on the OpenShift platform.
No real issues once we’d understood the point of aliases.

We can send notifications quite happily and see whats going on. We use
Perl for our backend servers and so we wrote a small Perl interface. If
anybody wants the code for the Perl interface let me know and we’ll
pass it on. We can’t claim a lot of credit for a simple piece of code
:)

sure, I think that would be awesome, if you could publish it on github.
We will promote if for other perl users!

Anyway, one of edge use-cases would be to delete notification or set of
notifications when the app is running but in the background on iOS.

We want to do this as the user can receive a high number of
notifications (> 10) when the app is in the background. Notifications
come in groups and provide traffic updates, so a user may get a new
group of 3-4 traffic updates, this new group completely supersedes ANY
previous update. Our data is valuable when fresh and useless when over
10 minutes old.

Whilst we can simply ignore old notifications, UX testing has shown the
users don’t like having old notifications sitting round. We know that
the users can delete them individually or delete the lot from the
notification drawer OR can simply bring the app out of the background
BUT they don’t like doing that.

So what we want to do is delete old notifications, we were hoping for
the ability to call a JavaScript function with say a parameter to
identify notifications by a group or something, but we could accept
deleting the lot and inserting local notifications instead.

We know that we can send content-available and have stuff pulled from a
server in the background. This option is quite difficult for us and has
some complexity identifying when the app is not started up. The simplest
option is delete some or all of the notifications.

Does anybody know if this is possible or any other suggestions?

I think that's an interesting idea. Erik Jan recently did an update for
message, on Cordova, to actually stack em:
https://github.com/aerogear/aerogear-cordova-push/pull/81

Perhaps we could have a 'delete' feature too. Mind filing a JIRA against:
https://issues.jboss.org/projects/AGCORDOVA
(you need to have an account in order create tickets)

Cheers!
Matthias


_______________________________________________
Aerogear-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-users
Reply | Threaded
Open this post in threaded view
|

Re: [Aerogear-users] Unified Push Server - Anyway to delete notifications when in background?

Rob Willett
In reply to this post by Erik Jan de Wit

Erik,

Thanks for the thoughtful reply.

Great minds think alike :)

We have already worked through this as an option and it is probably the likeliest way forward for us. Indeed your notes and ours are almost identical.

You (or Corrine) have correctly identified the pitfalls regarding background and foreground. There is one other case and thats when the app is not actually started up. We still want to send them notifications (at least for a while) alerting them to traffic issues. After a day or so, we’ll throttle back these notifications but at least for a few hours or a day, we need to send them out. We can’t use the content-available flag as the app isn’t running (in either bg or fg) to handle the flag. So we have to try to work out if the app is ‘alive’ or not, if the app is not alive we send down full-fat notifications, this means no content-available flag and full information to be displayed in the notification drawer.

Our potential solution has us send out a single silent notification to everybody who needs to be sent one. The device segmentation to determine who gets information is already done by us. The payload for the silent notification is actually empty and its used as a signalling mechanism. This tells the app when it is in the fg or bg to phone home and get a specific payload for that user. When the app contacts the backend database to retrieve the payload, we flag the app as alive and working.

If we send out a silent notification but never get a response to get a payload, then we flag the app as not started. After every batch of silent notifications are sent, 60 secs later, we then do a second cycle looking at whether the devices have NOT responded. If the app has not responded then we move to full notifications for that device and don’t use content-available. Once the user clicks on a notification and starts the app up, we can see that and we move them into the ‘alive’ state, so next time we send silent notifications.

The process diagram is a lot simpler than my explanation :)

The other reason for sending a single silent notification with little information in and to get the app to respond to that single notification is quite subtle and appears on the surface to be counter intuitive. We could send down batches of notifications and so each device could receive 3-4 notifications. This would mean that since we cannot predict the order of the notifications or even if they arrive, we would have to constantly be sending data back to our server telling us that the app is alive. We would have 2-3 times the number of connections coming back in which need to be processed very quickly. Our system is quite bursty, nothing happens for 3-4 minutes and then all hell breaks lose as we have to manage everything in around 30 secs. Also we are relying on every notification getting through we would be sending a lot of data which you have correctly identified as potentially an issue as well.

We also looked at sending our highly specific payloads, i.e. each user getting one message but that one message has 3-4 notifications in it. This would mean we have to process, generate and send thousands of individual messages. We know we can generate the individual messages quite quickly, but the the network connection costs are too high (so we believe). Simply connecting to the servers, opening the connection, sending and tearing the connection down could take a long time (minutes?) for 5,000 users. We don’t want to spread the connection time out, we want the data to get to the user ASAP.

If your views are different on the time take not do this, I’d be interested in hearing them as we believe the connection time would be too long. Since we don’t have 5,000 users we can’t easily test our hypothesis.

Rob

On 25 Nov 2015, at 10:50, Erik Jan de Wit wrote:

Hi Rob,

Like Matthias already told you on Android managing notifications and
changing how they look is much simpler then on iOS. On iOS you can cancel
all the remote notifications, but not some.

Corrine had this idea: send your notifications as 'background
notifications' (e.g. 'content-available' flag set) then your app will be
notified, but nothing will show up in the Notification area. You can use
local notifications to create the notification in the notification area,
because these you can cancel. You decide how they show up and even group
them. The cordova plugin to create local notifications is called
'cordova-plugin-local-notifications' [1]

So you will have to deal with the complexities of background notifications
for this to work, but to determine if the app is in the foreground when the
background notification arrives there is a boolean on the notification to
help [2]

Although I must advise you sending large volumes of messages might not be a
great way to use push notifications, it's meant to inform the user that
something important has happened it should be personal and engage the
users. Users could also opt to turn off the push notifications so you can't
use it to transfer data.

Hope this helps

[1] https://github.com/katzer/cordova-plugin-local-notifications
[2]
https://aerogear.org/docs/guides/aerogear-cordova/AerogearCordovaPush/#_ios_background_notification

On Wed, Nov 25, 2015 at 11:07 AM, Matthias Wessendorf [hidden email]
wrote:

On Wed, Nov 25, 2015 at 10:14 AM, Rob Willett <
[hidden email]> wrote:

Hi,

We’ve got the Unified Push Server working on the OpenShift platform.
No real issues once we’d understood the point of aliases.

We can send notifications quite happily and see whats going on. We use
Perl for our backend servers and so we wrote a small Perl interface. If
anybody wants the code for the Perl interface let me know and we’ll
pass it on. We can’t claim a lot of credit for a simple piece of code
:)

sure, I think that would be awesome, if you could publish it on github.
We will promote if for other perl users!

Anyway, one of edge use-cases would be to delete notification or set of
notifications when the app is running but in the background on iOS.

We want to do this as the user can receive a high number of
notifications (> 10) when the app is in the background. Notifications
come in groups and provide traffic updates, so a user may get a new
group of 3-4 traffic updates, this new group completely supersedes ANY
previous update. Our data is valuable when fresh and useless when over
10 minutes old.

Whilst we can simply ignore old notifications, UX testing has shown the
users don’t like having old notifications sitting round. We know that
the users can delete them individually or delete the lot from the
notification drawer OR can simply bring the app out of the background
BUT they don’t like doing that.

So what we want to do is delete old notifications, we were hoping for
the ability to call a JavaScript function with say a parameter to
identify notifications by a group or something, but we could accept
deleting the lot and inserting local notifications instead.

We know that we can send content-available and have stuff pulled from a
server in the background. This option is quite difficult for us and has
some complexity identifying when the app is not started up. The simplest
option is delete some or all of the notifications.

Does anybody know if this is possible or any other suggestions?

I think that's an interesting idea. Erik Jan recently did an update for
message, on Cordova, to actually stack em:
https://github.com/aerogear/aerogear-cordova-push/pull/81

Perhaps we could have a 'delete' feature too. Mind filing a JIRA against:
https://issues.jboss.org/projects/AGCORDOVA
(you need to have an account in order create tickets)

Cheers!
Matthias

Thanks

Rob


Aerogear-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-users

--
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf


Aerogear-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-users

--
Cheers,
Erik Jan


Aerogear-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-users


_______________________________________________
Aerogear-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-users
Reply | Threaded
Open this post in threaded view
|

Re: [Aerogear-users] Unified Push Server - Anyway to delete notifications when in background?

Matthias Wessendorf


On Wed, Nov 25, 2015 at 1:30 PM, Rob Willett <[hidden email]> wrote:

Erik,

Thanks for the thoughtful reply.

Great minds think alike :)

We have already worked through this as an option and it is probably the likeliest way forward for us. Indeed your notes and ours are almost identical.

You (or Corrine) have correctly identified the pitfalls regarding background and foreground. There is one other case and thats when the app is not actually started up. We still want to send them notifications (at least for a while) alerting them to traffic issues. After a day or so, we’ll throttle back these notifications but at least for a few hours or a day, we need to send them out. We can’t use the content-available flag as the app isn’t running (in either bg or fg) to handle the flag. So we have to try to work out if the app is ‘alive’ or not, if the app is not alive we send down full-fat notifications, this means no content-available flag and full information to be displayed in the notification drawer.

Our potential solution has us send out a single silent notification to everybody who needs to be sent one. The device segmentation to determine who gets information is already done by us. The payload for the silent notification is actually empty and its used as a signalling mechanism. This tells the app when it is in the fg or bg to phone home and get a specific payload for that user. When the app contacts the backend database to retrieve the payload, we flag the app as alive and working.


when in background, on iOS you have a 30 second time window to fetch data from the backend. I'd use that to issue local notification, these are usually better to handle user interactions.
 

If we send out a silent notification but never get a response to get a payload, then we flag the app as not started. After every batch of silent notifications are sent, 60 secs later, we then do a second cycle looking at whether the devices have NOT responded. If the app has not responded then we move to full notifications for that device and don’t use content-available. Once the user clicks on a notification and starts the app up, we can see that and we move them into the ‘alive’ state, so next time we send silent notifications.


that's nice trick, I'd like that "engine" on the UPS :-) haha
 

The process diagram is a lot simpler than my explanation :)

The other reason for sending a single silent notification with little information in and to get the app to respond to that single notification is quite subtle and appears on the surface to be counter intuitive. We could send down batches of notifications and so each device could receive 3-4 notifications. This would mean that since we cannot predict the order of the notifications or even if they arrive, we would have to constantly be sending data back to our server telling us that the app is alive. We would have 2-3 times the number of connections coming back in which need to be processed very quickly. Our system is quite bursty, nothing happens for 3-4 minutes and then all hell breaks lose as we have to manage everything in around 30 secs. Also we are relying on every notification getting through we would be sending a lot of data which you have correctly identified as potentially an issue as well.


what are you doing when push notifications are disabled?
 

We also looked at sending our highly specific payloads, i.e. each user getting one message but that one message has 3-4 notifications in it. This would mean we have to process, generate and send thousands of individual messages. We know we can generate the individual messages quite quickly, but the the network connection costs are too high (so we believe). Simply connecting to the servers, opening the connection, sending and tearing the connection down could take a long time (minutes?) for 5,000 users. We don’t want to spread the connection time out, we want the data to get to the user ASAP.

yeah, I'd think so too, that sending a bunch of msgs might take sometime of HTTP traffic. Regarding getting info out ASAP, for apps that are alive (in fg), have you thought about using a TCP socket? I found this article interesting http://blog.layer.com/how-we-leverage-ios-push-notifications/ - worth a read.



 

If your views are different on the time take not do this, I’d be interested in hearing them as we believe the connection time would be too long. Since we don’t have 5,000 users we can’t easily test our hypothesis.

Rob

On 25 Nov 2015, at 10:50, Erik Jan de Wit wrote:

Hi Rob,

Like Matthias already told you on Android managing notifications and
changing how they look is much simpler then on iOS. On iOS you can cancel
all the remote notifications, but not some.

Corrine had this idea: send your notifications as 'background
notifications' (e.g. 'content-available' flag set) then your app will be
notified, but nothing will show up in the Notification area. You can use
local notifications to create the notification in the notification area,
because these you can cancel. You decide how they show up and even group
them. The cordova plugin to create local notifications is called
'cordova-plugin-local-notifications' [1]

So you will have to deal with the complexities of background notifications
for this to work, but to determine if the app is in the foreground when the
background notification arrives there is a boolean on the notification to
help [2]

Although I must advise you sending large volumes of messages might not be a
great way to use push notifications, it's meant to inform the user that
something important has happened it should be personal and engage the
users. Users could also opt to turn off the push notifications so you can't
use it to transfer data.

Hope this helps

[1] https://github.com/katzer/cordova-plugin-local-notifications
[2]
https://aerogear.org/docs/guides/aerogear-cordova/AerogearCordovaPush/#_ios_background_notification

On Wed, Nov 25, 2015 at 11:07 AM, Matthias Wessendorf [hidden email]
wrote:

On Wed, Nov 25, 2015 at 10:14 AM, Rob Willett <
[hidden email]> wrote:

Hi,

We’ve got the Unified Push Server working on the OpenShift platform.
No real issues once we’d understood the point of aliases.

We can send notifications quite happily and see whats going on. We use
Perl for our backend servers and so we wrote a small Perl interface. If
anybody wants the code for the Perl interface let me know and we’ll
pass it on. We can’t claim a lot of credit for a simple piece of code
:)

sure, I think that would be awesome, if you could publish it on github.
We will promote if for other perl users!

Anyway, one of edge use-cases would be to delete notification or set of
notifications when the app is running but in the background on iOS.

We want to do this as the user can receive a high number of
notifications (> 10) when the app is in the background. Notifications
come in groups and provide traffic updates, so a user may get a new
group of 3-4 traffic updates, this new group completely supersedes ANY
previous update. Our data is valuable when fresh and useless when over
10 minutes old.

Whilst we can simply ignore old notifications, UX testing has shown the
users don’t like having old notifications sitting round. We know that
the users can delete them individually or delete the lot from the
notification drawer OR can simply bring the app out of the background
BUT they don’t like doing that.

So what we want to do is delete old notifications, we were hoping for
the ability to call a JavaScript function with say a parameter to
identify notifications by a group or something, but we could accept
deleting the lot and inserting local notifications instead.

We know that we can send content-available and have stuff pulled from a
server in the background. This option is quite difficult for us and has
some complexity identifying when the app is not started up. The simplest
option is delete some or all of the notifications.

Does anybody know if this is possible or any other suggestions?

I think that's an interesting idea. Erik Jan recently did an update for
message, on Cordova, to actually stack em:
https://github.com/aerogear/aerogear-cordova-push/pull/81

Perhaps we could have a 'delete' feature too. Mind filing a JIRA against:
https://issues.jboss.org/projects/AGCORDOVA
(you need to have an account in order create tickets)

Cheers!
Matthias

Thanks

Rob


Aerogear-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-users

--
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf


Aerogear-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-users

--
Cheers,
Erik Jan


Aerogear-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-users


_______________________________________________
Aerogear-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-users




--

_______________________________________________
Aerogear-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-users
Reply | Threaded
Open this post in threaded view
|

Re: [Aerogear-users] Unified Push Server - Anyway to delete notifications when in background?

Matthias Wessendorf
In reply to this post by Rob Willett
Hi Rob

On Wed, Nov 25, 2015 at 1:00 PM, Rob Willett <[hidden email]> wrote:

Matthias,

Thanks for the prompt and helpful reply.

We had a quick look at the stacking, as expected it seems to be for Android (which is no surprise at all). I am not an expert on iOS (or anything else) but as far as I know, stacking is impossible on iOS. We’re spending more and more time on getting the notifications right, its turned out to be significantly more complicated than we thought and one of the areas where we have two distinct lines of code in our Cordova app.

I’ll raise JIRA for our ideas and let people ponder on that.


that would be awesome! We are happy to get anything into our SDKs and servers, if useful for our users!
 

In the last three weeks, we’ve tried four biggish vendors for Push notifications and we’ve had issues with all of them. Amazon, Parse, Urban Airship, OneSignal. Some are money issues (thats always the way), some are incredibly inflexible (Amazon), some don’t handle content-available, some don’t really support Cordova. Its been hardwork and we really, really want UPS to work for us. We’re tired of testing notifications on yet another system :)


Another benefit of the UPS is, that it's open-source. If you find the server (or the SDKs) not efficient for a specific task, we all can together work on it, and get it fixed
 

I’ll put in on github but the code is pretty simple so I’ll put it here as well as we’re not big users off github and it might takes us a while to work it out. We’re rather old-school and like Emacs, Perl and dead simple stuff like that. We’ll try and work it out though


If you need help, let us know!
 

Best wisher,

Rob

This is untested code as-is, we just pulled it straight out the testing file. We know it works in our system but I haven’t tested this simplified version. The github one will be tested though.

#!/usr/bin/perl -w

use strict;
use warnings;
use Net::Curl::Easy qw(/^CURLOPT_.*/);
use JSON;

sub SendAeroGearNotification
{
    my ($url , $username , $password , $config) = @_;
    my $curl = Net::Curl::Easy->new;
    my $json = JSON->new();
    my $response_body;

    my $json_string = $json->encode($config);

    print "json string $json_string\n";

    $curl->setopt( CURLOPT_URL, $url);
    $curl->setopt( CURLOPT_SSL_VERIFYHOST , 0);
    $curl->setopt( CURLOPT_SSL_VERIFYPEER , 0);

    $curl->setopt( CURLOPT_USERPWD , "$username:$password");
    $curl->setopt( CURLOPT_HTTPHEADER, ['Content-Type: application/json' ,
                                        'Accept: application/json']);
    $curl->setopt( CURLOPT_POST , 1);
    $curl->setopt( CURLOPT_POSTFIELDS , $json_string);

    $curl->setopt( CURLOPT_WRITEDATA , \$response_body);

    $curl->perform;
    print "AeroGear Reponse=".Dumper($response_body);
}

    my $notification_config = {
                 variants => [ “<<VARIANT ID>>“ ] ,
                 alias => [ “alias1” , “alias2” , “alias3” ] ,
                 ttl => 600 ,
                 message => {
                    alert => $contents ,
                     'content-available' => JSON::true ,
                     data => {
                        key1 => value1 , 
                        key2 => value2
                     }
                 }
             };

    SendAeroGearNotification("https://<<OPENSHIFT GEAR NAME>>.rhcloud.com/ag-push/rest/sender" ,
                             “<<USERNAME>>“ ,
                             “<<PASSWORD>>” , $notification_config);

On 25 Nov 2015, at 10:07, Matthias Wessendorf wrote:

On Wed, Nov 25, 2015 at 10:14 AM, Rob Willett <
[hidden email]> wrote:

Hi,

We’ve got the Unified Push Server working on the OpenShift platform.
No real issues once we’d understood the point of aliases.

We can send notifications quite happily and see whats going on. We use
Perl for our backend servers and so we wrote a small Perl interface. If
anybody wants the code for the Perl interface let me know and we’ll
pass it on. We can’t claim a lot of credit for a simple piece of code
:)

sure, I think that would be awesome, if you could publish it on github.
We will promote if for other perl users!

Anyway, one of edge use-cases would be to delete notification or set of
notifications when the app is running but in the background on iOS.

We want to do this as the user can receive a high number of
notifications (> 10) when the app is in the background. Notifications
come in groups and provide traffic updates, so a user may get a new
group of 3-4 traffic updates, this new group completely supersedes ANY
previous update. Our data is valuable when fresh and useless when over
10 minutes old.

Whilst we can simply ignore old notifications, UX testing has shown the
users don’t like having old notifications sitting round. We know that
the users can delete them individually or delete the lot from the
notification drawer OR can simply bring the app out of the background
BUT they don’t like doing that.

So what we want to do is delete old notifications, we were hoping for
the ability to call a JavaScript function with say a parameter to
identify notifications by a group or something, but we could accept
deleting the lot and inserting local notifications instead.

We know that we can send content-available and have stuff pulled from a
server in the background. This option is quite difficult for us and has
some complexity identifying when the app is not started up. The simplest
option is delete some or all of the notifications.

Does anybody know if this is possible or any other suggestions?

I think that's an interesting idea. Erik Jan recently did an update for
message, on Cordova, to actually stack em:
https://github.com/aerogear/aerogear-cordova-push/pull/81

Perhaps we could have a 'delete' feature too. Mind filing a JIRA against:
https://issues.jboss.org/projects/AGCORDOVA
(you need to have an account in order create tickets)

Cheers!
Matthias


_______________________________________________
Aerogear-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-users




--

_______________________________________________
Aerogear-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-users
Reply | Threaded
Open this post in threaded view
|

Re: [Aerogear-users] Unified Push Server - Anyway to delete notifications when in background?

Rob Willett
In reply to this post by Matthias Wessendorf
Matthias,

30 secs should be fine. We actually do very little processing, our data
movements are small.

On 25 Nov 2015, at 13:02, Matthias Wessendorf wrote:

>>
>>
>> Our potential solution has us send out a single silent notification
>> to
>> everybody who needs to be sent one. The device segmentation to
>> determine
>> who gets information is already done by us. The payload for the
>> silent
>> notification is actually empty and its used as a signalling
>> mechanism. This
>> tells the app when it is in the fg or bg to phone home and get a
>> specific
>> payload for that user. When the app contacts the backend database to
>> retrieve the payload, we flag the app as alive and working.
>>
>
> when in background, on iOS you have a 30 second time window to fetch
> data
> from the backend. I'd use that to issue local notification, these are
> usually better to handle user interactions.
>
>> we move to full notifications for that device and don’t use
>> content-available. Once the user clicks on a notification and starts
>> the
>> app up, we can see that and we move them into the ‘alive’ state,
>> so next
>> time we send silent notifications.
>>
>
> that's nice trick, I'd like that "engine" on the UPS :-) haha

Thats todays job.

>> Our system is quite bursty,
>> nothing happens for 3-4 minutes and then all hell breaks lose as we
>> have to
>> manage everything in around 30 secs. Also we are relying on every
>> notification getting through we would be sending a lot of data which
>> you
>> have correctly identified as potentially an issue as well.
>>
>
> what are you doing when push notifications are disabled?

Can’t do anything if they are disabled. Our app checks at startup if
they are disabled and requests that the user change to allow
notifications. Apple doesn’t allow apps that require or need
notifications. Our app works without notifications but if the user
doesn’t want to receive them, nothing we can do. Can’t orce the user
:)

>> We also looked at sending our highly specific payloads, i.e. each
>> user
>> getting one message but that one message has 3-4 notifications in it.
>> This
>> would mean we have to process, generate and send thousands of
>> individual
>> messages. We know we can generate the individual messages quite
>> quickly,
>> but the the network connection costs are too high (so we believe).
>> Simply
>> connecting to the servers, opening the connection, sending and
>> tearing the
>> connection down could take a long time (minutes?) for 5,000 users. We
>> don’t
>> want to spread the connection time out, we want the data to get to
>> the user
>> ASAP.
>>
> yeah, I'd think so too, that sending a bunch of msgs might take
> sometime of
> HTTP traffic. Regarding getting info out ASAP, for apps that are alive
> (in
> fg), have you thought about using a TCP socket? I found this article
> interesting
> http://blog.layer.com/how-we-leverage-ios-push-notifications/ -
> worth a read.
>

We hadn’t thought of that as we have been so focussed on
notifications. I’ve had a quick glance though the blog and it looks
interesting. I can see that LayerKit has identified similar issues as we
have already identified separately. The costs aren’t bad for what they
provide, though you have to immediately stump up a credit card if you
are in production. However they don’t appear to have a production
Cordova plugin or JavaScript SDK (yet).  There appears to be a early
access program though so we’ll look further into this.

Thanks for this, I have also raised a JIRA request, I can’t call it an
issue as its not :)

Rob

>
>
>
>
>> If your views are different on the time take not do this, I’d be
>> interested in hearing them as we believe the connection time would be
>> too
>> long. Since we don’t have 5,000 users we can’t easily test our
>> hypothesis.
>>
>> Rob
>>
>> On 25 Nov 2015, at 10:50, Erik Jan de Wit wrote:
>>
>> Hi Rob,
>>
>> Like Matthias already told you on Android managing notifications and
>> changing how they look is much simpler then on iOS. On iOS you can
>> cancel
>> all the remote notifications, but not some.
>>
>> Corrine had this idea: send your notifications as 'background
>> notifications' (e.g. 'content-available' flag set) then your app will
>> be
>> notified, but nothing will show up in the Notification area. You can
>> use
>> local notifications to create the notification in the notification
>> area,
>> because these you can cancel. You decide how they show up and even
>> group
>> them. The cordova plugin to create local notifications is called
>> 'cordova-plugin-local-notifications' [1]
>>
>> So you will have to deal with the complexities of background
>> notifications
>> for this to work, but to determine if the app is in the foreground
>> when the
>> background notification arrives there is a boolean on the
>> notification to
>> help [2]
>>
>> Although I must advise you sending large volumes of messages might
>> not be a
>> great way to use push notifications, it's meant to inform the user
>> that
>> something important has happened it should be personal and engage the
>> users. Users could also opt to turn off the push notifications so you
>> can't
>> use it to transfer data.
>>
>> Hope this helps
>>
>> [1] https://github.com/katzer/cordova-plugin-local-notifications
>> [2]
>>
>> https://aerogear.org/docs/guides/aerogear-cordova/AerogearCordovaPush/#_ios_background_notification
>>
>> On Wed, Nov 25, 2015 at 11:07 AM, Matthias Wessendorf
>> [hidden email]
>> wrote:
>>
>> On Wed, Nov 25, 2015 at 10:14 AM, Rob Willett <
>> [hidden email]> wrote:
>>
>> Hi,
>>
>> We’ve got the Unified Push Server working on the OpenShift
>> platform.
>> No real issues once we’d understood the point of aliases.
>>
>> We can send notifications quite happily and see whats going on. We
>> use
>> Perl for our backend servers and so we wrote a small Perl interface.
>> If
>> anybody wants the code for the Perl interface let me know and we’ll
>> pass it on. We can’t claim a lot of credit for a simple piece of
>> code
>> :)
>>
>> sure, I think that would be awesome, if you could publish it on
>> github.
>> We will promote if for other perl users!
>>
>> Anyway, one of edge use-cases would be to delete notification or set
>> of
>> notifications when the app is running but in the background on iOS.
>>
>> We want to do this as the user can receive a high number of
>> notifications (> 10) when the app is in the background. Notifications
>> come in groups and provide traffic updates, so a user may get a new
>> group of 3-4 traffic updates, this new group completely supersedes
>> ANY
>> previous update. Our data is valuable when fresh and useless when
>> over
>> 10 minutes old.
>>
>> Whilst we can simply ignore old notifications, UX testing has shown
>> the
>> users don’t like having old notifications sitting round. We know
>> that
>> the users can delete them individually or delete the lot from the
>> notification drawer OR can simply bring the app out of the background
>> BUT they don’t like doing that.
>>
>> So what we want to do is delete old notifications, we were hoping for
>> the ability to call a JavaScript function with say a parameter to
>> identify notifications by a group or something, but we could accept
>> deleting the lot and inserting local notifications instead.
>>
>> We know that we can send content-available and have stuff pulled from
>> a
>> server in the background. This option is quite difficult for us and
>> has
>> some complexity identifying when the app is not started up. The
>> simplest
>> option is delete some or all of the notifications.
>>
>> Does anybody know if this is possible or any other suggestions?
>>
>> I think that's an interesting idea. Erik Jan recently did an update
>> for
>> message, on Cordova, to actually stack em:
>> https://github.com/aerogear/aerogear-cordova-push/pull/81
>>
>> Perhaps we could have a 'delete' feature too. Mind filing a JIRA
>> against:
>> https://issues.jboss.org/projects/AGCORDOVA
>> (you need to have an account in order create tickets)
>>
>> Cheers!
>> Matthias
>>
>> Thanks
>>
>> Rob
>> ------------------------------
>>
>> Aerogear-users mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/aerogear-users
>>
>> --
>> Matthias Wessendorf
>>
>> blog: http://matthiaswessendorf.wordpress.com/
>> sessions: http://www.slideshare.net/mwessendorf
>> twitter: http://twitter.com/mwessendorf
>> ------------------------------
>>
>> Aerogear-users mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/aerogear-users
>>
>> --
>> Cheers,
>> Erik Jan
>> ------------------------------
>>
>> Aerogear-users mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/aerogear-users
>>
>>
>> _______________________________________________
>> Aerogear-users mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/aerogear-users
>>
>>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
> _______________________________________________
> Aerogear-users mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/aerogear-users

_______________________________________________
Aerogear-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-users
Reply | Threaded
Open this post in threaded view
|

Re: [Aerogear-users] Unified Push Server - Anyway to delete notifications when in background?

Erik Jan de Wit
In reply to this post by Rob Willett
Hi Rob,

You (or Corrine) have correctly identified the pitfalls regarding background and foreground. There is one other case and thats when the app is not actually started up. We still want to send them notifications (at least for a while) alerting them to traffic issues. After a day or so, we’ll throttle back these notifications but at least for a few hours or a day, we need to send them out. We can’t use the content-available flag as the app isn’t running (in either bg or fg) to handle the flag. So we have to try to work out if the app is ‘alive’ or not, if the app is not alive we send down full-fat notifications, this means no content-available flag and full information to be displayed in the notification drawer.

I think that when your app is not started the OS should start your app when the notification arrives, so that it can handle it. It could be that the app is not started because the device is low on power or there are some heuristics as to how often the app is used, that might come in play as well. But generally speaking a background notification should start the app as well.

_______________________________________________
Aerogear-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-users
Reply | Threaded
Open this post in threaded view
|

Re: [Aerogear-users] Unified Push Server - Anyway to delete notifications when in background?

Rob Willett
Erik,

Thats interesting. We hadn’t seen that happening at all. I
specifically tested this yesterday when testing UPS.

We’ll test again

Rob

On 25 Nov 2015, at 13:19, Erik Jan de Wit wrote:

> Hi Rob,
>
>> You (or Corrine) have correctly identified the pitfalls regarding
>> background and foreground. There is one other case and thats when the
>> app
>> is not actually started up. We still want to send them notifications
>> (at
>> least for a while) alerting them to traffic issues. After a day or
>> so,
>> we’ll throttle back these notifications but at least for a few
>> hours or a
>> day, we need to send them out. We can’t use the content-available
>> flag as
>> the app isn’t running (in either bg or fg) to handle the flag. So
>> we have
>> to try to work out if the app is ‘alive’ or not, if the app is
>> not alive we
>> send down full-fat notifications, this means no content-available
>> flag and
>> full information to be displayed in the notification drawer.
>>
> I think that when your app is not started the OS should start your app
> when
> the notification arrives, so that it can handle it. It could be that
> the
> app is not started because the device is low on power or there are
> some
> heuristics as to how often the app is used, that might come in play as
> well. But generally speaking a background notification should start
> the app
> as well.
> _______________________________________________
> Aerogear-users mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/aerogear-users
_______________________________________________
Aerogear-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-users
Reply | Threaded
Open this post in threaded view
|

Re: [Aerogear-users] Unified Push Server - Anyway to delete notifications when in background?

Rob Willett
In reply to this post by Matthias Wessendorf
Matthias,

We think we’ve published the Perl sample on gitgub
https://github.com/rwillett/AeroGear-UnifiedPush-Perl-Interface.

Please look and see if you can see it. Feel free to use it as you will.

Now we know how it works, we’ll upload other samples as we can an d
that people may find useful.

Any changes please let me know.

Rob.

On 25 Nov 2015, at 10:07, Matthias Wessendorf wrote:

> On Wed, Nov 25, 2015 at 10:14 AM, Rob Willett <
> [hidden email]> wrote:
>
>> Hi,
>>
>> We’ve got the Unified Push Server working on the OpenShift
>> platform.
>> No real issues once we’d understood the point of aliases.
>>
>> We can send notifications quite happily and see whats going on. We
>> use
>> Perl for our backend servers and so we wrote a small Perl interface.
>> If
>> anybody wants the code for the Perl interface let me know and we’ll
>> pass it on. We can’t claim a lot of credit for a simple piece of
>> code
>> :)
>>
>
> sure, I think that would be awesome, if you could publish it on
> github.
> We will promote if for other perl users!
>
>
>>
>> Anyway, one of edge use-cases would be to delete notification or set
>> of
>> notifications when the app is running but in the background on iOS.
>>
>> We want to do this as the user can receive a high number of
>> notifications (> 10) when the app is in the background. Notifications
>> come in groups and provide traffic updates, so a user may get a new
>> group of 3-4 traffic updates, this new group completely supersedes
>> ANY
>> previous update. Our data is valuable when fresh and useless when
>> over
>> 10 minutes old.
>>
>> Whilst we can simply ignore old notifications, UX testing has shown
>> the
>> users don’t like having old notifications sitting round. We know
>> that
>> the users can delete them individually or delete the lot from the
>> notification drawer OR can simply bring the app out of the background
>> BUT they don’t like doing that.
>>
>> So what we want to do is delete old notifications, we were hoping for
>> the ability to call a JavaScript function with say a parameter to
>> identify notifications by a group or something, but we could accept
>> deleting the lot and inserting local notifications instead.
>>
>> We know that we can send content-available and have stuff pulled from
>> a
>> server in the background. This option is quite difficult for us and
>> has
>> some complexity identifying when the app is not started up. The
>> simplest
>> option is delete some or all of the notifications.
>>
>> Does anybody know if this is possible or any other suggestions?
>>
>
> I think that's an interesting idea. Erik Jan recently did an update
> for
> message, on Cordova, to actually stack em:
> https://github.com/aerogear/aerogear-cordova-push/pull/81
>
> Perhaps we could have a 'delete' feature too. Mind filing a JIRA
> against:
> https://issues.jboss.org/projects/AGCORDOVA
> (you need to have an account in order create tickets)
>
> Cheers!
> Matthias
>
>
>>
>> Thanks
>>
>> Rob
>> _______________________________________________
>> Aerogear-users mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/aerogear-users
>>
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
> _______________________________________________
> Aerogear-users mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/aerogear-users
_______________________________________________
Aerogear-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-users