To my understanding the point of threading is, mostly, to avoid blocking the UI. The UI should never be unresponsive because an app has the UI thread tied up doing something other than responding to user's actions. (And if the OS detects an app not responding it will pop up a message saying the app is not responding and present an option to Force Close the app!)
I use threading often such that it has become part of the design pattern for the apps. If something is going to take a long time consider pushing it into a child thread. The child thread can then inform results via a Handler to the parent thread. For the game one could conceivably place all the calculations and game area updates on a child thread that is always running (not created and destroyed each time). Then the UI thread could send relevant events to the child thread. I am over-simplifying a complex coding problem, but hopefully it helps. And then then again maybe it does not matter for your game. If the game's calculations are really really fast then the user, and the OS, would never notice the UI thread being unresponsive. But if the calculations begin to bog down the UI thread then child threads are the next thing to look at. Hope this helps, On Nov 12, 8:13 am, Neilz <[email protected]> wrote: > Anyone? This is a common consideration, I would have thought? > > On Nov 11, 10:17 pm, Neilz <[email protected]> wrote: > > > Hi all. I've been reading the developer guide, the sections on > > designing for performance and responsiveness. It's great stuff, and > > I'm going to go through all my code and refactor everything I can to > > meet these suggestions. > > > One line stood out for me: "For games specifically, do calculations > > for moves in a child thread." > > > Could someone possibly elaborate on this a little? If you had a game > > where the screen was being refreshed continuously, with calculations > > being made on every refresh, does this mean starting and ending a > > thread every time this happens? Or is one thread created at the start, > > which stays open for the duration of the game? > > > And would this be an inner class extending Thread with a run() method > > as usual, or are there better ways of handling it? I recently used an > > "AsyncTask" to handle a background task, would that be something that > > could be of use here? > > > Many thanks for any help. -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
