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

Wed Nov 25 08:17:29 EST 2015

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 
>> 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
> _______________________________________________
> Aerogear-users mailing list
> Aerogear-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-users