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 save/restore is possible... some apps more complex and there is no easy way to save/restore. I know which of my iPhone apps will have to be restarted from an interruption... actually they are of a nature that I want them that way.
My app is one where there several screens could be navigated down to a detail level (imagine navigating down a database schema) and data is retrieved from the network for each screen. I haven't found an easy way to serialize or store Android Views. Repopulating them from the workflow that the user followed and then re-stacking them on the screen is also difficult. Since I can use an Intent to open an external activity (browser for example) and return without a recreate then why not allow that for a screen rotation change? Regardless whether an app needs to survive state (from a phone call or exit and then return)... mine doesn't... let the developer choose when to recreate activities based on THEIR application. I still of the opinion that there is some problem if an activity has to be recreated JUST to enter text on some screen. Forget the arguments about phone calls, interruptions, or coming back to app after playing a game --- there is something that doesn't feel right from a design perspective that you have to restart your activity only to enter text. If there is no technical limitation, why force it? On Oct 8, 3:49 pm, Mark Murphy <[EMAIL PROTECTED]> wrote: > 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, your application will not work in production, when real > people use your app on real devices with real memory restrictions that > cause your application to go bye-bye at random times. The mere fact that > one of those "random times" is when the user slides open the keyboard > should matter not a whit. Your app could go away just as easily because > the person took a call, then started to play Super Orangutan Spheres for > a while, and orangutans make lousy Java coders, so there's a memory > leak, which eventually causes your application to get ejected from > memory. Or, they realize they needed to look up something else while > using your application, got distracted, forgot all about your app, and > eventually enough other stuff gets done that causes your application to > get ejected from memory. Or any number of other combinations of events. > > So, if you need to support saving/restoring instance state to have a > meaningful application in production, just write the code and be done > with the matter. You wind up with portrait/landscape handling "for free". > > -- > Mark Murphy (a Commons Guy)http://commonsware.com > _The Busy Coder's Guide to Android Development_ Version 1.3 Published! --~--~---------~--~----~------------~-------~--~----~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~----------~----~----~----~------~----~------~--~---
