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.
Asked
Active
Viewed 1.1k times
3 Answers
41
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 and ends 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.
synic
- 26,359
- 20
- 111
- 149
-
Thanks, that's what I thought. On a related topic, at least in the emulator, after I've started the streaming player it would continue to play even after I pressed the back button. I was assuming it would stop when the activity was no longer in the foreground... is it because of the new thread or it will play regardless until android kills the application. – zerayaqob Apr 13 '10 at 22:09
-
Yeah, the thread will stay running until Android kills it. If you want it to stop, implement some sort of "active" flag and set it to false in your onDestroy() method. – synic Apr 13 '10 at 22:32
-
3Also note that threads in an `Activity` are destroyed when the configuration (read: orientation) changes! This is not true for threads in `Service` s. – MrSnowflake Apr 14 '10 at 00:05
-
8Threads in an Activity won't get destroyed during a configuration change at all. They may, however, have local references to the old Activity, which may be a problem. – synic Apr 14 '10 at 00:24
-
they may have local reference which maybe a problem you said? @synic ? if that's the case then... we should ensure that the UI (activity) is still active for the Service that still running and want to access it. right? otherwise, the error should be in try & catch statements. – gumuruh Aug 26 '14 at 15:31
2
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!!!
AlikElzin-kilaka
- 34,335
- 35
- 194
- 277
-
Can you give a situation where you would need to run a new thread in a service rather than just running a new thread in an activity to accomplish that same task? – committedandroider Aug 18 '15 at 21:48
-
@committedandroider Say, you have a browser app and user selects to download a file of 1 GB. User won't keep your browser app opened and wait for the file to be downloaded. He will simply start the download and exit the app. In this case, if have thread spawned from Activity will no longer be running, so you need to spawn a thread from the Service. – CopsOnRoad Sep 12 '17 at 07:54
-
@committedandroider You are right. It's been a long time you asked that. But recently I joined SO and I learned about Services and Threads so I preferred to answer your question. – CopsOnRoad Sep 13 '17 at 03:12
0
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.
Valeriy Katkov
- 33,616
- 20
- 100
- 123