tags:

views:

142

answers:

3

Hello! I'm really confused about this, but when I'm trigging a thread from my SurfaceView, im sending a Handler with the constructor like this

private static Thread thread;

public SurfaceView(Context localContext) {
      //other stuff
      thread = new Thread(mySurfaceHolder, myEngine, this, new Handler());
      //other stuff
}

and in my thread-class I assign a Handler-object with the handler I sent from my view, like this:

    public Thread (SurfaceHolder lHolder,
    Engine lEngine,
    View lView,
    Handler lHandler){

    surfaceHolder = lHolder;
    engine = lEngine;
    view = lView;
    handler = lHandler;

}

So what does this Handler do? I never use it in my thread-class in any ways, so why are the examples on the web still showing me that I should send a handler with the constructor? I can't see the connection....

Thanks in advance!

+3  A: 

From the Handler docs:

When a process is created for your application, its main thread is dedicated to running a message queue that takes care of managing the top-level application objects (activities, broadcast receivers, etc) and any windows they create. You can create your own threads, and communicate back with the main application thread through a Handler. This is done by calling the same post or sendMessage methods as before, but from your new thread. The given Runnable or Message will than be scheduled in the Handler's message queue and processed when appropriate.

http://developer.android.com/intl/zh-TW/reference/android/os/Handler.html

Usually it is needed to communicate from your threads back to UI in case you need to execute some code which should run strictly on UI thread.

Konstantin Burov
Okey, but then I have no use for this (in my application)? And which sort of code do I need the handler to execute in the UI?
Julian Assange
For example Toasts and Dialogs can be shown from the UI thread only. I bet there are other cases.
Konstantin Burov
+2  A: 

I assume in your code you are extending Thread, because there is no constructor taking a handler for the Thread class. The handler is used to communicate back to the UI thread, as the Android threading model requires UI operations to be performed on a special dedicated thread.

When creating a new thread, the code is executed in a background thread, and thus UI-operations are unsafe. If you do not need to do anything UI-related, you can remove the handler.

Since Android API 3, there is AsyncTask, which makes communication between background and UI easier and alleviates the need to use a handler.

Examples:

  • For an example of using a Handler, see this.
  • See Painless Threading as well, which contains links to sample projects using threading.
JRL
Okey. The Thread-class extends Thread of course. :) Can you provide any example there I do anything UI-related, just for better knowledge?
Julian Assange
@Julien Assange: see my edit for an example.
JRL
Ok, so this is for example a way to update (in Game-coding perspectives) the score with help from the handler?
Julian Assange
@Julien Assange: it's to access anything that is visible to the user. If the score is displayed in a TextView, updating the textview needs to be done on the UI-thread. Another example is displaying a ProgressDialog.
JRL
Okay, thanks for the answer! :-) Now accepted! Maybe I will comment here about this, it's depending how it goes with this thing.
Julian Assange
+2  A: 

Just define your handler in the main activity, as a global.

Handler mUIHandler = new Handler();

And now you can post to the mUIHandler immediately and it always goes to your UI thread.

Brad Hein
I still have no idea how this can be useful? In which situation? Sorry, but I haven't get this at all. :-)
Julian Assange
No problem, it's a mind bender, really. Say you have a thread that downloads stuff. To display that stuff you may want the downloader thread to display stuff on the screen. To do that, you have to post the changes to the main UI thread, you can't make those changes from the downloader thread. Does that help?
Brad Hein
Put another way, a Handler executes the "runnable" which you post to it. It does so on the main UI thread. You define the runnable which, say for example updates the text or progress bar on the screen. The handler accepts that runnable and executes it. The UI thread affects the user's experience, so doing too much stuff in it is detrimental to the user experience.
Brad Hein