I have a scenario where I need to notify the server whenever the device language changes. I need to call an API (even if the app is not running)
and update the current language with the server. I have implemented this with the help of a BroadCastReceiver for
<action android:name="android.intent.action.LOCALE_CHANGED" />
As soon as the broadcast triggered, I'm launching a service and calling the API. But, Since Android Oreo and above has background execution limits,
I have to launch a ForegroundService.
Here, during the background API call, a notification is visible in the Notification panel. So,
The user can still go to App settings and Force Stop the App, then the API call will be interrupted. But I need a guaranteed execution of this API. Is there any way to execute it in the background
other than foreground service? Can it be done with the help of WorkManager or Job Scheduler? What is the best way to handle this use case? Hope my question is clear. Thanks in advance!
The user can always kill your app so this should not be unexpected. But if you do not like foreground service, then queue this information (with timestamp) in DB and send to your API next time your app is running. If you must send immediately then do queue it too and then send immediately. If the user kills your app in mid-operation then you still will be able to resend it from queue next time. WorkManager is a good choice:
Guarantees task execution, even if the app or device restarts
Related
Once the user gets into an activity, I need to send a value to the Web Service and, once s/he exits the activity, I need to send another value to the server. It needs to happen at that exactly moment.
Android Developers guide says I should use Foreground Services for background tasks which need to be executed immediately, and WorkManager for deferable tasks. However, I do not need to update anything on the UI nor a notification (as they are mandatory in Foreground services) after the task is done...
What should I use?
UPDATE:
As said in the comment
OnDestroy is not even guarenteed to be called on process death and moreover. The correct approach is a foreground service that shows some generic "syncing with server" message until it's done
I've just been reading about adding a service to my application, and since 7/8 there are now service restrictions to improve phone performance.
I've seen that the recommended approach is to use a job scheduler, but will that not just periodically start a new listener if I did that?
Basically I update my database, and using a snapshot listener I want to update my user in real time. When the app is closed, I'd like to send a notification.
My issues (if I'm correct) are that constantly making a new Firestore request will eat through my request allowance.
Also, if its a job scheduler it won't quite be real time?
I've read that you can use a foreground service, but this doesn't really seem like that task that needs a permanent notification and would annoy the user.
Anyone got any tips on how I'd implement this?
Thanks
Using a listener after an android application is closed
You can use a listener after an android application is closed, by not removing it. Once you are using a listener, you also need to remove it according to the life-cycle of your activity. But this will work only for a shot period of time because Android will stop your service if the app is not in the foreground. It does this to save resources when the app isn't being used. It also might stop your app from doing any networking, or even kill the app process completely. There's nothing you can do to prevent this, other than making it a foreground service, as you already mentioned.
A foreground service is probably not the best thing to do for your case, nor is it the best thing for your users. Read more about limitations on background services.
My recommendation is to use Firebase Cloud Messaging to notify your app when something has changed that it might be interested in. So your users will recieve notification even if they will keep their app closed.
I need to create a service that runs alongside the android app,irrespective of which screen of the app the user is on.
The app is a chat application so when the device is offline the service should queue up all the messages that are being sent offline and when the device is connected it should sync all messages.
I have written code for the job scheduler to sync data automatically when the device is online but while the app is active i would like to handle this manually.
Creating a Long Running service.
Operating system still can terminate the service in low memory and possibly other situations. There are 2 ways to overcome this:
If you are implementing the service, override onStartCommand() and return START_STICKY as the result. It will tell the system that even if it will want to kill your service due to low memory, it should re-create it as soon as memory will be back to normal.
AlarmManager .A system service, which will execute actions periodically. That will ensure that if your service will be terminated, or even the whole process will die(for example with force close) - it will be 100% restarted by AlarmManager.
Thank you.
You can do this by simple following steps:
Create Simple Service and after first launch of app just start at splash screen.
In Service after getting one data you can call another request.
After that you can create one broadcast action globally which will always call every network changed.
At background you can sync again data and saved it to shared preferences or as per your your requirement.
For interval you can also using AlarManager.
A part from this you can simply create Service using JobSheduler in this you can assign job and time as well.
Refer link :
https://developer.android.com/reference/android/app/job/JobScheduler.html
Hopefully this logic will helps you.
You have to use a intent service with sticky instead of service for this which will be executed in a queue and do your work. And since it is a intent service it will be started automatically after sometime, when system kills the service process.
I am working on a small project. We need to do the following:
Have a background service/whatever running on your android ph which
listens for a sms with some specific content in the msg body
On encountering that specific content, make a webservice call to a
remote server to download some event data
Set the fetched event data as reminders in the calendar
All the above must be done without any user interaction.
I have managed to do #1 via a broadcast receiver. Didn't need to run a service for it.
For #2, I plan to call the web service via the Broadcast receivers onReceive() method and get the data. Once I have the data, how do I go about setting the same so that the user gets his/her timely reminders based on the same? There is no activity opening up or anything that the user can see. He should just get the reminders (even if he restarts the ph).
Any help will be much appreciated. Thanks!
For #2, I plan to call the web service via the Broadcast receivers onReceive() method and get the data.
Please don't. This will be unreliable and will freeze your UI if you happen to have the foreground activity. onReceive() is called on the main application thread, and Android will terminate your code if it thinks you are spending too much time on that thread, even in the background. Please delegate this work to an IntentService, which has a background thread and automatically shuts down when there is no more work to be done.
Once I have the data, how do I go about setting the same so that the user gets his/her timely reminders based on the same?
On Ice Cream Sandwich (Android 4.0), you could add events to their calendar.
Before that, roll your own reminder mechanism using AlarmManager.
There is no activity opening up or anything that the user can see.
You have no choice but to supply an activity. Otherwise, your app will never run on Android 3.1+. They will need to run your activity once to enable your app, then again every time after they elect to kill off your app via a task killer or the Settings application.
I am creating an app that has a UIThread and a background thread. The background thread is basically being used as a timer - every second it sends a message to the UIThread to update the UI. When the user exits the app by hitting the backbutton, the thread continues to run. I want this to happen since the user may want to open another app while the timer continues to count down.
My question is when the user comes back to my app. I want to connect to that background thread that is running to display the current state of the app - how much time is left, etc. My question is how to hook back in to the thread that is still running in the background. I have tried using Thread and AsyncTask, but the same issue occurs.
Thanks for any help that you can provide.
Your thread is still turning by sheer chance - your application is in fact still running but it and the thread will be shut down when Android decides it needs the resources.
However what you want to do is well-provided for in Android - you need to implement a Service to have a process that runs in the background separately from your application. You can even have a Service start at boot and run whether or not your application is started.
This http://developer.android.com/reference/android/app/Service.html has most of what you need to know. To communicate between the Service and a foreground Activity you'll need to bind to a service interface, which is fortunately very easily done.
First thing that comes to mind is to change your timer thread to a Service and have apps interested in it bind to that service. Based on the Android documentation and suggested app design, you cannot depend on that thread to not be killed by the OS whenever it deems necessary.
http://developer.android.com/guide/topics/fundamentals/services.html
The android system provides a broadcast event every minute, it's call TIME_TICK.
You should:
Create a service. This is the recommended way to have a part of the app running in the background
Listen to the TIME_TICK event. This will consume less battery. (It won't wake the phone, though, so use an ALARM, too)
Add an alarm (to wake the phone if necessary)
Let the UI and the service interact. You need a callback via rpc (see the last callback example on the api page)
You should also ensure that the phone can sleep during the timeframe. You thus may want to compute the state as a delta between the starting point and now, instead of updating the state all the time.