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 developer cannot know beforehand the dimensions of an Android handset I'd be surprised that anyone could or should design with different resources (layouts, strings, etc). How many possible "landscape" dimensions will there be for all the phones? How many "portrait" sizes? There is no way to program for that other than have the layout manager dynamically do it like Swing does. It seems if the Android design team is to encourage a best practice, it would be NOT to assume a particular screen orientation or dimension by the developer and let Android handle it transparently. Then the issue of alternate resources goes away... and besides as I indicated how would anyone know how many different layout resources to plan. Android for the most part only allows a "WRAP" or "FILL" when sizing components anyway. Why not have an option to tell Android there is no need for an activity recreate if there are no alternate resources? If there is no technical limitation and Android can handle dynamic resizing on the fly, let us bypass the difficulty of trying to save/restore state in more complex applications? Then you can have the best of both worlds and the most flexibility. On Oct 8, 12:25 pm, hackbod <[EMAIL PROTECTED]> wrote: > 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 Oct 8, 10:18 am, Xolotl Loki <[EMAIL PROTECTED]> wrote: > > > -----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 reasoning behind the design for screen > > > rotation forcing an activity recreate while a return from another > > > activity doesn't? > > > I don't think it's a 'technical restriction' at all. Your onCreate() > > method might have drawn itself differently, depending on the screen > > orientation. Just because you have no use for this doesn't mean that no > > one else would. > > > Just use onSaveInstanceState to persist your app state, then restore it > > in onCreate. If you do this, users will be able to leave your app > > entirely, and come back to it without interruption. > > > cheers, > > - -- > > ᛏᚠᛖᚾᚱᛁᛊᚢᛚᚠᚱᛏ > > ᛏᚢᛚᚠᛊᛚᛖᛁᚠᚨᚱᛏ > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG v1.4.9 (GNU/Linux) > > Comment: Using GnuPG with Mozilla -http://enigmail.mozdev.org > > > iEYEARECAAYFAkjs63UACgkQNig/07RbnEv3pgCeNJ0KjWRxlE7i7PNsHpC21ZaB > > qJwAn0hJNkfdK9yfvEu6J1lL14JZBLxJ > > =jJTC > > -----END PGP SIGNATURE----- --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
