Académique Documents
Professionnel Documents
Culture Documents
Threads: Android supports the usage of the Threads class to perform asynchronous processing. Android also supplies the java.util.concurrent package to perform something in the
background, e.g. using the ThreadPools and Executor classes. If you need to update the user interface from a new Thread, you need to synchronize with the user interface thread.
You can use the android.os.Handler class or the AsyncTasks class for this.
Handler:
The Handler class can update the user interface. A Handler provides methods for receiving instances of the Message or Runnable class.
To use a handler you have to subclass it and override the handleMessage() to process messages. To process a Runnable you can use the post() method. You only need one instance of a
Handler in your Activity. You thread can post messages via the sendMessage(Message msg) method or via the sendEmptyMessage() method.
AsyncTask:
The AsyncTask class encapsulates the creation of Threads and Handlers. An AsyncTask is started via the execute() method. The execute() method calls the doInBackground() and the
onPostExecute() method. The doInBackground() method contains the coding instruction which should be performed in a background thread. This method runs automatically in a
separate Thread. The onPostExecute() method synchronize itself again with the user interface thread and allows to update it. This method is called by the framework once the
doInBackground() method finishes.
To use AsyncTask you must subclass it. AsyncTask uses generics and varargs. The parameters are the following AsyncTask . TypeOfVarArgParams is passed into the doInBackground()
method as input, ProgressValue is used for progress information and ResultValue must be returned from doInBackground() method and is passed to onPostExecute() as parameter.
Feedback via ProgressBar
For providing feedback to the user you can use the ProgressBar dialog, which allow to display progress to the user. The Javadoc of ProgressBar gives a nice example of its usage.
Alternatively you can provide progress feedback in the activities title bar.
Concurrency and lifecyle
One challenge in using threads is to consider the lifecycle of the application. The Android system may kill your activity or trigger a configuration change which also will restart your
activity. You also need to handle open dialogs, as dialogs are always connected to the activity which created them. In case the activity gets restarted and you access an existing dialog
you receive an View not attached to window manager exception. To save an object your can use the method onRetainNonConfigurationInstance() method. This method allows to
save one object if the activity will be soon restarted. To retrieve this object you can use the getLastNonConfigurationInstance() method. This way can you can save an object, e.g. a
running thread, even if the activity is restarted.
Threads are the cornerstone of any multitasking operating system and can be thought of as mini-processes running within a main process, the purpose of which is to enable at least
the appearance of parallel execution paths within applications. When an Android application is first started, the runtime system creates a single thread in which all application
components will run by default. This thread is generally referred to as the main thread.
The primary role of the main thread is to handle the user interface in terms of event handling and interaction with views in the user interface. Any additional components that are
started within the application will, by default, also run on the main thread.
When an Android application is first started, the runtime system creates a single thread in which all application components will run by default. This thread is generally referred to
as the main thread. The primary role of the main thread is to handle the user interface in terms of event handling and interaction with views in the user interface. Any additional
components that are started within the application will, by default, also run on the main thread.
When an Android application is first started, the runtime system creates a single thread in which all application components will run by default. This thread is generally referred to
as the main thread. The primary role of the main thread is to handle the user interface in terms of event handling and interaction with views in the user interface. Any additional
components that are started within the application will, by default, also run on the main thread.
In order to create a new thread, the code to be executed in that thread needs to be placed within the Run() method of a Runnable instance. A new Thread object then needs to be
created, passing through a reference to the Runnable instance to the constructor. Finally, the start() method of the thread object needs to be called to start the thread running. To
perform the task within the buttonClick() method, therefore, the following changes need to be made:
When the application is now run, touching the button causes the delay to
be performed in a new thread leaving the main thread to continue handling
the user interface, including responding to additional button presses. In fact,
each time the button is touched, a new thread will be created, allowing the
task to be performed multiple times concurrently.
As previously stated, updating a user interface element from within a thread
other than the main thread violates a key rule of Android development.
In order to update the user interface, therefore, it will be necessary to
implement a Handler for the thread.
Im p le m e n t in g a T h re a d H a n d le r
Thread handlers are implemented in the main thread of an application and are primarily used to make updates to the user interface in response to messages sent by another thread
running within the applications process.
Note that the only change that has been made is to make a call to the sendEmptyMessage() method of the handler. Since the handler does not currently do anything with
the content of any messages it receives it is not necessary to create and send a message object to the handler.
Messages can contain data and are processed by handleMessage() method. Runnable objects can be enqueued in a Threads message queue to be executed.
Methods using Message start with send, methods for Runnable objects start with post.
Methods for Messages/Runnables that are processed delayed postAtTime(), postDelayed(), sendMessageAtTime(), sendMessageDelayed().
SERVICES
The Android Service class is designed specifically to allow applications to initiate and perform background tasks. Unlike broadcast receivers, which are intended to perform a task
quickly and then exit, services are designed to perform tasks that take a long time to complete (such as downloading a file over an internet connection or streaming music to the
user) but do not require a user interface.
Started Services:
Started services are launched by other application components (such as an activity or even a broadcast receiver) and potentially run indefinitely in the background until the service
is stopped, or is destroyed by the Android runtime system in order to free up resources. A service will continue to run if the application that started it is no longer in the foreground,
and even in the event that the component that originally started the service is destroyed.
By default, a service will run within the same main thread as the application process from which it was launched (referred to as a local service). It is important, therefore, that any
CPU intensive tasks be performed in a new thread within the service. Instructing a service to run within a separate process (and therefore known as a remote service) requires a
configuration change within the manifest file. Unless a service is specifically configured to be private (once again via a setting in the manifest file), that service can be started by
other components on the same Android device. This is achieved using the Intent mechanism in the same way that one activity can launch another as outlined in preceding
chapters.
Started services are launched via a call to the startService() method, passing through as an argument an Intent object identifying the service to be started. When a started service
has completed its tasks, it should stop itself via a call to stopSelf(). Alternatively, a running service may be stopped by another component via a call to the stopService() method,
passing through as an argument the matching Intent for the service to be stopped.
Services are given a high priority by the Android system and are typically amongst the last to be terminated in order to free up resources.
Intent Service
The IntentService class is a convenience class (subclassed from the Service class) that sets up a worker thread for handling background tasks and handles each request in an
asynchronous manner. Once the service has handled all queued requests, it simply exits. All that is required when using the IntentService class is that the onHandleIntent() method
be implemented containing the code to be executed for each request.
For services that do not require synchronous processing of requests, IntentService is the recommended option. Services requiring synchronous handling of requests will, however,
need to subclass from the Service class and manually implement and manage threading to handle any CPU intensive tasks efficiently.
Bound Service
A bound service is similar to a started service with the exception that a started service does not generally return results or permit interaction with the component that launched it.
A bound service, on the other hand, allows the launching component to interact with, and receive results from, the service. Through the implementation of interprocess
communication (IPC), this interaction can also take place across process boundaries. An activity might, for example, start a service to handle audio playback. The activity will, in all
probability, include a user interface providing controls to the user for the purpose of pausing playback or skipping to the next track. Similarly, the service will quite likely need to
communicate information to the calling activity to indicate that the current audio track has completed and to provide details of the next track that is about to start playing.
A component (also referred to in this context as a client) starts and binds to a bound service via a call to the bindService() method and multiple components may bind to a service
simultaneously. When the service binding is no longer required by a client, a call should be made to the unbindService() method. When the last bound client unbinds from a
service, the service will be terminated by the Android runtime system. It is important to keep in mind that a bound service may also be started via call to startService(). Once
started, components may then bind to it via bindService() calls. When a bound service is launched via a call to startService() it will continue to run even after the last client unbinds
from it.
A bound service must include an implementation of the onBind() method which is called both when the service is initially created and when other clients subsequently bind to the
running service. The purpose of this method is to return to binding clients an object of type IBinder containing the information needed by the client to communicate with the
service.
In terms of implementing the communication between a client and a bound service, the recommended technique depends on whether the client and service reside in the same
or different processes and whether or not the service is private to the client. Local communication can be achieved by extending the Binder class and returning an instance from
the onBind() method. Interprocess communication, on the other hand, requires Messenger and Handler implementation.
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.
A service can essentially take two forms:
Started A service is started when an application component (such as an activity) starts it by calling startService(). Once started, a service can run in the background indefinitely,
even if the component that started it is destroyed. Usually, a started service performs a single operation and does not return a result to the caller. For example, it might download or
upload a file over the network. When the operation is done, the service should stop itself.
Bound A service is bound when an application component binds to it by calling bindService(). A bound service offers a client-server interface that allows components to interact
with the service, send requests, get results, and even do so across processes with interprocess communication (IPC). A bound service runs only as long as another application
component is bound to it. Multiple components can bind to the service at once, but when all of them unbind, the service is destroyed.
To create a service, you must create a subclass of Service (or one of its existing subclasses). In your implementation, you need to override some callback methods that handle key
aspects of the service lifecycle and provide a mechanism for components to bind to the service, if appropriate. The most important callback methods you should override are:
onStartCommand() The system calls this method when another component, such as an activity, requests that the service be started, by calling startService(). Once this method
executes, the service is started and can run in the background indefinitely. If you implement this, it is your responsibility to stop the service when its work is done, by calling
stopSelf() or stopService(). (If you only want to provide binding, you dont need to implement this method.)
onBind() The system calls this method when another component wants to bind with the service (such as to perform RPC), by calling bindService(). In your implementation of this
method, you must provide an interface that clients use to communicate with the service, by returning an IBinder. You must always implement this method, but if you dont want to
allow binding, then you should return null.
onCreate() The system calls this method when the service is first created, to perform one-time setup procedures (before it calls either onStartCommand() or onBind()). If the
service is already running, this method is not called.
onDestroy() The system calls this method when the service is no longer used and is being destroyed. Your service should implement this to clean up any resources such as threads,
registered listeners, receivers, etc. This is the last call the service receives.
If a component starts the service by calling startService() (which results in a call to onStartCommand()), then the service remains running until it stops itself with stopSelf() or
another component stops it by calling stopService().
If a component calls bindService() to create the service (and onStartCommand() is not called), then the service runs only as long as the component is bound to it. Once the service is
unbound from all clients, the system destroys it.
A service is a component which runs in the background, without direct interaction with the user. The Android platform provides and runs predefined system services and every
Android application can use them, given the right permissions. An Android application can, in addition to consuming the existing Android platform services, define and use new
services. The Android platform provides pre-defined services, usually exposed via a specific Manager class. Access to them can be gained via the getSystemService() method.
Services run with a higher priority than inactive or invisible activities and therefore it is less likely that the Android system terminates them. Defining your own services allows you to
design very responsive applications. You can fetch the application via a service and once the application is started by the user, it can present fresh data to the user
A service needs to be declared in the AndroidManifest.xml and the implementing class must extend the Service class or one of its subclasses
A service runs by default in the same process as
the application. in its own thread. Therefore you
need to use asynchronous processing in the
service to to perform resource intensive tasks in
the background.
You can also specify that your Service runs in a
separate process via the
android:process=:process_description attribute.
Running a service in its own process gives it its
own memory address space and a garbage
collector of the virtual machine in this process
does not affect the application process.
Running a services in its own process make the
communication of the other Android components
and the service harder to implement.
Starting services
An Android component (service, receiver, activity) can start and trigger a service via
the startService(intent) method. This method call starts the service if it is not running.
If the service started the onCreate() method is called.
Once the service is started the method call to start the service triggers startService(intent) method in the service. It passes in the Intent for the startService(intent) call.
If startService(intent) is called while the service is running, its onStartCommand() is also called. Therefore your service needs to be prepared that onStartCommand() can be called
several times. This method is called in the main user interface thread therefore it cannot be called simultaneously from two different threads.
Alternatively to startService(intent) you can also start a service via the bindService() method call. This allows you to communicate directly with the service.
Stopping a service:
You stop a service via the stopService() method. No matter how frequently you started the service with startService(intent) a call to stopService() stops it. A service can stop itself by
calling the stopSelf() method.
Binding between activities and local services:
If the activity wants to interact with the service it can use the bindService() method to start the service. This method requires as parameter a ServiceConnection object which allows
to connect to the service. In the service the onBind() method is called. This method returns a IBinder object to the ServiceConnection.
This IBinder object can be used by the activity to communicate with the service. Afterwards the binding was done the onStartCommand() method is called with the Intent data
provided by the activity.
startService() also allows you to provide a flag which determines the restart behavior of the services. Service.START_STICKY is used for services which are explicit started or stopped. If
these services are terminated by the Android system, they are restarted if sufficient resource are available again. Services started with Service.START_NOT_STICKY are not
automatically restarted if terminated by the Android system.
As with activities the Android system may terminate the process of a service at any
time to save resources. For this reason you cannot simple use a TimerTask in the
service to ensure that it is executed on a regular basis.
For correct scheduling of the Service use the AlarmManager class.
There are several way for an activity to communicate with an service and vice versa. This section dicusses the different ways and gives recommendation which to use
Broadcast Receivers
Starting a Service
You can start a service from an activity or other application
component by passing an Intent (specifying the service to
start) to startService(). The Android system calls the services
onStartCommand() method and passes it the Intent. (You
should never call onStartCommand() directly.)The startService
() method returns immediately and the Android system calls
the services onStartCommand() method. If the service is not
already running, the system first calls onCreate(), then calls
onStartCommand().
Stopping a service
A started service must manage its own lifecycle. That is, the
system does not stop or destroy the service unless it must
recover system memory and the service continues to run
after onStartCommand() returns. So, the service must stop
itself by calling stopSelf() or another component can stop it
by calling stopService. You can use stopSelf(int) to ensure that
your request to stop the service is always based on the most
recent start request. That is, when you call stopSelf(int), you
pass the ID of the start request (the startId delivered to
onStartCommand()) to which your stop request corresponds.
Bound Services
A bound service is an implementation of the Service class that allows other applications to bind to it and interact with it. To provide binding for a service, you must implement the
onBind() callback method. This method returns an IBinder object that defines the programming interface that clients can use to interact with the service.
A client can bind to the service by calling bindService(). When it does, it must provide an implementation of ServiceConnection, which monitors the connection with the service. The
bindService() method returns immediately without a value, but when the Android system creates the connection between the client and service, it calls onServiceConnected() on
the ServiceConnection, to deliver the IBinder that the client can use to communicate with the service.
Multiple clients can connect to the service at once. However, the system calls your services onBind() method to retrieve the IBinder only when the first client binds. The system then
delivers the same IBinder to any additional clients that bind, without calling onBind() again.
When the last client unbinds from the service, the system destroys the service (unless the service was also started by startService()).
When you implement your bound service, the most important part is defining the interface that your onBind() callback method returns. There are a few different ways you can define
your services IBinder interface and the following section discusses each technique.
When creating a service that provides binding, you must provide an IBinder that provides the programming interface that clients can use to interact with the service. There are three
ways you can define the interface:
Extending the Binder class
If your service is private to your own application and runs in the same process as the client (which is common), you should create your interface by extending the Binder class and
returning an instance of it from onBind(). The client receives the Binder and can use it to directly access public methods available in either the Binder implementation or even the
Service. This is the preferred technique when your service is merely a background worker for your own application. The only reason you would not create your interface this way is
because your service is used by other applications or across separate processes.
Using a Messenger
If you need your interface to work across different processes, you can create an interface for the service with a Messenger. In this manner, the service defines a Handler that responds
to different types of Message objects. This Handler is the basis for a Messenger that can then share an IBinder with the client, allowing the client to send commands to the service
using Message objects. Additionally, the client can define a Messenger of its own so the service can send messages back.
This is the simplest way to perform interprocess communication (IPC), because the Messenger queues all requests into a single thread so that you dont have to design your service
to be thread-safe.
Using AIDL
AIDL (Android Interface Definition Language) performs all the work to decompose objects into primitives that the operating system can understand and marshall them across
processes to perform IPC. The previous technique, using a Messenger, is actually based on AIDL as its underlying structure. As mentioned above, the Messenger creates a queue of all
the client requests in a single thread, so the service receives requests one at a time. If, however, you want your service to handle multiple requests simultaneously, then you can use
AIDL directly. In this case, your service must be capable of multi-threading and be built thread-safe.
To use AIDL directly, you must create an .aidl file that defines the programming interface. The Android SDK tools use this file to generate an abstract class that implements the
interface and handles IPC, which you can then extend within your service.
Note: Most applications should not use AIDL to create a bound service, because it may require multithreading capabilities and can result in a more complicated implementation. As
such, AIDL is not suitable for most applications and this document does not discuss how to use it for your service. If youre certain that you need to use AIDL directly, see the AIDL
document.
methods the client can call
2. Return this instance of Binder from the onBind() callback method.
3. In the client, receive the Binder from the onServiceConnected() callback
method and make calls to the bound service using the methods provided.
For example, heres a service that provides clients access to methods
in the service through a Binder implementation:
Started Service
Bound Service
By default thread doesnt have a message queue. To create a message queue and bind it
to the current thread we can use Looper.prepare(). To start a loop which runs to read and
process the messages or runnable objects, we use Looper.loop().
Handler Is bound to the looper(remember as message queue) of the current thread by
default.
After that, you can just pass the handler to any other thread. It has a thread-safe interface that includes many
operations, but the most straightforward ones are postMessage() and its relatives.
Note: The Handler interface has many more cool operations, especially related to message
For example, imagine another thread has a reference to the handler that was created in our Pipeline Thread.
Heres how that other thread can schedule an operation to be executed in the Pipeline Thread:
In our case, we will use this idiom to schedule download tasks to be performed (on the download pipeline
thread) when the user clicks a button (which is handled on the UI thread). We will also use it the other way
around when the download thread notifies the activity that a download has completed (on the download
thread), the activity will use a Handler that is attached to the UI thread to make sure that we update the UI on
the UI thread only (which is a requirement of Android UI).
At this point, however, we need to use another Handler the one that is attached to
the UI thread. The DownloadThreadListener is notified by the DownloadThread
from the download thread itself, but the action we want to take (updating the
progressbar and the textview) needs to be done from the UI thread. Therefore we
use the UI handler like this:
WHEN TO USE?