Can someone tell me the TRUE difference?
My rule of thumb is that an AsyncTask is for when I want to do something tied to single Activity and a Service is for when I want to do something that will carry on after the Activity which started it is in the background.
So if I want to do a small bit of background processing in the Activity without tying up the UI I'll use an AsyncTask. I'll then use the default Handler from that Activity to pass messages back to ensure updates happen on the main thread. Processing the updates on the main thread has two benefits: UI updates happen correctly and you don't have to worry so much about synchronisation problems.
If for example, I wanted to do a download which might take a while I'd use a Service. So if I went to another Activity in my application or another application entirely my Service could keep running and keep downloading the file so it would be ready when I returned to my application. In this case I'd probably use a Status Bar Notification once the download was complete, so the user could choose to return to my application whenever was convenient for them.
What you'll find if you use an AsyncTask for a long-running process it may continue after you've navigated away from the Activity but:
If the Activity is in the background when your processing is complete you may have problems when you try to update the UI with the results etc.
A background Activity is far more likely to be killed by Android when it needs memory than a Service.
Use Service when you've got something that has to be running in the background for extended periods of time. It's not bound to any activity. The canonical example is a music player.
AsyncTask is great when some stuff has to be done in background while in the current activity. E.g. downloading, searching for text inside a file, etc.
Personally I use Handlers only to post changes to the UI thread. E.g. you do some computations in a background thread and post the result via handler.
The bottom line: in most cases, AsyncTask is what you need.
To complement the other answers here regarding the distinction between service and AsyncTask, it is also worth noting[0]:
A Service is not a separate process. The Service object itself does not imply it is running in its own process; unless otherwise specified, it runs in the same process as the application it is part of.
A Service is not a thread. It is not a means itself to do work off of the main thread (to avoid Application Not Responding errors).
Services tend to be things that describes a significant part of your application - rather than an AsyncTask which is typically contributes to an Activity and/or improves UI responsiveness. As well as improving code clarity Services can also be shared with other applications, providing clear interfaces between your app and the outside world.
Rather than a book I would say the developer guide has lots of good answers.
[0] Source: http://developer.android.com/reference/android/app/Service.html#WhatIsAService
AsyncTask: When I wish to do something without hanging the UI & reflect the changes in the UI.
E.g.: Downloading something on Button Click, remaining in the same activity & showing progress bar/seekbar to update the percentage downloaded. If the Activity enters the background, there are chances of conflict.
Service: When I wish to do something in the background that doesn’t need to update the UI, use a Service. It doesn’t care whether the Application is in the foreground or background.
E.g.: When any app downloaded from Android Market shows notification in the Status Bar & the UI returns to the previous page & lets you do other things.
Service
A Service is an application component that can perform long-running operations in the background and does not provide a user interface. Another application component can start a service and it will continue to run in the background even if the user switches to another application. Additionally, a component can bind to a service to interact with.
When to use?
Task with no UI, but shouldn’t be too long. Use threads within service for long tasks.
Long task in general.
Trigger: Call to method onStartService()
Triggered from: Any Thread
Runs on: Main thread of its hosting process. The service does not create its own thread and does not run in a separate process (unless you specify otherwise)
Limitations / Drawbacks: May block main thread
AsyncTask
AsyncTask enables the proper and easy use of the UI thread. This class allows performing background operations and publishing results on the UI thread without having to manipulate threads and/or handlers. An asynchronous task is defined by a computation that runs on a background thread and whose result is published on the UI thread.
When to use?
Small task having to communicate with main thread
For tasks in parallel use multiple instances OR Executor
Disk-bound tasks that might take more than a few milliseconds
Trigger: Call to method execute()
Triggered from: Main Thread
Runs on: Worker thread. However, Main thread methods may be invoked in between to publish progress.
Limitations / Drawbacks:
One instance can only be executed once (hence cannot run in a loop)
Must be created and executed from the Main thread
Ref Link
Related
I have read the two reasons/issue mentioned on:(Please read two reason on below link)
Android AsyncTask for Long Running Operations
1. "If you start an AsyncTask inside an Activity and you rotate the device, the Activity will be destroyed and a new instance will be created. But the AsyncTask will not die":
Lets suppose i have set the orientation of my activity to Portrait. Will this issue still be there?
2. Memory leak issue:
inner class will hold an invisible reference on its outer class instance : the Activity.
What if i am not using Inner AsyncTask instead created separate class. Also if i use weak reference.
The issues you mention arise only when life-cycle of AsyncTask is not handled properly, mainly from lack of understanding of how they work.
AsyncTask is a wrapper for running code on a separate thread. It is similar to plain Java's Runnable submitted to ExecutorService, with additional features of "pre" and "post" hooks to be run on main thread. So, its basically an enhanced version of Thread, Runnable and Handler setup.
By default AsycTask's share a single thread and hence not advised for long running tasks. Because when a single background thread is shared by many tasks, a long running task may block others. However, AsycTask can also run on a custom Executor, removing such restrictions of a shared worker thread.
All that means that AsyncTask's own design doesn't restrict its usage for long running tasks.
You can have a background Service run some continuous processing using AsyncTasks on a separate ThreadPoolExecutor.
You can have a Fragment load latest news using an AsyncTask and when Fragment's onDestroy() is called, you cancel the task, since its no longer meaningful.
Hence the answer to "how long and AsyncTask should run", entirely depends upon the usage context.
Additional problem of AsyncTask: losing your results.
Yes, you said:
Lets suppose i have set the orientation of my activity to Portrait.
Will this issue still be there?
But, Activity could be recreated not only 'cause rotation. For example, if there is no enough resources in system, operation system can destroy your Activity.
So, for long running operations there is high risk that AsyncTask will have an invalid reference to its Activity in onPostExecute() after Activity recreation.
Another problem: parallelism.
new AsyncTask1().execute();
new AsyncTask2().execute();
Will these two tasks run at the same time or will AsyncTask2 start when AsyncTask1 is finished?
Well... It depends on the API level.
And aboud API level...
Before API 1.6 (Donut): the tasks were executed serially. This means a task won't start before a previous task is finished.
API 1.6 to API 2.3 (Gingerbread): the Android developers team changed AsyncTasks to make possibility to start them in parallel on a separate worker thread.
API 3.0 (Honeycomb): the AsyncTasks where executed serially again. Of course the Android team provided the possibility to let them run parallel. This is done by the method executeOnExecutor(Executor). Check out the API documentation for more information on this.
Setting the orientation will work because locking to portrait means no orientation change, meaning no lifecycle re-creation because of this. However if an activity is paused for a long time it can still be destroyed so this is not a good way to make sure this works 100%. You could instead try a service or a headless fragment.
According to this post, having a weak reference will solve the memory issue
AsyncTask have following drawback.
1. Memory leak :- In inner class as well in seprate class you provide reference of your activity to AsyncTask for callback in both case AsyncTask will not release the reference of activity for GC which cause memory leak.
2. GC :- If a AsyncTask is running although the calling activity is destroyed it will restrict the GC to not run till it will not finish its process.
3. On Orintation change activity recreate as Asynchtask will running in background and when it finish its operation it will try to update UI which cause IllegalStateException as activity is not attached to window.
So its better if you use Service for long running background process instead of AsyncTask.
There are so many superstitions around this topic, it's hard to know where to start. AsyncTask is just a small piece of sugar around a standard task queue, using it or not using it does not make much difference in comparison to other things.
For example the problem of orientation change is NOT real. You can start an AsyncTask when the activity starts for the first time and simply not start it the next time around. (and remember that other changes in configuration can also restart your activity).
The weak references are a total overkill and will probably get you nowhere. You either need a reference to the current activity (and then the weak reference won't work) or not (and then, simply don't hold any reference).
The most important, and missing from your question, is what are you actually trying to accomplish?
Think about someone answering their phone while your application is running, and going back to it after some time. And then try to answer questions like:
- are the results from 15 minutes ago relevant? Or will the task be restarted?
- how about 6 hours ago?
- will something bad happen if the background task is interrupted?
- does user expect the task to be finished? (did he press "OK" and just waited for a confirmation to appear?).
And then you can ask a more precise question. AsyncTask can be used in any scenario, but usually it's simpler not to use it than to use it correctly.
I have the following design:
Activity/FragmentA upon a user action starts an AsyncTask to fetch a set of data.
While the AsyncTask is running, a progress indicator is displayed to the user.
When the AsyncTask finishes its task and fetches the resultset, it saves it in a singleton class serving as a shared datamodel.
When FragmentA is notified that the AsyncTask has finished (LocalBroadcastReceiver) then it start ActivityB/FragmentB which takes the set of results from the shared singleton and displays them in a ListView.
This works but since I am a newbie in android I am trying to understand and learn best practices.
E.g. I see a small delay from the time the progress bar is dismissed to the time the UI of ActivityB/FragmentB is displayed (during this latency the UI of ActivityA/FragmentA is still visible).
Also I think that somehow if the fetch of the items was done from FragmentB instead of FragmentA would make FragmentB "autonomous"
Overall can someone please help me understand how could I have implemented this differently using better/standard practices in android and the pros/cons of each approach?
Fragments
Fragments are small part of the activity which has their own life cycle, which provides developer more flexibility to deal with UI. Fragments has nothing to do with background processes.
Now your main question is about the background processes.
AsyncTask
This is nothing but the bit better version of thread with some predefined callbacks, when u need to perform some network operation which will take not more than 20 seconds, and after that it refreshes the UI, its better to use asycntask. Do not use Services (Avoid complexity, Keep it simple). You can use some third party library also.
IntentService
Now IntentService are better version of service, the main purpose of IntentService is to avoid performing long running operations on mainthread and provide queueing system to the developer. You should use services if you do not need user interaction while running long running operations (e.g syncing app with the server at the end of every day).
So for conclusion
User Interaction + short running network operation = AsyncTask
No User Interaction + long running network operation = IntentService + Broadcast Receiver to notify UI of needed
What is the purpose with Service class?
Many examples with Bluetooth Low Energy uses Service classes for all Bluetooth communication, connecting, disconnecting, scanning for devices etc. Activity classes always call method from this Service class.
What about implementing all Bluetooth communication directly in an Activity class instead?. Why does nobody implement like that and uses a Service class instead?
From the documentation:
A Service is an application component that can perform long-running operations in the background and does not provide a user interface. Another application component can start a service and it will continue to run in the background even if the user switches to another application. Additionally, a component can bind to a service to interact with it and even perform interprocess communication (IPC). For example, a service might handle network transactions, play music, perform file I/O, or interact with a content provider, all from the background.
Basically it is a loosly coupled component independet from activitys lifecylce. The problem is in Android you can't really control when an activity will be created/destroyed, so for example if you are loading somenthing in an activity and you receive a call, your activity might get destroyed and the result of your update will be lost, or even worst your loading task won't finish and holds on to the activity and it can't be garbage collected and you create a memory leak.
So you use service for long running background tasks, but you just let them run as long as you have to, to avoid, again, memory leaks and be nice to your resources.
Caution: It's important that your application stops its services when it's done working, to avoid wasting system resources and consuming battery power. If necessary, other components can stop the service by calling stopService(). Even if you enable binding for the service, you must always stop the service yourself if it ever received a call to onStartCommand().
what about implementing all Bluetooth communication directly in an Activity class instead
you most likely end being killed by the framework for doing too much on UI thread (aka ANR - Application Not Responding). See Keeping Your App Responsive article on develoer site.
Anything that is not directly related to UI (like networking of any kind) should be offloaded to separate task. Be it AsyncTask:
This class allows to perform background operations and publish results
on the UI thread without having to manipulate threads and/or handlers.
or IntentService:
IntentService is a base class for Services that handle asynchronous
requests (expressed as Intents) on demand.
. The Service (not IntentService) is for slightly different purpose:
A Service is an application component representing either an
application's desire to perform a longer-running operation while not
interacting with the user or to supply functionality for other
applications to use.
Service class is used to perform , background non UI operations like playing audio file.Further service is the component that will run in background even if your activity gets destroyed ,While using Bluetooth we really do some non UI phone level operation and hence we use Services .
Activity class isn't a good place for any kind of communication tasks. It can be killed as soon as user switches to another activity. It shows UI, that means that we can't do much work in Activity's thread. Sometimes you can use somthing like
Thread t = new Thread(new Runnable() {
#Override
public void run() {
// do something here
}
});
t.start();
or more complicated things with AsyncTask but this is suitable for short-time actions.
Service will not be killed so fast, so it's good for background work of any kind. Just read Android documentation about services.
I'm developing an app which must heavily interact with the server.So user input name and password and after authorization the next tasks must be performed:
The app has to fetch all incoming and outcoming messages for this user and load them to SQLite database.
Fetch all user friends (JSON with id,names,contact_data) and also load it to the app's database
Jump to the next activity and display income messages from the local database.
The problem this operations are too slow and when app starts new activity it is nothing to fetch from the database :AsyncTasks have not completed yet.I'm forced to use AsyncTask.get() in order to wait when they all complete but this takes over 16 seconds to wait!So what should I do: use threads, or before loading fetched data to database hold it in memory and display it in the new activity instead of fetching it from the database?But even without database tasks other fetching tasks take nearly 10 seconds to wait!So what should I do?
Oke a couple of things going pretty wrong here.
Do not use AsyncTasks for Networking. Use a service. In short, this is because your AsyncTask will stop, as soon as the Activity that started it will stop. This means that network requests get aborted easily and data goes lost and has to re-start again when the Activity is opened again.
Do not use .get() on AsyncTasks. This makes the UI thread wait for the task to complete, making the whole AsyncTask idea kinda useless. In other words: This blocks your UI.
What you should do:
Read up on using services. You can also have a look at a great opensource library called RoboSpice to help you with this.
Stop using .get() on AsyncTasks, if you want to know when it is done just use a listener.
Execute AsyncTasks on a threadpool ( myTask.executeOnExecutor(AsyncTask.THREAD_POOL_EXECUTOR); ) when possible.
You should use a Service. This way it always can complete the tasks it was doing and you can complete all your tasks. Besides that you should initialize the app once, and after that only update the data.. that can't take 10 seconds.. than you're having an other problem.. But the nice thing of the service is that this can run in the background. see: Services in Android Tutorial
== Edit
Also take a look at GreenDao This library arranges fast SQlLite operations. Without the large setup!
AsyncTasks are not meant to run several small tasks concurrently at the same time. Quoting the docs
When first introduced, AsyncTasks were executed serially on a single background thread. Starting with DONUT, this was changed to a pool of threads allowing multiple tasks to operate in parallel. Starting with HONEYCOMB, tasks are executed on a single thread to avoid common application errors caused by parallel execution.
Use Threads in a ThreadPool when you want to run multiple tasks concurrently.
How you want to handle this situation is up to you. When the background tasks take too long, you can always show an alert dialog to the user and then take them to the activity once the data has been populated. Many apps show a 'Loading' screen when this happens. You can also show the 'Loading' Spinner control if no data is available yet. Never show a blank screen.
If the server side calls are under your control, employ some sort of caching to speed up the time. Any API call that lasts more than a second will make for an impatient user. If not employ one of the techniques mentioned in the previous paragraph. #Perception's technique is also one to consider if you can do it.
I can't seem to find any documentation on the details of an Activity's run loop for Android.
Apple documents the "anatomy of a run loop", and that's pretty much what I'm looking for. The Android documentation just says "Activity Is Running" in its life cycle state diagram. Obviously that's backed up by some sort of run loop.
Anyone have some insight (aka Documentation) into the internals of an Activity's run loop?
edit - I should clarify that I presume the run loop is actually owned and run by the main UI thread. The current Activity's functionality is likely injected into this runloop at a certain point. I'm interested in the overall UI thread run loop, as well as what role the Activity takes in it.
The short answer is, "don't worry about it, it's done for you."
Activities and other constructs sit on top of android.os.Looper, communicating with it through instances of android.os.Handler. A Looper manages your "run loop," dispatching messages from a queue and blocking the thread when it's empty. Handlers communicate with a thread's Looper and provide a mechanism for working with the message queue.
Most of the time you won't need to work with either one directly. Lifecycle events for your major application components like Activities and Services will be dispatched to your code. If you're curious as to what's under the hood, sources for both are available:
https://android.googlesource.com/platform/frameworks/base/+/master/core/java/android/os/Looper.java
https://android.googlesource.com/platform/frameworks/base/+/master/core/java/android/os/Handler.java
Updated:
There's really nothing specific being referred to by "Activity is running." The Activity is simply displaying its UI, handling input, executing any necessary functions, and starting another Activity.
If you're interested in what implications multi-threading would have on the run-loop, there isn't really a concrete relationship. Your threads can just do their work, and the Activity's state will function independently and automatically update its UI (provided you call postInvalidate() correctly).
Original:
Take a look at the first diagram on this page: http://developer.android.com/reference/android/app/Activity.html
It specifies the "lifetime" of each Activity and what states it can be in, if that's what you're looking for.