My app needs to be connected to a remote socket server in a background Service.
I need to "ALWAYS" run it in the background.
As already known - its imposible and not a good architectur to try and run a Service always because it will overload the system and system will kill it.
Can someone please advise on a way to still keep my service in a "listen" mode for push notification and still keep the socket connection alive using AlarmManager?
Related
I am using sockets for android real time push notifications, but the trouble is here, In android 8.0 or higher when app is killed , then socket is disconnected, however we achieved connection alive with foreground notification, but ideal user wont be happy with that, is there any solution so that I can run sockets in background or hide foreground notification ? (I dont want to use FCM notifications for some reasons), however I can use job schedulers or workers but there will be atleast 15minutes delay which is not real time
Using broadcast and service together are a good solution for your problem they can call and run even when your app killed
Just check the below link, I hope that it might help you :
How to keep a CountDownTimer running even if the app is closed?
https://stackoverflow.com/a/32028234/7485788
How to get data from the server when the Android app is closed when using the service and display in the notification
Example :
I'll design a program that communicates with the server every few seconds and displays the values received in the notification. Even when the program is closed or when the phone is turned on, it still has the information exchange server.
You can run a service using startForeground to prevent it from being killed.
However
A foreground service is a service that's considered to be something the user is actively aware of and thus not a candidate for the system to kill when low on memory.
But still if you just want to send a notification you can integrate firebase in your server to show the notifications.
Notifications can even be shown when the app is not running in the background.
Setting up firebase in your android application:
https://firebase.google.com/docs/cloud-messaging/android/client
Since the inception of Android Oreo, services are killed as soon as Application gets in background state. You could use Foreground Service to avoid getting killed but that will display a persistent notification to the user.
Going by your needs, I would suggest you to use WorkerManager. It will choose best JobScheduler for you, and can perform task repeatedly as per your needs.
I m actually developping an application in which I need my phone to be active even if it's locked.
Explanations
The applications connect to a remote nodejs server using socket.io. In that case, it cans sends realtime messages to a socket server that can handle this and make anything it needs. The fact is the socket management is in a service class (extends Service class).
The problem is that, when I lock the phone, the device stop to send heartbeat, and so is disconnected (by timeout) from the nodejs socket io server.
Actually, the normal behaviour of an android phone locked is to sleep. Meaning no activity.
Question
I was wondering how does others applications to be able to receive notifications, and so handling notif by a background service. it means that there's an activity even if the phone is sleeping right ?
How can I do to make this without draining a lot of battery ?
You use wake locks to keep CPU awake while locked: https://developer.android.com/training/scheduling/wakelock.html
You should aquire it for a small amount of time to not drain battery.
I think if you will acquire a phone wake lock it will drain the battery which is not a good thing . On the other hand, The use of service is really very good,and you talk about the notification of other apps and they works in background because notification does this by default
So in you case As I do not know what are you really trying to do with server, But Service is good option. Service works even your mobile is locked. But in your case if it stops make sure it is not bind with the class.
You should make sure that the Service is not binded with the class or activity as when the activity will be destroyed the service would also be. Just trigger your service and let it handle all the things in background.Please read the discussion in this link. It might help you in understanding better.
I'm developing a similar app to Telegram or WhatsApp, I need to keep a persistent socket connection to a server (I know this is a resource intensive job and I am sure GCM is not going to help in this case, I can't change the architecture at the moment).
First of all I tried writing a Service but since the service is running in the same process as the app's main thread, whenever the app is closed, then the service is restarted. (I have returned START_STICKY on onStartCommand()).
After that I am begining to think I would have to develope an independent service and use AIDL to interact with my app.
I'd appreciate if you could help me with this problem.
Users can always kill your app if they want to. If you've marked your Service as STICKY, Android will simply restart it for you. In this case you will need to recognize that your app has been restarted and recreate the persistent socket connection. There is nothing you can do to prevent a user (or Android) from killing your app under certain conditions.
I implemented a chat application in Android with websockets. However when the user closes the application, the websocket connection to the server is lost and no new messages can be received.
I am essentially lost and do not know where else to turn, how can I setup the service in the app to stay connected to the server as the user logs in as well as after the app has been stopped?
As we're all aware, continuous background code execution is not feasible on Android; different ROMs will man-handle your background services without any guarantees (e.g. START_STICKY will not get your service restarted on some devices), so we need to do the best we can with the code that is reliably executed.
In this situation, you have a websocket server delivering continous information to your client. When your app is in the background, it may miss out on some data. When your app returns to the foreground, your information may be out of sync, so you need to synchronize again with your server, and then reconnect to your websocket.
In my chat app I achieve this by checking whether my websocket service is running onResume in an activity which is a superclass of all the activities that I want to have access chatting data (i.e. not login/registration activities). If the service is not running, I synchronize my data by pulling the changes from an endpoint and then restarting the service. This way, even if the service is killed in the background I will still get the latest data and real-time experience once the app returns to the foreground.