I do an application design for a soft real-time software application now.
The application will probably need to notify its mobile users about some events in the system. An event can happen during a 15-minute time frame which starts after the user's first interaction with the system. The event notification should be done in soft real-time: if a user notified later than 15-20 seconds he was supposed to be notified, then it is critical. Basically, I need to notify a mobile user about an event no later than 15-20 seconds after that event happens during a 15-minutes time frame.
I plan to do that with some kind of PUSH technology (XMPP/Jabber, native app with Comet connection or maybe PUSH email).
Unfortunately, the most obvious solution which is to have mobile web-site (example: http://www.lightstreamer.com/) with real-time push notifications is not suitable, because in that case the user will have to stare at the screen during all the 15-minute time frame. Notifying a user with a sound or a vibration would be a much more pleasant user experience (connect to the system via smartphone -> start interaction with the system -> put the smartphone back into the pocket or a bag -> get notified).
I have done a simple experiment by sending Jabber chat messages between my laptop (WiFi/100Mbit) and my Android smartphone (GPRS/3G). The thing is that some of the messages sent to the smartphone are late (it takes about 1 minute until they arrive at the smartphone) or just lost (they never arrive at the smartphone). Moreover, I have noticed that the Jabber client at the smartphone goes offline regularly for a few seconds. I do not know if it is because I have a very cheap Android smartphone or because the 3G connection is not very good, but this behaviour is not acceptable for the software application that I design.
Thus, I am interested in the following:
is there any technology standard that can guarantee pushed message delivery to mobile (GPRS/3G) consumers in soft real-time? I.e. a technology standard which guarantees that a mobile client will be notified no later than N seconds from now;
do you know any examples of mobile apps which have soft real-time push notifications?
what are the ways to address the issue of delivering/pushing soft real-time messages to mobile devices in soft real-time? (e.g. keep sending the same message until the mobile device confirms the receipt of the message)
P.S. The intended use of the software application is with any smartphone, be it iPhone, Android, WP or any other internet-connected smartphone.
Note: This question is similar to one of my previous questions, but this one is about on a completely different use-case with strong focus on soft real-time requirements.
I know that this question is 3 years old but it doesn't have any answer.
A PUSH notification is always Best Effort. It means that the server will do it's best to deliver it but can not guarantee that it will be done on time or if it will be delivered at all.
Never rely on PUSH notifications to achieve a critical job.
Related
How to reduce the time it takes a FCM to reach user's phone, which is not influenced by any restrictions like doze or task killers.
it can be particularly bad for signaling voip calls which firebase doesn't support natively (unlike apple's Pushkit).
I see some voip apps tend to maintain a socket for that, but i've seen that sockets usually don't last with some vendor's task killers
I'm working on a voice recognition app that connects to custom hardware using a bluetooth handsfree profile (HFP aka headset profile) connection. The application is used to pass PCM audio data to a cloud based voice recognition server, by leveraging the Android AudioRecord class. This functionality works fine if the application initiates the SCO connection, but if the headset hardware initiates the SCO connection, by issuing the AT+BVRA HFP command to the phone, Google Assistant always hijacks the phone. Thus, my question is how can I stop this? Is there a way to programmatically tell Google Assistant to chill? I've tried many different things (AudioManager sco management, AudioRouting preferred connection, BluetoothHeadset profile class, Java Reflection & View.setAssitBlocked(true), etc...), but none of them seem able to either block Google Assistant or recapture the SCO connection. (It also seems that the handset opens up an A2DP for google assistant's audio feed). I'm hoping this is possible with a Java based solution... ?
As noted by another answer, what is likely happening is that Android is broadcasting an ACTION_VOICE_COMMAND intent, and since Google Assistant is set up to receive it, it gets priority on the connection. Your app could register for the intent and see if it gets priority on receiving it.
I am not seeing anything in the docs (Alexa Skills Kit or Alexa Voice Service) about adjusting the time that the device waits for a command after the "wake word" (default: "Alexa") has been uttered. I was wondering if I could adjust it and how to do so, preferably programmatically.
Is it possible? How so?
This is part of the hardware device behavior. So it cannot be done via the SDKs.
The underlying service, Alexa, doesn't support the concept of a wake word. In fact, it is against the terms and conditions of people using AVS to enable hardware devices to use a wake word without explicit permission from Amazon. So it isn't the sort of thing you would expect to see available programmatically.
The same goes for the other constants that govern how the hardware reacts such as the timeout in waiting for the service to respond, how long it waits for the user to say something before a reprompt, or how long it waits after the reprompt before hanging up.
Ever since the introduction of push services in IOS I wonder how it works.
From what I found out the push function is basically an open connection that does not close serverside.
But mobiles are connecting at different points of the internet, the only way for a server to know where the mobile is connected is when the mobile tells the server where that it has changed location.
I read something about polling a connection so it stays open.
What advantage is there to manage and keep a changing open connection alive vs just checking if something is to pull?
Internally yes, push is implemented by having your phone poll for new data. The thing that makes push notifications attractive is that they are routed over Apple's service and that has many advantages.
From the phone's point of view, it only has to poll from one service, which means it can conserve bandwidth and piggyback on the normal operations of keeping a cellphone online. That means a lot less battery is used, and you can do things like set your phone to only receive push notifications every half hour, which means that 29 minutes out of every half hour you can turn off the data connection.
From the server's point of view, you no longer need to cache messages or provide quality-of-service guarantees. If you want to send a push notification to a phone that's out of range of a cell-tower for a few minutes, you may need to store the message for a considerable amount of time until the phone comes back online. Apple handles all this for you, and lets your server just be in charge of creating notifications, not storing and relaying them.
I have to devise a push notification plan for some mobile devices where push is not yet officially supported by C2DM / APNS / BES ,etc. MQTT was also a good option but I could not get an MQTT Client for my required platform. (Blackberry Playbook, ActionScript only)
Going back to basics, I had the options of Long Polling and streaming. Streaming using a high keep-alive value seems good to me, as the development of the mobile app (it is not a browser) and the server code are both in my control. To maintain the connection open, I just need to ping the server occasionally.
What issues I may be facing in this approach ? I understand this would constantly open an HTTP connection from the device to the server. Would the battery life of mobile device drain quickly just by persistently opening a server connection ? ...Afterall the data is not being transferred, just by keeping the connection open...right ?
You might want to consider Urban Airship or take a look at this realtime technologies guide.
If realtime really matters, I'm talking about seconds or milliseconds, then a realtime web technology using WebSockets or HTTP Streaming is your best option as they deliver updates the instant they are available. This sort of thing is best suited to the sort of application that a user is actively using during a reasonable period of time where they need instant notifications or are collaborating/chatting with others.
WebSockets are probably a better standard to be using with longer term technology considerations in mind since they are the first standard for full duplex bi-directional communication between a client (mobile, web, desktop) and server.
What platform could you not find an MQTT client for? http://mqtt.org/software lists clients in just about every language I can think of and more than I'd like to bother using. The mosquitto C client library is very portable.
For battery life, it really depends what you're doing between the keepalives...
If you app runs in a country where the network isn't in the best shape, then having all your clients keep a connection open can put strain on their infrastructure (assuming you are that popular).
Battery life is the other consideration, yes, a lot of devices aren't that efficient in keeping an idle radio/3g connection open and it drains the battery a lot faster than not having a connection open.