And not even your UI:

*" The default implementation takes care of most of the UI per-instance 
state for you by calling 
onSaveInstanceState()<http://developer.android.com/reference/android/view/View.html#onSaveInstanceState()>
 on 
each view in the hierarchy that has an id, and by saving the id of the 
currently focused view (all of which is restored by the default 
implementation of 
onRestoreInstanceState(Bundle)<http://developer.android.com/reference/android/app/Activity.html#onRestoreInstanceState(android.os.Bundle)>).
 
If you override this method to save additional information not captured by 
each individual view, you will likely want to call through to the default 
implementation, otherwise be prepared to save all of the state of each view 
yourself. "*

http://developer.android.com/reference/android/app/Activity.html#onSaveInstanceState(android.os.Bundle)
 

So any UI object with the same ID in both the old and new context will be 
restored by the system

On Friday, July 20, 2012 3:57:51 PM UTC+1, MagouyaWare wrote:
>
> As Mark said earlier... The main purpose of onSaveInstanceState() is to 
> save the current state of your UI so you can restore it when the activity 
> comes back...  That way the rotation appears seamless to the user. 
>
> This would mean saving text in EditText objects, or the checked state of a 
> CheckBox or RadioButton, etc... That shouldn't take very long to save... If 
> you are doing other stuff in there that would need to be moved elsewhere.
>
> Thanks,
> Justin Anderson
> MagouyaWare Developer
> http://sites.google.com/site/magouyaware
>
>
> On Fri, Jul 20, 2012 at 6:17 AM, Mark Murphy 
> xxxxxxxxxxxxxxxxxxxxxxxxx wrote:
>
>> On Fri, Jul 20, 2012 at 8:06 AM, Andrew
>> xxxxxxxxxxxxxxxxxxxxxxxxxxxxx wrote:
>> > Yes, I agree that this probably is freezing UI.  But there's a problem 
>> here:
>> > this cannot be run on a spawned thread as OS may kill the process right
>> > after this call returns, thus, again, killing the saving thread in the
>> > middle!
>>
>> First, it is rather unlikely that the OS will "kill the process right
>> after this call returns".
>>
>> Second, if you are trying to do anything that takes a while in
>> onSaveInstanceState(), you're doing it wrong. You should be triggering
>> that work in other places (e.g., onPause(), on an explicit action bar
>> item click), and using a background thread in those places as well.
>> For example, onSaveInstanceState() has nothing to do with a persistent
>> data model (e.g., database).
>>
>> Third, as you are discovering, Android may terminate your work
>> *anyway* if you are taking a long time on the main application thread.
>>
>> --
>> Mark Murphy (a Commons Guy)
>> http://commonsware.com | http://github.com/commonsguy
>> http://commonsware.com/blog | http://twitter.com/commonsguy
>>
>> _The Busy Coder's Guide to Android Development_ Version 3.8 Available!
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Android Developers" group.
>> To post to this group, send email toxxxxxxxxxxxxxxxxx
>> To unsubscribe from this group, send email to
>> xxxxxxxxxxxxxxxxxxxxx
>> For more options, visit this group at
>> http://groups.google.com/group/android-developers?hl=en
>>
>
>

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