Lập trình Androi part 23 pdf

Override one or more AsyncTask methods to accomplish the background work, plus whatever work associated with the task that needs to be done on the UI thread e.g., update progress.. Async

Override one or more AsyncTask methods to accomplish the background work, plus whatever work associated with the task that needs to be done on the UI thread (e.g., update progress)

When needed, create an instance of the AsyncTask subclass and call execute() to have it begin doing its work

What you do not need to do is:

Create your own background thread

Terminate that background thread at an appropriate time

Call all sorts of methods to arrange for bits of processing to be done

on the UI thread

AsyncTask, Generics, and Varargs

Creating a subclass of AsyncTask is not quite as easy as, say, implementing the

Runnable interface AsyncTask uses generics, and so you need to specify three data types:

The type of information that is needed to process the task (e.g., URLs

to download)

The type of information that is passed within the task to indicate progress

The type of information that is passed when the task is completed to the post-task code

What makes this all the more confusing is that the first two data types are actually used

as varargs, meaning that an array of these types is used within your AsyncTask subclass This should become clearer as we work our way toward an example

The Stages of AsyncTask

There are four methods you can override in AsyncTask to accomplish your ends

The one you must override, for the task class to be useful, is doInBackground() This will

be called by AsyncTask on a background thread It can run as long as necessary in order

to accomplish whatever work needs to be done for this specific task Note, though, that tasks are meant to be finite; using AsyncTask for an infinite loop is not recommended The doInBackground() method will receive, as parameters, a varargs array of the first of the three data types listed in the preceding section—the data needed to process the task So, if your task’s mission is to download a collection of URLs, doInBackground() will receive those URLs to process The doInBackground() method must return a value

of the third data type listed—the result of the background work

You may wish to override onPreExecute() This method is called, from the UI thread,

before the background thread executes doInBackground() Here, you might initialize a

ProgressBar or otherwise indicate that background work is commencing

Also, you may wish to override onPostExecute() This method is called, from the UI

thread, after doInBackground() completes It receives, as a parameter, the value

returned by doInBackground() (e.g., success or failure flag) Here, you might dismiss the

ProgressBar and make use of the work done in the background, such as updating the

contents of a list

In addition, you may wish to override onProgressUpdate() If doInBackground() calls the

task’s publishProgress() method, the object(s) passed to that method are provided to

onProgressUpdate(), but in the UI thread That way, onProgressUpdate() can alert the

user as to the progress that has been made on the background work, such as updating

a ProgressBar or continuing an animation The onProgressUpdate() method will receive

a varargs of the second data type from the list in the preceding section—the data

published by doInBackground() via publishProgress()

A Sample Task

As mentioned earlier, implementing an AsyncTask is not quite as easy as implementing a

Runnable However, once you get past the generics and varargs, it is not too bad

For example, the following is an implementation of a ListActivity that uses an

AsyncTask, from the Threads/Asyncer sample project:

package com.commonsware.android.async;

import android.app.ListActivity;

import android.os.AsyncTask;

import android.os.Bundle;

import android.os.SystemClock;

import android.widget.ArrayAdapter;

import android.widget.Toast;

import java.util.ArrayList;

public class AsyncDemo extends ListActivity {

private static String[] items={"lorem", "ipsum", "dolor",

"sit", "amet", "consectetuer",

"adipiscing", "elit", "morbi",

"vel", "ligula", "vitae",

"arcu", "aliquet", "mollis",

"etiam", "vel", "erat",

"placerat", "ante",

"porttitor", "sodales",

"pellentesque", "augue",

"purus"};

@Override

public void onCreate(Bundle savedInstanceState) {

super.onCreate(savedInstanceState);

setContentView(R.layout.main);

setListAdapter(new ArrayAdapter<String>(this,

android.R.layout.simple_list_item_1,

new ArrayList()));

new AddStringTask().execute();

}

class AddStringTask extends AsyncTask<Void, String, Void> {

@Override

protected Void doInBackground(Void unused) {

for (String item : items) {

publishProgress(item);

SystemClock.sleep(200);

}

return(null);

}

@Override

protected void onProgressUpdate(String item) {

((ArrayAdapter)getListAdapter()).add(item[0]);

}

@Override

protected void onPostExecute(Void unused) {

Toast

.makeText(AsyncDemo.this, "Done!", Toast.LENGTH_SHORT)

.show();

}

}

}

This is another variation on the lorem ipsum list of words, used frequently throughout

this book This time, rather than simply hand the list of words to an ArrayAdapter, we simulate needing to work to create these words in the background using AddStringTask, our AsyncTask implementation

If you build, install, and run this project, you will see the list being populated in real time over a few seconds, followed by a Toast indicating completion, as shown in Figure 15–2

Figure 15–2 The AsyncDemo, partway through loading the list of words

Let’s examine this project’s code piece by piece

The AddStringTask Declaration

First, let’s look at the AddStringTask declaration:

class AddStringTask extends AsyncTask<Void, String, Void> {

Here, we use the generics to set up the specific types of data we are going to leverage

in AddStringTask, as follows:

We do not need any configuration information in this case, so our first

type is Void

We want to pass each string generated by our background task to

onProgressUpdate(), to allow us to add it to our list, so our second

type is String

We do not have any results, strictly speaking (beyond the updates), so

our third type is Void

The doInBackground() Method

Next up is the doInBackground() method:

@Override

protected Void doInBackground(Void unused) {

for (String item : items) {

publishProgress(item);

SystemClock.sleep(200);

}

return(null);

}

The doInBackground() method is invoked in a background thread Hence, we can take

as long as we like In a production application, we might be doing something like

iterating over a list of URLs and downloading each Here, we iterate over our static list of

lorem ipsum words, call publishProgress() for each, and then sleep 1/4 second to

simulate real work being done

Since we elected to have no configuration information, we should not need parameters

to doInBackground() However, the contract with AsyncTask says we need to accept a

varargs of the first data type, which is why our method parameter is Void unused

Since we elected to have no results, we should not need to return anything Again,

though, the contract with AsyncTask says we must return an object of the third data type

Since that data type is Void, our returned object is null

The onProgressUpdate() Method

The onProgressUpdate() method looks like this:

@Override

protected void onProgressUpdate(String item) {

((ArrayAdapter)getListAdapter()).add(item[0]);

}

The onProgressUpdate() method is called on the UI thread, and we want to do something

to let the user know we are making progress on loading these strings In this case, we simply add the string to the ArrayAdapter, so it is appended to the end of the list

The onProgressUpdate() method receives a String varargs because that is the second data type in our class declaration Since we are passing only one string per call

to publishProgress(), we need to examine just the first entry in the varargs array

The onPostExecute() Method

Here’s the onPostExecute() method:

@Override

protected void onPostExecute(Void unused) {

Toast

.makeText(AsyncDemo.this, "Done!", Toast.LENGTH_SHORT)

.show();

}

The onPostExecute() method is called on the UI thread, and we want to do something to indicate that the background work is complete In a real system, there may be some ProgressBar to dismiss or some animation to stop Here, we simply raise a Toast Since we elected to have no results, we should not need any parameters The contract with AsyncTask says we must accept a parameter of the third data type Since that data type is Void, our method parameter is Void unused

The Activity

Finally, let’s look at the activity:

new AddStringTask().execute();

To use AddStringsTask, we simply create an instance and call execute() on it That starts the chain of events eventually leading to the background thread doing its work

If AddStringsTask required configuration parameters, we would not have used Void as our first data type, and the constructor would accept zero or more parameters of the defined type Those values would eventually be passed to doInBackground()

And Now, the Caveats

Background threads, while eminently possible using the Android Handler system, are not all happiness and warm puppies Background threads not only add complexity, but they also have real-world costs in terms of available memory, CPU, and battery life

Hence, there are a wide range of scenarios you need to account for with your

background thread, including the following:

The possibility that users will interact with your activity’s UI while the

background thread is chugging along If the work that the background

thread is doing is altered or invalidated by the user input, you will need

to communicate this to the background thread Android includes many

classes in the java.util.concurrent package that will help you

communicate safely with your background thread

The possibility that the activity will be killed off while background work

is occurring For example, after starting your activity, the user might

have a call come in, followed by a text message, followed by a need to

look up a contact—all of which might be sufficient to kick your activity

out of memory Chapter 16 will cover the various events Android will

take your activity through Hook to the proper ones, and be sure to

shut down your background thread cleanly when you have the chance

The possibility that your user will get irritated if you chew up a lot of

CPU time and battery life without giving any payback Tactically, this

means using ProgressBar or other means of letting the user know that

something is happening Strategically, this means you still need to be

efficient at what you do—background threads are no panacea for

sluggish or pointless code

The possibility that you will encounter an error during background

processing For example, if you are gathering information from the

Internet, the device might lose connectivity Alerting the user of the

problem via a notification (discussed in Chapter 31) and shutting down

the background thread may be your best option