And you shouldn't be doing this. You could have a static pointing to the currently running activity instance (which very well may be null, which is a valid state, and something your thread needs to deal with anyway). Often you do this by giving the thread just a Handler to communicate back with the main thread, which the activity implements as a static along with a static of the current activity instance. So your thread posts a message to display a dialog, and then on the main thread you get that message and handle it on whichever activity instance is the current one.
On Sun, Aug 30, 2009 at 4:10 PM, CraigsRace <craig...@gmail.com> wrote: > > Mark: Sorry, I deleted my original post (very rude, I know!), as I > decided to just go ahead and write a solution myself (see previous > post). > > As for starting multiple threads, yes, they will hold on to the old > Activities. However, that's what happens right now, no? In fact, > that's the whole problem, when the threads try to do UI, they are > referring to the old activities. > > > On Aug 31, 8:26 am, Mark Murphy <mmur...@commonsware.com> wrote: > > CraigsRace wrote: > > > I'm obviously missing something, as I thought the Thread would be the > > > only thing holding onto the old Activity (as it is now). When the > > > Thread dies, the old activity would be garbage collected (as it does > > > now). All forwarding would be done via the Activity class. > > > > Correct, but what Ms. Hackborn wrote was: > > > > > > > > >> And that still means it needs to keep the old activity around so the > > thread > > >> can use it. > > > > So, given that, imagine this scenario: > > > > -- Activity instance A starts > > -- You fork a background thread, holding onto A, that will run for 30 > > seconds, as a result of a button click > > -- At 0:02 into the thread, the user rotates the screen > > -- Android creates a new activity instance (B), and has A point to B for > > the purposes of your call forwarding stuff > > -- At 0:05 into the first thread, you fork another thread, holding onto > > B, that will run for 30 seconds, as a result of a button click > > -- At 0:07 into the thread, the user rotates the screen again (bear in > > mind that for non-QWERTY devices, it doesn't take much to cause the > > screen to rotate) > > -- Android creates a new activity instance (C), and has B point to C for > > the purposes of your call forwarding stuff > > > > At this point, we have three total instances of the activity running (A, > > B, C), and we still have 23 seconds of the original 30 to work with. > > Factor in the possibility of developers having threads that run for 30 > > days instead of 30 seconds. > > > > In your specific example, coded properly, the forwarding mechanism may > > work fine, if your thread is very short lived (a couple of seconds), > > won't get started again, and your activities are not terribly complex. > > It's when you start to violate those assumptions (coded improperly, > > lotsa threads, long threads, complex activities) that memory issues > > become more painful. > > > > -- > > Mark Murphy (a Commons Guy)http://commonsware.com| > http://twitter.com/commonsguy > > > > Warescription: Three Android Books, Plus Updates, $35/Year > > > -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~----------~----~----~----~------~----~------~--~---
