17

Does anyone know the rationale behind the design of Android to destroy and re-create activities on a simple orientation change?

Shouldn't allowing the activity to just redraw itself (if it so chooses) be a better, simpler and more practical design?

BTW, I'm well aware of how to disable my app from orientation change effects, but what I don't really get is the reason for this design in Android

Bryan Denny
  • 27,363
  • 32
  • 109
  • 125
source.rar
  • 8,002
  • 10
  • 50
  • 82
  • 1
    This is a programming question. Android Enthusiasts is more for users of Android. I'm moving your question over to StackOverflow. – Bryan Denny Jul 30 '11 at 05:01
  • Was initially thinking of posting it here but was not sure if it belonged. Thanks for clearing that up :) – source.rar Jul 30 '11 at 05:03

3 Answers3

12

In docs, http://developer.android.com/guide/topics/resources/runtime-changes.html

it states that,

The restart behavior is designed to help your application adapt to new configurations by automatically reloading your application with alternative resources.

sat
  • 40,138
  • 28
  • 93
  • 102
  • 4
    Well it doesn't really "help" when it cause so many other problems as side effects (for e.g. dangling AsyncTasks, Dialogs not continuing seamlessly are some I've come across so far). When all that is actually required is a redraw/layout of the current components on the screen is there a simple way to just ensure this (without having the activity destroyed and recreated)? – source.rar Jul 30 '11 at 06:12
  • 6
    More than a redraw is required. Android offers you the ability to have different resources (images, strings, themes, styles, layouts, etc.) for the 2 screen orientations. Reloading these manually would be much more work than handling dialogs and asynctasks. – Romain Guy Jul 30 '11 at 07:28
  • 2
    Hmmm... is destroying and recreating an activity really that much more 'lightweight' than allowing the app to reload any additional resources it needs? – source.rar Jul 30 '11 at 16:07
  • 1
    @source.rar - It looks like Romain Guy was the driving force behind it. Why otherwise would he protect it in comments? ;) – JBM Jul 30 '11 at 18:13
  • BTW, found another problem that also seems to have something to do with orientation. Posted here http://stackoverflow.com/questions/6903761/after-home-button-press-re-launching-app-shows-intial-activity-not-current – source.rar Aug 02 '11 at 03:52
0

This is pretty simple. Android destroys and recreates an activity on orientation changes so that you (the developer) have the option to keep on using the previous layout or use and implement another one.

user1923613
  • 626
  • 5
  • 11
  • 31
  • 1
    You're right but the rationale is completely wrong _in my opinion_. The docs state about destroy: `[..] can happen either because the activity is finishing [..] or because the system is temporarily destroying this instance of the activity to save space.`. This doesn't exclude orientation changes, but it seems odd that it works like this.. Thus far, the only way I've been able to trigger a 'natural' `destroy` is by rotating the screen. Doing a `pause` followed by a `resume` seems more logical to me. Also, `resume` is a misnomer, but that aside. – pauluss86 Jan 30 '14 at 01:23
0

Dont know exactly why, my guess is because it has to reconstruct the activity on the screen.

OnCreate takes in a variable "Bundle savedInstanceState". You can save the data in there for faster reloading.

package com.android.hello;

import android.app.Activity;
import android.os.Bundle;
import android.widget.TextView;

public class HelloAndroid extends Activity {
    /** Called when the activity is first created. */
    @Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);

        mTextView = new TextView(this);

        if (savedInstanceState == null) {
            mTextView.setText("Welcome to HelloAndroid!");
        } else {
            mTextView.setText("Welcome back.");
        }

        setContentView(mTextView);
    }

    private TextView mTextView = null;
}
Abhishek
  • 1,749
  • 9
  • 27
  • 39