By Local Service is I mean a Service that is only connected to by the host application. It may use the Binder-subclass version of Services or it may use Messenger -- it doesn't matter. Also, I'll consider only services that run on background threads although I think this applies regardless.
I have been trying to figure out the value of local services over a simple background thread. I've seen it written many times that the background thread version somehow ties you to the Activity or Application lifecycle and is right only if your task should only run when the app is in foreground... but I don't see how this is true. Background threads are AFAIK unrelated to the lifecycle of their creator context. They don't onPause or anything like that.
Service describes a "lifecycle API" that permits external (client) control of the Service. So you can, for example, call stopService and implement kill behavior in Service.onStop instead of writing your own API. But the lifecycle is so trivially-simple that this seems like more complexity, not less. For example, stopService and onStop don't need to be two different methods in a simple local implementation.
I'd especially like to hear of any real use cases where a local service was genuinely preferable to a thread.
First of all service changes killing order of your process.
For a task “fire and forget” all is pretty easy, real fun comes with thread communication. The regular Java mechanisms - pipes, shared memory, blocking queues - are available to Android applications but impose problems for the UI thread because of their tendency to block. Hence, the Android platform defines its own helpers.
BTW, "background" service by default starts in the main thread, for true background work you still have to use threads.
Related
This is more of a conceptual question than a matter of programming.
I am currently using ReactiveX (RxJava + RxAndroid) to run an interval timer, as the other methods of timers are too inaccurate when it comes down to the milliseconds. From what I understand, ReactiveX requires several threads to operate correctly.
I need the timer to also be running in the background when the user is not on the app itself. But from reading the Services documentation, it seems that background services can only run on the main thread. I was wondering if it is still possible to run the ReactiveX timer in the background despite this limitation. Implementing services would require some major changes to my project, so I thought that I would try asking before doing so.
The project is written in Kotlin, but I doubt that matters. However, any insight on what this code would look like in Kotlin would be appreciated!
Even though the actual work is done in the background, it seems appropriate to use a foreground service, not a background service.
A background service can easily be stopped by the system or even be deferred to maintenance (time) windows.
In order to get a "foreground" for the service it is common to use a notification and bind to it:
https://developer.android.com/guide/components/services#Foreground
As to the other question: The life cycle functions of a Service like onStartCommand() might be called on the main thread but you'd be using RxJava to switch to another thread instantly and return from those functions.
Even after the lifecycle return, the service is considered "running" to the system. They just exist so get things going and should return promptly.
Workmanager is not necessarily a good choice here as it is designed for deferrable tasks. So you cannot be sure when it exactly will be started. Foreground service seems like the way to go here.
I'm fairly certain that it's standard practice to handle asynchronous file downloads using a Service and AsyncTask. That way, you can kill the originating activity and go on your merry way. However, when you don't need the lifecycle management, remote process communication, or other major features of a Service, it seems a bit overkill.
Since a Service is still a part of the same process and lifecycle of the overall Application, why not simply run a background thread within the context of the Application (vs Activity, although not necessarily within the extended Application class)? Is there any reason why this would be a particularly bad idea?
I'm fairly certain that it's standard practice to handle asynchronous file downloads using a Service and AsyncTask.
An AsyncTask is useless in a Service, as you have no reason to do anything on the main application thread in a Service. Use an IntentService for downloads, as it gives you a background thread, plus automatically stops itself when there is no more work to be done.
why not simply run a background thread within the context of the Application... Is there any reason why this would be a particularly bad idea?
Because your app will be unreliable.
While a lot of people focus on the independent lifecycle of the service, that's not why you use a service for something like this. You use a service as a flag to the OS that your process is still doing something.
Once you are no longer in the foreground, Android can terminate your process, at will, at any moment. Particularly if there is a lot of memory pressure, this can be within milliseconds of your app leaving the foreground.
However, Android generally prioritizes terminating empty processes (ones with no running activities or services) and activity-only processes, ahead of processes that contain a running service. Here, "generally" means that processes with services will not live forever, but they are far less likely to be terminated quickly.
Hence, using an IntentService is signalling to the OS that you are still delivering value to the user (downloading the file) and that it should leave your process alone, until either your IntentService stops (because the download completed) or your service runs so long that it's probably lost its virtual marbles.
An Application is not a Service. Every process has an Application instance. Having a download be "managed" by an Application is pointless -- you may as well run a bare thread outside of any Context. And, most importantly, nothing tells the OS that you are doing anything meaningful, and so your process can be terminated as soon as you leave the foreground.
However, when you don't need the lifecycle management, remote process communication, or other major features of a Service, it seems a bit overkill.
Writing an IntentService, outside of the manifest entry, is not significantly more complicated than writing an AsyncTask. Invoking an IntentService is not significantly more complicated than invoking an AsyncTask.
I am confused with android services and java thread.
Please help me to understand in which scenario i should use them.
As per my understanding
Service run in background ,so do thread.
Service is to be used for activities like network operation or playing mp3 in background,so do threads.
So whats actual difference between them and when to use each of them.
Let me give an analogy.
Activities and Service are like projects.
Activities are like external projects. This is what the clients(users) see.
Services are like internal projects. There might be several internal projects for 1 external project or none at all.
You can "pause" external project but the internal project that supports it can still continue.
Main Thread is like the boss in a company
The boss should never be held up by too much work since he shouldn't be late to meetings (UI freezing) or the client(user) will be unhappy.
Threads are like employees in a company.
The more you have, the more things you can do at the same time provided you have enough equipment(CPU speed) for all of them.
Multiple employees can work on the same project at the same time but the boss should really work only on the Activities.
Always: A service of your application is usable not only by other components of your application, but by other applications, too.
A service is for use in not-GUI parts of program.
Mostly: A service is something more independent, than a thread. Service is something more long-living than a thread. Service is something more complex than a thread.
BTW, threads do not run in background only. What runs in foreground, is a thread, too.
I believe the main difference is about Android system attitude. Service is a part of android infrastructure, so android recognizes service as a working part of application and considers killing service as a last option. Moreover, if your service is killed (e.g. because of memory lack) you can say system to restart it automatically, whenever resources available again. Moreover, you can tune up service priority in order to do it as important as foreground activity. As for threads, android does not recognize a thread as important part which must be kept. So usual threads has much more chances to be killed eventually.
For instance If you have an activity which start a working thread and then go background, as android do not recognize thread as a working part, it may think that application do nothing, because no activity or service running and kill the whole app, including the working thread.
Thus when you start a Service, you are telling system something like: "Hi. I'm doing some business here, don't kill me until I finish, please." and Android pay attention to your request.
Services are more analogous to a headless Activity.
The the important piece to understand is that a Service is about managing application lifetime and the ability to keep work running when your Application is not in the foreground (no UI visible). It is also about providing the ability to expose functionality to other apps.
http://developer.android.com/reference/android/app/Service.html#WhatIsAService
Typically when starting a Service you will also start a worker Thread. There are settings in the manifest that can cause a Service to be started in a new Process but generally you do not need to do this, it makes communication with your service more difficult.
Use a just Thread in your Activity when you need to offload work from the UI thread while the application is in the foreground, but this work can stop when you are no longer in the foreground. (It is possible that your app will continue to run when not it foreground but there is no guarantee depending on a number of factors) Generally speaking Android is free to kill your Activity if it is not in the foreground, and if your App process has no Activities or Services it can be killed.
Use a Service with a Thread to do work that will take place while your app is in the background and you want better guarantee about the lifetime.
Use a Service to expose non-UI functionality to other applications.
Android Service don't run in a separate process (by default) and even don't run in a separate thread! It runs in the main thread(UI thread) of the application, therefore if you would like to do something time consuming task in the Service start a separate thread yourself, or use IntentService.
As per Android Developer Guide (http://developer.android.com/guide/components/services.html#Basics) :
A service is simply a component that can run in the background even when the user is not interacting with your application. Thus, you should create a service only if that is what you need.
If you need to perform work outside your main thread, but only while the user is interacting with your application, then you should probably instead create a new thread and not a service. For example, if you want to play some music, but only while your activity is running, you might create a thread in onCreate(), start running it in onStart(), then stop it in onStop(). Also consider using AsyncTask or HandlerThread, instead of the traditional Thread class. See the Processes and Threading document for more information about threads.
Remember that if you do use a service, it still runs in your application's main thread by default, so you should still create a new thread within the service if it performs intensive or blocking operations.
Why we need service is to avoid resource crunch.
For example you opening an application after opening an another application so at the time your app added to the background task.
While opening multiple application, ur app may killed by android system. So if ur app has service it won't be killed by the system because service is higher priority , even it may killed the app has service so that we using constant return type in onStartCommand(). Method. That's START_STICKY,START_NOT_STICKY and DELIVER_INTENT.
Why do I read in the answer to most questions here a lot about AsyncTask and Loaders but nothing about Services? Are Services just not known very well or are they deprecated or have some bad attributes or something? What are the differences?
(By the way, I know that there are other threads about it, but none really states clear differences that help a developer to easily decide if he is better off using the one or the other for an actual problem.)
In some cases it is possible to accomplish the same task with either an AsyncTask or a Service however usually one is better suited to a task than the other.
AsyncTasks are designed for once-off time-consuming tasks that cannot be run of the UI thread. A common example is fetching/processing data when a button is pressed.
Services are designed to be continually running in the background. In the example above of fetching data when a button is pressed, you could start a service, let it fetch the data, and then stop it, but this is inefficient. It is far faster to use an AsyncTask that will run once, return the data, and be done.
If you need to be continually doing something in the background, though, a Service is your best bet. Examples of this include playing music, continually checking for new data, etc.
Also, as Sherif already said, services do not necessarily run off of the UI thread.
For the most part, Services are for when you want to run code even when your application's Activity isn't open. AsyncTasks are designed to make executing code off of the UI thread incredibly simple.
Services are completely different: Services are not threads!
Your Activity binds to a service and the service contains some functions that when called, blocks the calling thread. Your service might be used to change temperature from Celsius to Degrees. Any activity that binds can get this service.
However AsyncTask is a Thread that does some work in the background and at the same time has the ability to report results back to the calling thread.
Just a thought: A service may have a AsyncTask object!
Service is one of the components of the Android framework, which does not require UI to execute, which mean even when the app is not actively used by the user, you can perform some operation with service. That doesn't mean service will run in a separate thread, but it runs in main thread and operation can be performed in a separate thread when needed.
Examples usages are playing music in background, syncing data with server in backgroud without user interaction etc
AsyncTask on other hand is used for UI blocking tasks to be performed on a separate thread. It is same like creating a new thread and doing the task when all the tasks of creating and maintaining the threads and send back result to main thread are taken care by the AsyncTask
Example usage are fetching data from server, CRUD operations on content resolver etc
Service and asynctasks are almost doing the same thing,almost.using service or a asynctask depends on what is your requirement is.
as a example if you want to load data to a listview from a server after hitting some button or changing screen you better go with a asynctask.it runs parallel with main ui thread (runs in background).for run asynctack activity or your app should on main UI thread.after exit from the app there is no asynctask.
But services are not like that, once you start a service it can run after you exit from the app, unless you are stop the service.like i said it depends on your requirement.if you want to keep checking data receiving or check network state continuously you better go with service.
happy coding.
In few cases, you can achieve same functionality using both. Unlike Async Task, service has it's own life cycle and inherits Context (Service is more robust than an Async Task). Service can run even if you have exited the app. If you want to do something even after app closing and also need the context variable, you will go for Service.
Example: If you want to play a music and you don't want to pause if user leaves the app, you will definitely go for Service.
Comparison of a local, in-process, base class Service✱ to an AsyncTask:
✱ (This answer does not address exported services, or any service that runs in a process different from that of the client, since the expected use cases differ substantially from those of an AsyncTask. Also, in the interest of brevity, the nature of certain specialized Service subclasses (e.g., IntentService, JobService) will be ignored here.)
Process Lifetime
A Service represents, to the OS, "an application's desire to perform a longer-running operation while not interacting with the user" [ref].
While you have a Service running, Android understands that you don't want your process to be killed. This is also true whenever you have an Activity onscreen, and it is especially true when you are running a foreground service. (When all your application components go away, Android thinks, "Oh, now is a good time to kill this app, so I can free up resources".)
Also, depending on the last return value from Service.onCreate(), Android can attempt to "revive" apps/services that were killed due to resource pressure [ref].
AsyncTasks don't do any of that. It doesn't matter how many background threads you have running, or how hard they are working: Android will not keep your app alive just because your app is using the CPU. It has to have some way of knowing that your app still has work to do; that's why Services are registered with the OS, and AsyncTasks aren't.
Multithreading
AsyncTasks are all about creating a background thread on which to do work, and then presenting the result of that work to the UI thread in a threadsafe manner.
Each new AsyncTask execution generally results in more concurrency (more threads), subject to the limitations of the AsyncTasks's thread-pool [ref].
Service methods, on the other hand, are always invoked on the UI thread [ref]. This applies to onCreate(), onStartCommand(), onDestroy(), onServiceConnected(), etc. So, in some sense, Services don't "run" in the background. Once they start up (onCreate()), they just kinda "sit" there -- until it's time to clean up, execute an onStartCommand(), etc.
In other words, adding additional Services does not result in more concurrency. Service methods are not a good place to do large amounts of work, because they run on the UI thread.
Of course, you can extend Service, add your own methods, and call them from any thread you want. But if you do that, the responsibility for thread safety lies with you -- not the framework.
If you want to add a background thread (or some other sort of worker) to your Service, you are free to do so. You could start a background thread/AsyncTask in Service.onCreate(), for example. But not all use cases require this. For example:
You may wish to keep a Service running so you can continue getting location updates in the "background" (meaning, without necessarily having any Activities onscreen).
Or, you may want to keep your app alive just so you can keep an "implicit" BroadcastReceiver registered on a long-term basis (after API 26, you can't always do this via the manifest, so you have to register at runtime instead [ref]).
Neither of these use cases require a great deal of CPU activity; they just require that the app not be killed.
As Workers
Services are not task-oriented. They are not set up to "perform a task" and "deliver a result", like AsyncTasks are. Services do not solve any thread-safety problems (notwithstanding the fact that all methods execute on a single thread). AsyncTasks, on the other hand, handle that complexity for you.
Note that AsyncTask is slated for deprecation. But that doesn't mean your should replace your AsyncTasks with Services! (If you have learned anything from this answer, that much should be clear.)
TL;DR
Services are mostly there to "exist". They are like an off-screen Activity, providing a reason for the app to stay alive, while other components take care of doing the "work". AsyncTasks do "work", but they will not, in and of themselves, keep a process alive.
Is there any difference between AsyncSync being fired up from Activity or IntentService?
I'm building an app which downloads and uploads files via http. I use custom notification layout with progress bar for each transfer.
I choose between doing transfers in parallel or putting them into queue (which option would you recommend?).
For the option with queue I use an IntentService, so Android framework takes care of putting tasks into a queue for me.
For having them in parallel I use AsyncTasks. But I fire them up from IntentService (could be Service as well) - is there any point doing so? IntentService is terminated right after it executes AsyncTask, so the AsyncTask runs without any "parent".
What if I fired up those AsyncTask from Activity, go to the homescreen and system decided to close this Activity? Can it do that? Will the AsyncTask survive it?
What would be the preferred approach for this case?
AsyncTask isn't really appropriate for things where you're concerned about surviving outside the lifecycle of a component (if you need to message back to that component). If you're going to the extent of having a service, I wouldn't even bother with AsyncTasks. As far as parallel or queue, that really depends on a lot of different variables, but I certainly wouldn't make it completely parallel for any number of downloads/uploads. I'd set some limit on the max number of concurrent transfers.
There's no point in using IntentService for parallel exeuction--you've noted the problem with that already. You're getting into territory which is not really covered by the Android API. AsyncTask and IntentService are nice abstractions that make several scenarios easy, but parallel execution of many many tasks is not one of them. It's probably best to use some of the Java threading/concurrency classes. Take a look at ThreadPoolExecutor.
First your easy questions, an AsyncTask will survive being in the background as long as the parent application is not killed. Starting it from an Activity will tell the system that it can be killed if memory pressure requires it. The system also does not consider it having a long running process that may be interrupted.
The dev guide Services has a great info box under its "The Basics" heading about whether you should use a Service or Activity. Activities get none of the memory pressure consideration that Services get or a restart after a kill, when system resources become available again.
If you wanted me to make the call for you, use the IntentService. Whether to run the downloads in parallel or series or some combination is a tough call because you must consider the network (Wifi or Cellular), file size, and other system resources.