In the Training documentation on Android, Define a Handler on the UI Thread, see this code
private PhotoManager() {
...
/* Instantiates a new anonymous Handler object and defines its handleMessage() method. The Handler *must* run on the UI thread, because it moves photo Bitmaps from the PhotoTask object to the View object. To force the Handler to run on the UI thread, it's defined as part of the PhotoManager constructor. The constructor is invoked when the class is first referenced, and that happens when the View invokes startDownload. Since the View runs on the UI Thread, so does the constructor and the Handler.
*/
mHandler = new Handler(Looper.getMainLooper()) {
...
An ImageView invokes static method PhotoManager.startDownload(ImageView)
passing itself. The image is downloaded on a background thread from a threadpool managed by PhotoManager
.
The Handler
as instantiated above sets imageView to the downloaded image bitmap.
My question is, as the constructor of PhotoManager
ran on UI thread
, since PhotoManager
class is first referenced from the ImageView
(as explained in the comment also), then why is Handler
passed an instance of Main (UI thread) Looper
. That is, instead of
mHandler = new Handler(Looper.getMainLooper()) {
shouldn't the following would have sufficed?
mHandler = new Handler() {
Or is it just to protect against the case where PhotoManager.startDownload()
would have been called from a non-UI thread?