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

Matthias Wessendorf matzew at apache.org
Wed Nov 25 08:02:10 EST 2015


On Wed, Nov 25, 2015 at 1:30 PM, Rob Willett <rob.aerogear at robertwillett.com
> 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 matzew at apache.org
> wrote:
>
> On Wed, Nov 25, 2015 at 10:14 AM, Rob Willett <
> rob.aerogear at robertwillett.com> 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
> Aerogear-users at lists.jboss.org
> 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
> Aerogear-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-users
>
> --
> Cheers,
> Erik Jan
> ------------------------------
>
> Aerogear-users mailing list
> Aerogear-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-users
>
>
> _______________________________________________
> Aerogear-users mailing list
> Aerogear-users at lists.jboss.org
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-users/attachments/20151125/ee5bf94a/attachment.html 


More information about the Aerogear-users mailing list