I have an application with background service (important tasks run in background always).
What is your offer for handle important tasks?
my application may be close but these tasks must be done.
If your service is doing important task and the application mustn't be close you should use Foreground Service as it will inform the user that you're doing some work.
If you don't need immediate execution you can use WorkManager. WorkManager offers deferrable but guaranteed execution, it'll run even if you're application is killed.
Related
Android Os. Is there a way to start Location Manager in background Thread with WorkManager(ex)?
WorkManager is for background work that's deferrable and requires guaranteed execution:
Deferrable means that the work is not required to run immediately. For example, sending analytical data to the server or syncing the database in the background is work that can be deferred.
Guaranteed execution means that the task will run even if the app exits or the device restarts
You should check this list and see what fits for your needs. I would recommend you start your Location Manager with a Foreground Service
My question is can I close the activity after starting work manager?. currently in my app, I want to use WorkManager to print a receipt from the printer. So I want to start WorkManager from the activity, then I need to close the activity. Will the code from the WorkManager continue the print task from the worker or will it stop after closing the activity ?
Short Answer :- Yes
that's the whole point of the using the workmanager so you can schedule your task based on System events, so it does not not matter what activity is running.
as according to the documentation
For work that is deferrable and expected to run even if your device or
application restarts, use WorkManager.
https://developer.android.com/guide/background/#workmanager
About how to implement workmanager, below documentation will help you.
https://developer.android.com/topic/libraries/architecture/workmanager/basics
here at the end you will find section "Hand off your task to the system".
the system will place your task in a system queue to execute it based on system event that you will define
In my app, the user can start a background process that makes long running API calls to the backend. The user will also have the ability to pause the background thread and resume at any point.
If the app restarts, the background process should resume from where it left off. Once the background process has completed, the process should terminate.
Even when the background process is running, if the user hits the device's home button, I still want the background process to keep running. It is not necessary for any UI to be shown while it is running.
Reading up on the Android docs, it would seem that using WorkManager is probably the best choice since my minSdkVersion is 19. Is this true?
The process can run for hours
WorkManager work cannot run that long. You could still use WorkManager for the scheduling aspect, but then the "work" would need to be starting a foreground service, where the service then does the actual network I/O.
It is not necessary for any UI to be shown while it is running.
On Android 8.0+, you cannot have something running for hours without UI showing, at least in the form of a Notification associated with a foreground service.
I need to do some background updates (about every 1 min). I have to use JobService to do it periodically. But I don't need to run service when app is closed - only when app is running (on foreground).
Is there is a way to do that?
You don't need a JobService for that. Simply use normal Service. The OS allows apps in foreground to freely create the service. You can easily start a Service and perform your task. You can use Handlerthread for background processing or use Handler for foreground processing.
Note for Android O: If your app goes to background then your Service will be stopped as if you have called stopSelf(). Remember to clean up the necessary object's state.
What are the advantages/disadvantages in placing a lengthy network access code in a thread in an activity or a thread in a service? How would it affect the application? I am writing a streaming audio player and from what I've read so far putting the code in a service will still end up blocking the application so a new thread is needed, does anyone know if it makes more sense to put this piece of code in a service.
Yes, a blocking operation in a Service will still block the application. Despite first appearances, Services are not simply for running tasks in the background. They are for running tasks with a lifecycle that is independent of the Activity lifecycle (IE, they may continue after the Activity is closed).
A Service that starts when an Activity starts and ends when the Activity ends is useless.
In your case, where you are streaming audio, you may want to stream audio even after the user closes the Activity, in which case, you should use a Service, but you'll still need a thread (or an AsyncTask) for blocking tasks.
From my experience (1+ years developing Android), there is no difference between running a new thread in a service or in an activity.
Try not to keep a reference to the Activity in the new thread - use the application context.
Also, the service's life-cycle didn't help at all because some methods are not guaranteed to be invoked :(
The only difference may be that the service can be destroyed without destroying the app completely - thus potentially destroying the new threads.
Why potentially? because on the practical side, this doesn't happen. The app ALWAYS gets killed without killing the service before that, meaning: the local service mechanism is useless!!!
Remote service is a different discussion - I was referring only to "where should I run a new thread?".
Good luck!!!
The difference is how the system manages your application process lifecycle. Running threads don't affect the application process lifecycle, but a service does.
To determine which processes should be killed when low on memory, Android places each process into an importance hierarchy based on the components running in them and the state of those components. If your app doesn't have a visible activity or a foreground service but has a background service, it's categorized as a service process and will be kept alive while there less priority cached processes exist. But if the app has neither a visible activity/fragment, foreground service nor a background service, it's categorized as a cached process and can be killed at any time to free system resources, whether it has a running thread or not.
But do not rush to create a background service, there are more modern approaches to deal with background tasks nowadays. Consider alternative solutions described below and in the background processing guide and keep in mind all restrictions associated with background services.
If a thread executes a task which result is required only by an activity, the thread lifecycle should be bound to the activity. In such a case no services are required. It's so called immediate tasks, ViewModel + Kotlin Coroutines + ViewModelScope is a great way to deal with it, see Guide to background processing for more details about different kinds of background tasks.
If the task should be completed whether the user closed you app or not and it's not required to execute it immediately, consider using WorkManager which is a great way to deal with such deferred tasks. See Android Work Manager vs Services? for more details.
Otherwise, if you have an immediate task which lifecycle isn't bound to an activity/fragment, may be a foreground service would be the best choice, especially in case of an audio player. There are some limitations considering background services since Android 8, the system stops an app's background services in several minutes after the app is closed, so it's not a place for a long running task.