I have an Android app, instant messaging is one of the key features. For implementing the IM feature, we use our push server based on websocket.
For my app, I have a PushService, in this service, I establish a websocket connection which connects to the push server and receive push message.
The code works well when app in foreground (i.e.: works well while user plays with the app), but when the app doesn't in foreground, it stop receiving push messages after a while (about 1 minute). Same issue when user turns off screen.
I have set a repeat task with AlarmManager, which checks the websocket connection status, if it is not in connected status, then re-try to connect so as to back to normal to receive push messages.
This works well below Android M, for example on the Android 5 phones, it seldom misses push messages. But on Android M / Android N, it doesn't work as good as on Android 5.x. I can confirm the service itself is keep running , check from the 'Running services'.
I've noticed that starts from Android M, Android introduces Doze and Standby mode, not sure if they are related, if yes, how can I make the app continue to work again? On my phone the WeChat and Skype Android App work well, what's the mechanism behind it? I know FCM is the best solution, but I cannot use that for customers in China, so I need a workaround.
Edit: I had proposed to use a foreground service but PM doesn't like the notification tray always being shown in the status bar he wants to keep it clean.
Any advice will be appreciated!
I don't know about WeChat or Skype communication, but i know the WhatsApp using you own service notification with the same tecnology of FCM.
They using the Jaber server with implements the XMPP communication protocols
link
Related
For devices that don't have Google Play Services, there are a few options to be able to receive push notifications.
Those options can be Baidu in China, Pushy, Facebook own push notifications, etc.
But I cannot understand how is that even possible to overcome those two main problems :
Since we cannot have an "SDK" of some sort like the Google Play Service on a device-level, our only option is to integrate it on an app-level. This means, we cannot have one socket connection to the push server that would be mutual for all apps, like the GCM does. Instead, we need to have as many socket connections alive as the number of apps installed.
Even if we close an eye on problem number 1, to make that connection survive Doze and App Standby, we would have to handle them in a Foreground Service, which is the only way to guarantee its running even after killing the app, or when the device enters Doze state.
But how come we don't see the notification of a foreground service in the notification bar in Chinese phones, or apps that use Pushy for example?
Are they simply polling the push server periodically? with AlarmManager (marked with setAndAllowWhileIdle) and a BroadcastReceiver ? that would be too resource-heavy and inefficient.
Goal
Create a long-running background service with a network connection, similar to Zello app.
Problem
Starting with API level 26 (Oreo), there're tight restrictions on background services and their network activity.
Looking at the Zello app which has a constantly running background service which is able to accept audio and text messages even if the device is sleeping, I wonder how they achieved that?
Their service is not running on the foreground. Also, it doesn't look like they use push messages for that, since the app works quite stable in conditions where there's a problem with push messages reception (e.g. low-end Xiaomi phones).
Any ideas would be appreciated.
From what I gathered these apps use the Firebase Cloud messaging service:
https://firebase.google.com/docs/cloud-messaging/
The Firebase Service is embedded in the Android system and maintains a constant network connection to the firebase server. The apps then contact the firebase server which in turn to notifies the destination device.
Advantages:
The Android system is responsible of keeping the server connection alive and running
The network load is minimized because one connection is used for all apps using the firebase service.
Disadvantages:
All data is sent through the firebase server and is therefore (in theory) directly accessible by Google
Depedning on how many devices use your app, you need to pay for the service.
A similar question asked might be helpful in tackling the problem too:
How does push notification technology work on Android?
These apps don't have long-running services with constant network connections. They use push notifications. When there is a new message for a user, the server sends a push notification to wake the device up.
I am from Apple world, so I don't have much experience with Android.
But what I am looking is a way that Android devices receive push notification, without using any third party servers. Notification need to be standard Android notification (look and feel)
The reason I need this is, because I would need this in a room that does not have access to outer world. (can't connect to any server) But I have my own WiFi so users can receive push notification from my server via my wifi.
I know that on iOS this is not possible, what about Android?
it is possible using Service left running in system (background) after app exit. some samples HERE, you should be interested in START_STICKY flag
you have to keep some connection (socket?) or interval requesting (not so well, but possible) inside your Service. Google Services (including Firebase) does that by itself and "redeliver" received push messages to properly declared (in manifest) app
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 am creating a app in android 4.0.3 i.e ICS version, which connects to the server when client gets login into the app.I am trying to get status of an client when he gets online or offline through server & seen onto the app screen.I am unable to proceed. Can anyone say me:
Is it possible to get the status of an user through server?
1-- How to proceed for first step...?
2-- How should I get a response from the server that the client is connected & viewed to other client example - when we login into skype our status shows available with green radio button, In same way how can I get it.?
It ll be very help full, If anybody guide me.
Many Thanks..
I'm assuming you're trying to develop a chat app ?
If this is the case, try using an XMPP library. XMPP is widely used for chat apps, including Facebook chat (and Google talk I think) and there are plenty of open source libraries available.
Otherwise, if you only want real-time notifications as a part of a bigger picture, try using push notifications. Google supports Cloud to Device Messaging (C2DM) for android. It allows to have push notifications to a specific device without you having to deal with persistent connections, battery and CPU use .etc.
C2DM approach comes down to this. When a client connects to your server, get a list of his friends and their 'C2DM IDs' and fire a C2DM push to their devices. This push is delivered to your app, and you can respond to it by firing a notification, or update UI .etc. (Your app doesn't necessarily have to be running. Push notification is delivered via a specific broadcast, and your app can register a receiver for it to wake up.)
Keep in mind that there is a quota for C2DM messages per device, per app and also a limit for the payload per message. So you're not supposed to send massive files via this. Just a notification to your app, so it can call your server and get an updated list, instead of polling.
You can get more info on C2DM and code samples here. https://developers.google.com/android/c2dm/
Hope this helps.
You may have moved on, but I'm posting for anyone who would run into this one in the future.
Firebase is a good solution to use in this scenario, if the app is always running when you want communication to happen. (It will not wake up your app as C2DM/CDM does, unless you have a service running all the time and still wouldn't wake up if the device is asleep... AFAIK)
It may be useful for some scenarios, but may be not for a chat app as you want the device to wake up when a message arrives.
Note that they have limitations on the free subscription though.