Yes, it's really an important point we should notice in multiple
thread programming in Android. Maybe you should declare this in your
published SDK.

Thanks,

Stanley

On Jan 24, 5:04 am, "James Patillo" <ja...@patillo.org> wrote:
> Excellent, thanks for the explanation Dianne.
>
> From: Dianne Hackborn [mailto:hack...@android.com]
> Sent: Friday, January 23, 2009 2:07 PM
> To: android-developers@googlegroups.com
> Subject: [android-developers] Re: Activity Issue on G1 phone
>
> There are two reasons for this:
>
> 1. Both screen rotation and keyboard shown/hidden are configuration changes,
> which means that after the state changes the application's resources can
> have any arbitrary new values -- anything from specific strings (for ex in a
> particular language you may need a abbreviation when in portrait mode) to
> layout resources and anything else.  Trying to keep track of, and update,
> any of these values that could have changed would require a lot of work in
> the system, and a fair amount of effort from the developer to help the
> system, so it is far easier to just restart the entire activity with the new
> configuration.
>
> 2. To be a correct application, you already need to deal with saving and
> restoring state so you will always be returned to the user in your previous
> state after being in the background.  By relying on this same mechanism for
> configuration changes, we get to take advantage of the work the developer
> has already done, and also further encourage them to actually do that work
> which otherwise often only causes problems in the application in obscure
> cases, so can often be missed.
>
> For the case of a thread running in the background that wants to communicate
> back with the current activity, an easy way to deal with this is to have a
> static variable that is the "current" activity, which you set in your
> onCreate() and clear in onDestroy().  Then instead of pointing to the
> activity that originally started it, the thread can just retrieve the
> current value in that variable when it needs it.  (And of course it will
> need to deal with the race where it can temporarily be null between the old
> activity being destroyed and the new one created...  but if you are doing
> multithreaded programming, this should be familiar territory!)
>
> On Fri, Jan 23, 2009 at 9:52 AM, Stanley.lei <xiaofeng.lei...@gmail.com>
> wrote:
>
> I rather agree with you!
>
> In fact, I could not understand why Google designs like this. The
> keyboard action could impact the rotation, but why changing rotation
> impacts the activity? In my case, the thread is destroyed, which will
> destroy all tasks in the thread. In worst case, the user will have to
> re-create their data from scratch.
>
> stanley
>
> On Jan 24, 1:47 am, cindy <ypu01...@yahoo.com> wrote:
>
> > Then android's implementation has problem.
>
> > For example, if my application needs to create account, of cause, the
> > key board will open first. After user typed in user name and password,
> > then he clickes the "create" button.Request   sends to server in a
> > thread. After that, he closes the keyboard, the activity will be
> > destroyed. So the callback function in thread to update UI will
> > crashed.
>
> > It happens exactly in my application.
>
> > On Jan 23, 7:20 am, "James Patillo" <ja...@patillo.org> wrote:
>
> > > I think what happens is that the activity's state is saved, the activity
> is
> > > destroyed, and then it is recreated with its saved state. This is the
> same
> > > thing that happens when the home button is pressed and the app is
> reopened.
>
> > > This just what I have come to understand, and may be wrong.
>
> > > -----Original Message-----
> > > From: Stanley.lei [mailto:xiaofeng.lei...@gmail.com]
> > > Sent: Friday, January 23, 2009 9:04 AM
> > > To: Android Developers
>
> > > Cc: jinnan....@gmail.com
> > > Subject: [android-developers] Activity Issue on G1 phone
>
> > > Hi all,
>
> > > I met a very strange issue when I tested my application on G1 phone.
>
> > > As usual method, I started a thread in an activity, and stopped the
> > > thread in the onDestroy method. But to my surprise, when I tried to
> > > slide down the keypad, the onDestroy method was called and the thread
> > > was stopped, and more surprising thing was that the activity was still
> > > alive and visible.
>
> > > From the activity's life cycle
>
> diagram,http://code.google.com/android/reference/android/app/Activity.html,
> we
>
> > > can see that onDestroy is called only before the activity is shut
> > > down. But my activity is still active and visible!!!
>
> > > Who could tell me what the hidden story is?
>
> > > Any reply will be appreciated.
>
> > > Thanks,
>
> > > Stanley
>
> --
> 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.  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