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