In a scenario where I have a UI that will be updated from a separate thread (using AsyncTask), I can define the AsyncTask as an inner class of the activity, but this has two downsides I find problematic:
It makes the source files very large, reducing efficiency in managing the code
It makes it hard to reuse the thread class
What's a good solution? Use an inner class, but abstract everything it does to other classes? Pass a reference to the Activity to the AsyncTask? Always define the AsyncTask class as an inner class and just accept source files will be large?
First and foremost: when using an AsyncTask you must not do UI activity within doInBackground().
What you can do is - if you want to e.g. update status for a long running background job, is to publishProgress(values) from doInBackground().
The runtime will then for those values call your onProgressUpdate(values) callback, which runs in the UI thread and from where you can update the UI.
Have a look at e.g. https://github.com/pilhuhn/ZwitscherA/blob/master/src/de/bsd/zwitscher/TweetListActivity.java#L336 to see an example.
The AsyncTask can be implemented in an own class file.
Quite a few examples I have seen just pass a Context into the constructor of the AsyncTask.
public class BackgroundStuff extends AsyncTask<Void, Void, Void> {
...
Context mContext;
...
BackgroundStuff(Context context){
super();
this.mContext = context;
}
...
}
I would be interested to hear if anyone else uses any other approaches.
I have a somewhat odd P.O.V with AsyncTasks because I generally prefer using normal Threads, but essentially the way I perform a background task and update a UI is create a Handler at the end of the onCreate() method, I'll then override the handleMessage(Message msg) method.
Then in my Thread, I'll pass the Handler in as a parameter, then when I wish to make an update I'll send a message from the thread to the Handler, now what this does is communicate from the new background thread onto the UI thread to process work on the UI.
Now I imagine AsyncTasks perform a similar task but removes the need to implement override the Handlers' handleMessage method.
It'd be interesting learning more about any advantages / disadvantages between these two approaches.
Related
I am using sockets and im getting data continuously in background using Asynctask.
I send this data to onProgressUpdate() with publishProgress()and I would like to know if there is a way to get the data from function onProgressUpdate() or send it to another class, because where I do need to use this data is in another class. At least, is this possible?
I have a .java, in this .java I have 2 public classes:
First one is a class where I use this Asynctask in background to get socket info.
In the second public class I use OpenGL and I need to use that data.
Thank you
Sure it's possible. You define the type of the array passed between doInBackground() and onProgressUpdate(). You can just publish the progress and consume it that way.
new AsyncTask<...,MyDataObject,...>() {...}.execute();
Alternatively, you can create a publish-subscribe interface between the thread running dIB() and whatever thread is consuming it.
Not that AsyncTask isn't intended to be used for long-running operations. It's meant to be a relatively quick one-shot. You'll need to consider running your task on a dedicated executor so as not to block the one serial executor that's used by default for all other instances of AsyncTask. E.g.,
executeOnExecutor(AsyncTask.THREAD_POOL_EXECUTOR);
Yo can do this with publishProgress() method and you can call this method from doInBackground() and this method can be called at any time when you need to get your data.
Then get data what you want from params and store it in public variable of Asynctask and access it from another class.
This may be work.
I'm refactoring an app I made some time ago. Back then I was taking my first steps into Android and the easy way to go was to avoid orientation changes, for almost all my CRUD operations I used the AsyncTask class, didn't implement a Content Provider or used Fragments.
Now I have made some changes:
I use Fragments to encapsulate functionality
All accesses to my database are done through a Content Provider
I use CursorLoaders to retrieve my data taking advantage of the content observation and automatic background loading the LoaderFramework brings.
The only problem I have now is that I'm not quite sure how to handle the rest of the CRUD operations (Create,Update, and Delete).
I've found that I can use the AsyncQueryHandler class, but there's not enough information online.
One thing I like the Loader Framework, is that is aware of the Activity or Fragment lifecycle, but what about the AsyncQueryHandler?
What happens to the operations that were started with startDelete, startInsert, startUpdate when the Activity/Fragment undergoes a configuration change? Or when I press the back button? Or worse yet, if the activity is destroyed?
What is the expected behavior of this kind of operations in such cases? Should they be cancelled or should they continue to do their work?
All the operations I've mentioned above are not that complex. For real complex operations I've used Services or IntentServices, but since I don't consider a good idea to run SQLite operations on the main thread I want to use a better solution, but first I need to know how that solution should react to the Activity/Fragment lifecycle events.
Any comments or suggestions would me greatly appreciated.
Thanks.
If you use AsyncQueryHandler you have to take into consideration that this abstract wrapper is created and executes provider operations on the thread that it was started on. If you call this from UI thread the callbacks will be sent to the UI thread. If you call this from another working thread, the callbacks will be sent to that working thread.
This is not bound to the lifecycle of the fragment or the activity, ContentProviders don't have an lifecycle.
The AsyncQueryHandler at an basic level, creates an Message object which is added to the MessageQueue of an single background thread. No matter from which activity/fragment you use the AsyncQueryHandler all the Message objects will end up on the same MessageQueue.
Once the background thread processes an request it will send the response back to the instance of the AsyncQueryHandler from which the request was initially made.
My recommendation is to use the Loaders from Android. These are directly tied to the lifecycle of the activity/fragment. You can have multiple Loaders in a LoaderManager(one LoaderManager per activity/fragment) which allows to do more complex operations. Your activity/fragment will automatically be notified when the content has changed(very useful when you want to combine it with your custom methods for CRUD operations or if you need to use long running services). Another very important feature they have is that they will always reconnect to the last Loader, thus you will avoid re-querying your content.
I recommend you search for some tutorials for implementing Loaders in Android. You can start with these:
Loaders - part 1
Loaders - part 2
Loaders - part 3
Loaders - part 4
Answer for your last comments:
I suggest to use the EventBus library (https://github.com/greenrobot/EventBus) to make the communication between your AsyncTasks/Thread and your other components.
You can start by creating an abstract AsyncTask/Thread and on top of that to make your specific command.
For example:
public abstract class AbstractThread extends Thread {
#Override
public void run() {
super.run();
command();
}
abstract void command();
}
In the abstract class you could make some DB initialization, verification or anything else that might make sense for your application.
public class InserTask extends AbstractThread{
#Override
void command() {
//TODO: Add logic for the insert task
}
}
public class UpdateTask extends AbstractThread{
#Override
void command() {
//TODO: Add logic for the update task
}
}
In these specific classes, just add your logic of the CRUD operation.
To have control over these threads, like when they should be stopped, paused, resumed you could create and ThreadPool manager which controls your threads. You can read more how to achieve this here: Thread Pool
I know that AsyncTask are not preferred for long process. Their main objective is to take the load off from UI thread and do stuff in background. Later on completion update the respective UI thread.
I am aware of the memory leaks i.e when UI needs to be updated after doInBackground is done and there's a possibility that the activity is destroyed.
My question is can I use AsyncTask just like a simple Thread?
What happens to AsyncTask if Activity or Application dies, which started it?
Requirments
I dont need to update any UI.
I dont want my task to be associated with Activity(which starts it).
First Question :
Yes you can.Its totally depends on your logic.
Second Question :
The thread will be in the background though the application is killed by the user or by the system.
To resolve the second scenario use the following technique
Just make sure that you are finishing your AsyncTask before application or Activity closes
AsyncTask yourAsyncTask
#Override
public void onDestroy(){
//you may call the cancel() method but if it is not handled in doInBackground() method
if(yourAsyncTask!=null)
if (yourAsyncTask != null && yourAsyncTask.getStatus() != AsyncTask.Status.FINISHED)
yourAsyncTask.cancel(true);
super.onDestroy();
}
If you only need the 'doInBackground' just use a normal thread.
new Thread("threadName", new Runnable(){ #Override run(){ } }).start();
The whole reason to use an AsyncTask is to have the facilities of preExecute and postExecute, so you don't need to mess with handlers.
It remain started in background even the application is killed or crash.
First, a general note, as stated by the Android Docs:
AsyncTasks should ideally be used for short operations (a few seconds at the most). If you need to keep threads running for long periods of time, it is highly recommended you use the various APIs provided by the java.util.concurrent pacakge such as Executor, ThreadPoolExecutor and FutureTask.
To answer your questions:
Yes - you can use Async task as if it were just a background thread - an Async task is merely a wrapper of Thread and Handler that allows the thread to seamlessly communicate with the UI thread. Warning! If you plan to update the UI thread, or otherwise reference an activity or fragment in the callbacks that reference the UI thread (i.e. onProgressUpdated and/or onPostExecute) you should explicitly check that the activity or fragment is still in a state from which it can be referenced and used. For example - here's the right and wrong way to do it when launching an AsyncTask from a fragment:
Create your task with a ref to the activity so you can do something when it's done:
private class DownloadFilesTask extends AsyncTask<URL, Integer, Long> {
Fragment mFragment;
public DownloadFilesTask(Fragment fragment){
mFragment = fragment;
}
WRONG:
protected void onPostExecute(Long result) {
// if the fragment has been detached, this will crash
mFragment.getView().findView...
}
RIGHT:
protected void onPostExecute(Long result) {
if (mFragment !=null && mFragment.isResumed())
... do something on the UI thread ...
}
}
If the Activity dies while an AsyncTask is executed, it will continue to run. Using the techniques listed above, you can avoid crashes by checking the lifecycle of the context that started the task.
Finally, if you have a very long-running operation that does not require the UI thread at all, you should look into using a Service. Here's a blurb:
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
My question is can I use AsyncTask just like a simple Thread?
Yes AsyncTask is android background thread , the task will be done in the background .
AsyncTask automatically creates a new Thread for you, so everything you do in doInBackground() is on another thread.
What happens to AsyncTask if Activity or Application dies, which
started it?
The AsyncTask is related to application , if application destroy or finish then all related AsyncTask of that application will be terminated .
I have a activity with a Listview and a adapter attached to it. I have a class which syncs data and hold it. (I think we should not care about from where data is coming) and it runs on a different thread. Now I want to know the clean way to update adapter but We should not call any function of activity from that class as it runs on different thread.
One way I know is to create handler in activity and pass it to other class and use it from there. But I want to know if activity is in background then activity's function can be called by UI thread or only when activity come in foreground.
I do not want to miss any update and want to update activity when it is in foreground.
If you want to update your listView from another class you can have a few ways to do that.
Send broadcastIntent from your worker class and add BroadcastReceiver to your activity and when you receive the right message, update your listview.
Second way is to create private or public class in your Activity which extends AsyncTask and in your doInBackground() do your work and in onPostExecute(result) update your listview.
Third way which I can imagine, but I don't think it's the best way create a static method is your activity which you can use from any other class for updatiogn your UI.
The best thing which you can use here at least in my opinion is AsyncTask.
this code will do what you want:
runOnUiThread(new Runnable() {
#Override
public void run() {
//your actions
}
});
We should not call any function of activity from that class as it runs on different thread.
That's wrong. (in java an object is not running in a thread. What you can say is that a method is running in the thread from which the method was called)
In Androïd (and in most UI frameworks) the rule is this:
You can only call a method updating UI from the UI thread.
If you have some code running on a thread (not the ui thread) and if that code need to update the UI : you can use the Handler of the UI-thread to post UI update code to the UI-thread. If the activity is not in the foreground when you post something to update it's UI : nevermind! the code you just post will be executed at some point in the future.
You should use AsyncTask, take a look at http://developer.android.com/reference/android/os/AsyncTask.html
Its for the first time I'm making a fairly large app and there are lots of sections in it.
I want to keep UI and background processes in different classes to avoid confusion. However, how do i communicate among them in best possible way. I've come across few approaches till now:
Declaring background thread in different class and defined its onPostExecute() method in UI thread.
new SetupDefaultFeeds(context) {
#Override
protected void onPostExecute(List<Feed> result) {
default_feeds = result;
for (Feed t : result) {
String log = t.toString();
Log.d("DEFAULT feed", log);
}
menu_btn[0].performClick();
}
}.execute();
Signalling using a flag variable between background and UI thread.
Thread and handler.
Are there any other ways and what is the best possible way. Thanks !
Passing messages through a Handler is usually the most "Android-ish" way to do this. Trying to do all communication through flag variables is most likely going to be quite a headache.
Edit: Android itself doesn't provide a way for you to link the two classes together, you need to do that by hand. One way which works quite well is to create an interface for your communication and have either the UI class or background thread implement it. Then, when creating the class, you can pass a reference to the other object and communicate through the interface.
However, if you want to completely decouple the two classes, you might want to use a BroadcastReceiver instead and use it to send messages between the UI and background thread.