Configuration changed (orientation change) and destroying Activities - is this the way it's supposed to work?

I read up on how Android handles "configuration changes" - by destroying the active Activity.

I really want to know from Android Team why this is. I would appreciate an explanation on how the reasoning went, because I don't understand it. The fact that it acts in that way puts us all, as I see it, in a world of pain.

Lets assume you have a Activity which presents a number of EditText:s, checkboxes etc. If a User starts to fill that form with text/data and then changes orientation (or get a Phonecall), then all input the User made is gone. I haven't found any way to preserve state. That forces us to make extremely painful coding to not lose all data.

As I see it, you need another "non-Activity" class (or "value-holding" class perhaps) that has one field for each "form element" (EditText, checkbox etc).

For every single "form element" that exists, you then need to attach an Event like "onChanged" (or onTextChanged or something like that) that updates the corresponding field in the "value-holding" class to make sure that for every single character you type (in a EditText for example) is saved at once.

Perhaps you can use some listener (like "onDestroy" or something) and then fill the value-holding class with data.

I have also found this piece of info where they talk about using Bundle, onSaveInstanceState and onRestoreInstanceState, but that also mean that the programmer has to manually save and then later put back the values in the correct place? This approach is a bit less messier than my suggestions above, but still not very nice.

Can someone tell me that I am totally wrong and that this is not how it works and that I totally missed some vital informa开发者_如何学Gotion?

You should read the Application Fundamentals (specifically, Activity lifecycle). Since Activitys must be able to handle being killed at any time due to memory contraints, etc. it's just a cleaner way to handle rotations without adding too much complexity - instead of checking every resource for an alternate resource, re-structuring the layout, etc. you just save your essential data, kill the activity, re-create it, and load the data back in (if you're willing to deal with the extra complexity of managing this yourself, you can use onConfigurationChanged to handle the configuration change yourself.) This also encourages better practices - developers have to be prepared for their Activity to be killed for orientation change, which has the (good) consequence of being prepared for being killed off by memory contraints also.

The contents of an EditText will be saved for you automatically when rotating the screen if you put an android:id attribute on it. Similarly, if you display dialogs using Activity#showDialog, then the dialogs are reshown for you after rotating.

on why part - short answer - because you might have resources that needed to be changed as you've rotated the phone. ( Images, layout might be different, etc )

On save - you can save you stuff to bundle and read it back.

  @Override
    protected void onSaveInstanceState(Bundle outState) {

            String story_id = "123"
            outState.putString(ContentUtils.STORYID, story_id);

    }

or you can use onRetainNonConfigurationInstance () as described here http://developer.android.com/reference/android/app/Activity.html#onRetainNonConfigurationInstance()

Finally if you don't have anything you want to handle during rotation - you can ignore it by putting this into your activity in manifest

android:configChanges="keyboardHidden|orientation"

In general, i would read trough article from url above couple of times, until lifecycle is crystal clear.

@Alex's approach above pointed me to a really, really useful solution when using fragments:

Fragments usually get recreated on configuration change. If you don't wish this to happen, use

setRetainInstance(true); in the Fragment's constructor(s)

This will cause fragments to be retained during configuration change.

http://developer.android.com/reference/android/app/Fragment.html#setRetainInstance(boolean)