Can you explain how to stop the android framework from destroying and re-creating the activity on a layout change?
On Aug 31, 11:24 am, Marco Nelissen <marc...@android.com> wrote: > On Mon, Aug 31, 2009 at 6:06 AM, ReubenH<reuben.har...@gmail.com> wrote: > > > Having used Android for 4 months, and now having a game doing well in > > the market, I am still wondering why a rotation change results in > > Activity creation / destruction in the first place? It has never made > > sense... why not an onLayoutChanged() type of event instead? > > You can have this too, if that's what you want. You can specify in > your manifest which configuration changes your activity can handle > itself, and you will see your Activity.onConfigurationChanged() called > when such a configuration change happens. > Note however that in that case your activity is responsible for > handling the configuration change, e.g. loading a new layout and > resources if needed, updating all the references your app has to > buttons, lists and other widgets, etc. > > > > > It seems wasteful and counterintuitive to create new activities when > > the activity hasn't actually changed... > > > I'd love to know the reason for it, am sure I am probably missing > > something obvious. > > > Thanks, > > > -- Reuben > > > On Aug 31, 2:39 am, CraigsRace <craig...@gmail.com> wrote: > >> Dianne: Yes, using a static Handler is a solution. Although, IMO, > >> it's not the most eloquent solution. But it will work, so I should be > >> happy. :) > > >> On Aug 31, 11:19 am, Dianne Hackborn <hack...@android.com> wrote: > > >> > 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 -~----------~----~----~----~------~----~------~--~---
