0

I just got started today developing for Android. I tried to make an application that uses a SurfaceView to draw some simple shapes, but couldn't get it working based on menu events (the surface was always invalid), so I decided to implement threads. Now the problem is I can't figure out how to stop a stray thread from running. I started the application in debug mode, then selected the menu item that starts the thread. Then I hit the back button on the emulator's interface to get out of the application. But my breakpoints on the thread continued to be hit. So I went back into the application by clicking on it in the application list in the emulator, and selected the command to stop the thread. But it did not detect that the thread was running -- like it was a different application instance.

There are many subtle questions underneath my main question which is "How should I handle the shut-down of threads in an android application most reliably?"

  1. Can I access the original instance?
  2. Should I have gotten the original instance when I went back in?
  3. Does selecting it from the application menu instead of starting the debugger affect the original instance visibility?
  4. Can/should I terminate the activity/application?
  5. Can the debugger (Eclipse) force it to stop somehow without resetting the whole device?
  6. Does a SurfaceView need threads in order to function rather than trying to lock the context during a menu event?

I looked at Close application and launch home screen on Android but it suggests that applications should not be terminated, so I'm not sure what to do.

Community
  • 1
  • 1
BlueMonkMN
  • 25,079
  • 9
  • 80
  • 146

1 Answers1

0

It sounds like you're trying to use threads in a strange way. In Android, if you're working with the UI, you shouldn't be using vanilla java threads. Instead, you should be using an AsyncTask. If you try to access the UI from a non-UI thread, the Android runtime will complain at you. Instead, you need to pass messages back and forth between your processing threads and your Activities (where you actually manage the UI). This is done with the use of Messengers and Handlers, but the process gets complicated. Instead, a much better solution is to use the AsyncTask model, which will allow you to perform actions in the background which seamlessly update the UI. This is very typically used in things like networking applications, where you download some information in a task, and then update your UI accordingly. So go try reading through a few AsyncTask tutorials and find out all the cool things it can do for you (the hell of dealing with threading headaches in Android is mostly avoided by using this model, and in reality you should never have to fight to kill off a thread).

Kristopher Micinski
  • 7,572
  • 3
  • 29
  • 34
  • So are the examples delivered with the Android SDK bad then? I'm looking at the Lunar Lander sample, with uses a simple Thread with a SurfaceView. – BlueMonkMN Feb 27 '12 at 14:07
  • http://developer.android.com/resources/articles/painless-threading.html is probably what you want to check out. – Kristopher Micinski Feb 27 '12 at 15:11
  • According to the intro paragraph, that article is about long running worker threads interacting with the UI whereas I am trying to figure out how to draw graphics on a SurfaceView, which also seems to rely on threads, but not what I would consider worker threads, and not what I would consider UI interaction. Am I splitting hairs? – BlueMonkMN Feb 28 '12 at 11:56
  • I'm dumb, I forgot, drawing on a SurfaceView requires writing your own extended SurfaceView and then implementing its onDraw method. – Kristopher Micinski Feb 28 '12 at 15:10