7:02 a.m.
On Wed, Nov 25, 2015 at 1:30 PM, Rob Willett <rob.aerogear(a)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/#_i...
>
> On Wed, Nov 25, 2015 at 11:07 AM, Matthias Wessendorf matzew(a)apache.org
wrote:
>
> On Wed, Nov 25, 2015 at 10:14 AM, Rob Willett <
> rob.aerogear(a)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(a)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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-users
>
> --
> Cheers,
> Erik Jan
> ------------------------------
>
> Aerogear-users mailing list
> Aerogear-users(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-users
>
>
> _______________________________________________
> Aerogear-users mailing list
> Aerogear-users(a)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