Found some SO Q&A about how to send and receive USSD messages (exchanged with the cellular network) on Android. I understand that one needs to register a BroadcastListener to receive USSD message, but have further questions (so far, admittedly theoretical i.e. without having attempted to write code for this).
On Android it is possible (and if so what are the specific things to take care of) so that my application gets to receive the USSD message from cellular network, even though it is not the foreground application, and even though the screen is locked, or when the device is in sleep-mode ?
From what I have read so far, it seem that I'd need a background service that registers the BroadcastListener for USSD message, that can then send a local Notification, to wake up the application which can offer UI for interaction with user. Is that correct ?
Note that the desired behaviour is somewhat analogous to GCM/FCM Notification being used to wake-up an application from sleep (post user interaction responding to the Notification). However, in this case there is no GCM/FCM, but only USSD message from the network.
USSD transaction (Sending and Receiving) is not yet supported on android app, you can follow the issue in google bug tracker: https://issuetracker.google.com/issues/36905980
and also similar question was asked Call (and get the response for) a USSD Code, in the background?
Related
I am developing a VoIP application with SIP as the signaling protocol. I have implemented the messaging and calling functions and they work when the app is in the foreground. To make the app listen to the call and message receiving when it is closed, I created a foreground notification so that the app would always be in the foreground.
The problem is that the above method consumes a lot of power which is unacceptable. I have also noted that famous VoIP applications like WhatsApp and Signal are not using foreground notifications but, they manage to inform us about incoming calls/messages no matter the app is closed. I wonder how to achieve the same functionality. Could anybody please point me in the right direction?
This kind of App should use Push Notifications (reference: https://firebase.google.com/docs/cloud-messaging) that use ONE SINGLE socket connection for the whole system: each App should register itself for receiving Push, then when the Server triggers (many languages are supported by FCM with examples/tutorials) the Calling Event then a special "message" is sent to the App (providing some information about IP or whatever you want) that gets those information and acts in the proper way.
Unfortunately FCM, after few thousand notification per month, requires payment.
There are other similar online service, but those services requires a fee because they should handle many users connected at the same time and it requires hardwar and bandwidth.
What I'm trying to ask is:
Whether these apps are relying on FCM/GCM (or any other type of) push notifications for syncing their data or are they using a socket connection in background through a service?
If they are relying on push notifications then why they don't have any loss in receiving notifications (in background) while I miss 10-15% of notifications in busy hours.
And if they are relying on a socket connection in background, then
ain't this eat battery like a dinosaur?
What I have found is that if I force stop Messenger and Facebook I still receive messages but somewhat late than usual.
Plus there is an option of 'Allow background activity' in Messenger, Facebook, Slack and Skype, which when I disable, I can't receive a notification at all.
Interesting this is that WhatsApp don't have this kinda option in its app info and If I just force stop WhatsApp it simply stops showing me message notifications.
Whether these apps are relying on FCM/GCM (or any other type of) push
notifications for syncing their data or are they using a socket
connection in background through a service?
They must be relying on FCM.
If they are relying on push notifications then why they don't have any
loss in receiving notifications (in background) while I miss 10-15% of
notifications in busy hours.
They must be using FCM high priority which are reliably delivered in doze mode.
And if they are relying on a socket connection in background, then
ain't this eat battery like a dinosaur?
They might not be running CPU intensive work.
Mobile applications like Whatsapp must be requesting permission to exempt them from Doze/battery saving and App standby mode. you can refer to my answer here for more details.
Adding on to Sagar answer.
1)Never show the notification from FCM notification payload unless required.
2)Once High priority FCM received you can do network operations for sometime and fetch data from server and then show up. If it fails whatsapp do puts ups with special msg.
https://www.quora.com/Why-do-I-get-You-may-have-new-messages-notification-on-WhatsApp
3)use foreground service/ cpu lock tied with app icon momentarily till the data is fetched ,later close it.
PS:No whatsapp do not request for Battery Optimization. they probably reply on FCM high-priority message.
Well I have no idea what EXACTLY are they doing in background (maybe no one has), but lets take a look at the concept.
In distributed systems and web applications, no one usually goes for push notification system in background for their services to talk to each other. While it is possible, but these alive services have better options to choose such as publisher/subscriber pattern and technologies that bring this service for us (ex: reddis, MQ, Nats.io), they are high available and with no single point of failure, and the data is still synced over all server.
Your second question starts with an if which might have a false result. But lets say they do. You should never compare your "client to server connections and logic" with "Server to server connections and logic". What I mean is maybe they use Reddis pub/sub service, it doesn't mean their client should use same system to connect to server. It has a big cost to keep those servers connections alive while supporting big numbers of messages to sync.
And about third question. No, socket connections don't always drain battery. It really depends on how you use them. You can check for sockets idle modes too.
Also, systems like firebase might be still be able to send notifications when an application is not running or not connected to server. Happened to me a lot of times in Telegram, when government of Iran has blocked it but I could still receive notifications. Its whole other story, I think you can find more about it with a little search.
PS: Please avoid asking too many questions at once. thanks.
For services which exchanging frequently messages like messenger, WhatsApp, and WeChat etc there are message brokers (Activemq Artemis, RabbitMQ, Kafka etc) which is running on the server and having active stomp connection with each client app. This broker forward the message to the respective client as it received, and if the client is not online then it hold the message in memory untill the client become online. For further details that how a message broker works visit the official website of my favorite Activemq Artemis docs.
Can Pusher messages be received on Android/iOS app when the app is closed or the phone is turned off?
What i expect to happen...
When phone is on & app is on, it's pretty straight forward from the Pusher docs on how to react to pusher messages sent to the app.
When phone is on & app is closed, the phone should receive a notification that something has been sent to the app.
When phone is turned off, a notification should be received by the phone when it's turned back on to notify that something has been sent to the app.
Are these even possible? If yes, what are some suggestions to lookout for? If no, what can be some workaround?
When an application using Pusher moves into the background on iOS and Android the connection to Pusher will likely stay active for a few minutes. But eventually that connection will be closed. You can't stop that happening within your application (although there may be a "hack" around stating your app is a Voice app when submitting to the Apps store).
Therefore, you should monitor your application moving to the background and put a fallback in place to delivery messages to the phone when it's not connected.
Please see How get pusher events when the iOS app go to the background? for libPusher (the Pusher iOS library).
Here's an extract from the Android Processes & Threads Lifecycle docs on a "Service Process":
A process that is running a service that has been started with the startService() method and does not fall into either of the two higher categories. Although service processes are not directly tied to anything the user sees, they are generally doing things that the user cares about (such as playing music in the background or downloading data on the network), so the system keeps them running unless there's not enough memory to retain them along with all foreground and visible processes.
So, running a Pusher instance in such a thread is a viable option.
However, there will still be occasions where the user goes offline. In that situation your server you can detect if a user is online by querying the Pusher HTTP API or by using WebHooks where your server can be instantly informed if the user has gone offline or come back online.
Using the mechanisms above you can facilitate smart notifications; if the user is online (the app is in the foreground) then send the message to them by Pusher, if they are offline (the app is in the background) then use an alternative mechanism for delivery (native Push Notification, SMS or email).
I'm creating video chat (like skype, but for a specific type of companies) apps for Android and iOS using Xamarin. I'm wondering what the best approach is to handle the server to client communication, specifically when a call is coming, how do I fast and reliably contact the receiver ie client phone?
I want to be able to contact my App even if it is closed
I need to know if the message have gone through
It has to be fast, preferably under 1 second
I've read about push notification and they can wake my app, but they are slow and no guarantee they will get through.
I've been looking into SignalR which are fast and reliable, but I can't quite see how to open my app.
Currently I'm thinking about setting a status wether or not the app is open. If it's open I'll use signalR else the caller will be asked if he wants to notify the receiver about the incoming call. Does anyone have better idea?
can anyone help me to intercept the incoming Flash messages (specially the ones from the telecom company, where they send our current balance after some activity like message sent).
My application deals with sending SMSes in bulk and I don't want the flash message popping now and then. So is it possible on Android ?
EDIT: Everyone says its not possible above Android 1.6 but I found a similar App on Google Play but I want the source of that kind of App. Please Help.
Edit: More than a year has passed and still I didnt got the solution. Can anyone help to resolve this thread..??
Might depend on the channel [of communication] used by your service provider. I guess they don't use SMS, probably they use WAP/PUSH or some pre-installed provider app for the notifications, which makes this harder to block. If it was SMS, you'd definitely have lots of ways to block their notifications, but in this case, I doubt there might be an easy / direct way to do this.
Flight Mode should ideally block telco / service-provider messages / notifications, but then this also blocks your connectivity, right? So, am not so certain on this one. Isn't there a way to opt-out of service provider notifications, maybe via a ussd routine? I've heard of this once...
Flash sms it is the same as usual sms except data coding flags. It has "class 0" indication in DCS.
For details about sms coding see: GSM 3.38 specification / 4 SMS Data Coding Scheme.
Some fragment from spec about it
When a mobile terminated message is class 0 and the MS has the capability of displaying short messages, the MS shall display the message immediately and send an acknowledgement to the SC when the message has successfully reached the MS irrespective of whether there is memory available in the SIM or ME. The message shall not be automatically stored in the SIM or ME.
So, in most cases, phone just displays this message and skips usual chain of actions.
Probably, you can't catch this message with usual API... probably you need deep hook and rooted device.
[Or may be just switch off this service by calling customer support?]