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 -> ScreenB -> ScreenC -> ... ScreenX where each one potentially accessed the Internet or a content provider to populate the screen with data. If Views were serializable, it could be easier. I didn't find any API's to bulk save/restore the state of something like lists as you mentioned.
Gosh, opinions about design flaws are just that... opinions. There is no absolute. I still feel forcing a cumbersome save/restore just because the screen orientation changed instead of repainting the screen with a new dimension is a problem. All because the user needed to enter text. 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 this area is starting an activity via an intent (such as the browser) and then hitting the back button to return back to where I was in my app. Now why doesn't this process require a full onCreate/onResume cycle like a screen orientation change does? On Oct 7, 12:13 pm, hackbod <[EMAIL PROTECTED]> wrote: > 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 result, there is pretty extensive support in > the system for remember the state of activities, lists, etc, and > restoring them when being re-created. > > See the API demos for saving and restoring state for a simple example. > > This is how most apps in the emulator work, so it is not a design > flaw. > > On Oct 7, 8:21 am, Rmac <[EMAIL PROTECTED]> wrote: > > > Trying this again. > > > Since there is no on-screen virtual keyboard built into Android, I am > > confused about how to plan for text entry. Let's assume there is a > > screen with a EditText field requiring user input. On the iPhone it > > works simply by a virtual keyboard popping up when the field has > > focus. How should an Android app handle this? With the HTC G1 phone > > I assume the user would have to rotate the phone and open the keyboard > > to type (cumbersome for minor text entry). Now, does the rotation and > > screen going into landscape mode mean the app is forced into the > > onCreate/onResume cycle requiring a complex saving/restoring of app > > state just to enter information? Or is the orientation flip handled > > by Android transparently without the app having to do anything... the > > screen dimension is just changed and redrawn accordingly? > > > If the application's activity is restarted just to enter text due to a > > screen orientation change, I believe this is a fundamental flaw in > > Android. Imagine an application that has progressed through several > > screens of data retrieval and display... does this process have to be > > repeated because the user rotated the screen? Why not have just have > > the window force a repaint with new screen dimensions without having > > to save/restore state (if that is even possible within the > > application). > > > Really confused about this and haven't found any definitive > > explanation yet. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~----------~----~----~----~------~----~------~--~---
