Take a look at
http://code.google.com/android/reference/android/R.styleable.html#AndroidManifestActivity_configChanges,
particularly setting it to orientation|keyboardHidden.
This is discouraged, for the reasons mentioned in this thread. But since
you're not going to save your state properly, thi
> Since I can use an Intent to open an
> external activity (browser for example) and return without a recreate
Not necessarily. You may or may not get control again before a "recreate".
It all depends on what the user does. Assuming you will get control again
before a "recreate" is dangerous.
>
I respectfully have to say you are missing my point. You don't know
my app (nor other possible future complex ones) and are making
assumptions about the save-ability of some apps. I have had an iPhone
from day one so I know about running apps and interruptions. Some
apps are simple enough where
Rmac wrote:
> Why not have an option to tell Android there is no need for an
> activity recreate if there are no alternate resources?
Somehow, I think you're missing the point.
The code you are trying avoid (saving/restoring instance state), you
need anyway. So just write it.
If you don't, you
Ok, makes some sense. I am more accustomed to Java's layout managers
that automatically resize without rebuilding everything. Same holds
for most "windowing" OS systems where a window's dimension can be
changed by the user and not force an application to restart basically.
Given that a develope
Correct, it's not a technical limitation, it is explicitly done
because -any- resource (layouts, strings, etc) can change based on
both screen orientation and whether a keyboard is available, so
restarting the activity allows all of the resources to be reloaded
again with the correct values.
On O
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
>
> It seems there is some technical restriction internal to Android that
> prevents it from just repainting screens after a rotation... unlike
> the return from an external activity where the originating activity
> remains intact. What is the reaso
Thanks... I think I understand the lifecycle.
And forgive me for continuing to push the keyboard/rotation issue. I
am having trouble understanding the logical reasoning for designing
Android where the app has to be re-created just to enter text (due to
the lack of a virtual keyboard and subseque
On Oct 7, 1:51 pm, Rmac <[EMAIL PROTECTED]> wrote:
> My testing shows starting an external activity and then returning via
> the back key only calls onResume, not onCreate. The screen
> orientation change calls both onCreate and onResume on the originating
> activity. It seems odd (maybe a desig
>
> That process requires the exact same onCreate()/onResume(), you just
> don't realize it because it happens transparently for Views:
>
My testing shows starting an external activity and then returning via
the back key only calls onResume, not onCreate. The screen
orientation change calls bot
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> Yes, changing the screen orientation means going through onCreate()
> onResume()
I have verified that changing the orientation causes the app to call
onCreate, without killing the process.
This appears to violate the state machine outlined in the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
>
> I can live with the app having to restart from scratch due to a
> process kill from a different app started by the user after going to
> Home. Most of the iPhone apps behave this way. One nice feature I
> think Android has over the iPhone in th
Thanks for the reply. Can you point me to a non-trivial example in
the API demos where saving/restoring state is done on a series of
screen displays (such as some drill-down type app)? I couldn't find
anything comparable. I am trying to wrap my head around how to
recreate something like ScreenA
Yes, changing the screen orientation means going through onCreate()
onResume() which, if your activity is implemented correctly, should be
transparent, since you also need to deal with this same thing
happening when your process is killed in the background and the user
returns to the app. As a re
14 matches
Mail list logo
