*TreKing,*

If you choose to ignore a well documented feature given to us by the Android 
team, that's your prerogative. As for the rest of us, we'll decide when we 
prefer to use one feature over another.


*King Salamon*,

As stated previously, regardless of which way you choose to do it (neither 
is "correct" or "incorrect"), just read up on the things you need to handle 
to make them work like you need them to.

If you really want to save a state long-term, I would suggest you also look 
at SharedPreferences:

http://developer.android.com/reference/android/content/SharedPreferences.html

You aren't guaranteed your state will still be there even if you do save it 
in a bundle. You should treat the state of your application as volatile at 
all times. If a state or piece of data is really important to keep around, 
commit it to disk immediately via the SharedPreferences or another method 
like a custom file, database, etc.. Devices are constantly switching states 
even when we don't want them to. Battery dying, being dropped, locking up, 
and tons of others things make sure the mobile environment is never 
guaranteed, so write accordingly.

Steven
Studio LFP
http://www.studio-lfp.com

 
On Saturday, October 8, 2011 3:02:34 PM UTC-5, TreKing wrote:
>
> On Sat, Oct 8, 2011 at 12:00 PM, Studio LFP <studi...@gmail.com> wrote:
>
>> *TreKing,*
>>
>> This is true, but he didn't ask about that.
>
>
> LOL - so since he didn't ask for for a method that covers the case I 
> mentioned, it's OK to give him a limited solution?
>  
>
>> He just asked about a way for an EditText to keep the text it has on a 
>> rotate.
>>
>
> What people ask on this list is usually very different from the problem 
> they're actually having.
>  
>
>> The easiest and fastest way to solve that particular problem is the 
>> configChanges XML attribute.
>>
>
> Easiest and fastest, but technically incorrect. He's probably asking 
> specifically about rotate because that's also the easiest and fastest way to 
> see the issue. But, as I mentioned, it's not the only way and the OP should 
> be completely aware of that before going with a strategy that will only hide 
> the problem in one particular scenario.
>
> You'll note that I said their may be a need for other options if they 
>> needed it to do additional things other than just handle a rotate.
>
>
> You mentioned the case of different layouts which doesn't cover the case of 
> leaving the app, waiting a while, and coming back to it (AFAIK). There are 
> probably others.
>  
>
>> There is no need to code complicated functions to do something simple. Fix 
>> it the simplest way possible and then add to it if other things arise.
>
>
> Sure, but if "the simplest way possible" is known to have issues, you're 
> not really doing the OP any favors, are you? Now he'll waste time fixing it 
> the simplest way, then eventually having to come back and fix it the right 
> way. Why not have him do it the right way from get-go if you can? It's not 
> like using the save and restore methods is that complicated.
>
> IMHO, the configChanges attributes are for use when you know exactly what 
> you're doing with them and why. Using them to get around saving / restoring 
> state is a fragile kludge for people that can't figure out how to do it 
> correctly. People should be encouraged to figure out how to do this the 
> right way so it works in every scenario and not use what amounts to a hack 
> to solve the most common instance of configuration change.
>
> And I say all this because I've seen way to many people ask about this 
> exact scenario in this group.
>
>
> -------------------------------------------------------------------------------------------------
> TreKing <http://sites.google.com/site/rezmobileapps/treking> - Chicago 
> transit tracking app for Android-powered devices
>
>  

-- 
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
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

Reply via email to