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?

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
-~----------~----~----~----~------~----~------~--~---

Reply via email to