When starting a certain activity of my app, the user is “welcomed” with a dialog that he must fill with some data in order to proceed. Then, in the activity per se, the user has 2 buttons that enable him to dynamically create and delete an infinite number of fields (that are composed by several views)
As you know, when the screen orientation changes, the activity is restarted so every information is lost. Obviously, this can be problematic.
In order to handle the screen orientation, android documentation advises developers to use onRetainNonConfigurationInstance(). The only problem is that if you use it to save objects in a context all the views tied will leak. This is further problematic in my case, since the data in that activity is inherently tied to its view, which, in turn, is tied with its context.
Android Documentation does not recommend developers to handle configuration changes themselves. They state (and I quote) “in general, a short-term solution that will only complicate their lives later”
I can bypass the initial dialog easily, creating a hasBeenShown Boolean and set it to true, for instance. I can even bypass the “dynamically created views” problem by saving their metadata: in this case the number of fields generated, their type, their relative position to each other, their text or selection, and so on… (with some minor bugs, but nothing serious).
But since fields(views) are generated dynamically with layoutInflate(and thus we can have an infinite number of views), when re-generating those same fields after screen orientation change, the application gets really really slow even on emulator. With 20 fields (approximately 120 views) on a real device (Samsung Galaxy S) it took almost 1 minute to complete.
Strangely, when I passed views directly (and thus, leaking all that stuff), it took my Samsumg Galaxy S less than 10 seconds to complete.
With this information, what do you think its the best approach?
(1) – Let the fields reset? (not really an option, I bet anyone would get pissed if they inadvertently tilt their screen =P)
(2) – Add a loading screen while android takes care of changing screen orientation?
(3) – Block screen orientation change
(4) – Handle screen orientation change myself, and hope the impeding Doom Android docs talk about never comes.
P.S: A bit offtopic, but when my activity finishes, all memory is released right?
Your situation is different from mine, but a similar solution may be in order.
Again, because Android will destroy and recreate on an orientation change I initially had issues with Async tasks doing network communication. Obviously I shouldn’t be creating new requests on every orientation change when the first one is still executing.
To save some network usage and headaches I just ‘handle’ the orientation change myself. By placing this code in your AndroidManifest.xml
you allow Android to keep the current context, with views and variables etc. What happens is the layouts will resize themselves but if you designed correctly then you should be ok.
AFAIK the only thing I am preventing Android from doing is using specialized layouts based on the orientation of the device (which I don’t need) and so far I have not been hit by the forewarned impending doom.