Found what I was looking for here: http://www.androidguys.com/2008/11/07/rotational-forces-part-two/
On Aug 14, 12:12 am, Indicator Veritatis <[email protected]> wrote: > The advice to read and memorize the online docs on lifecycle is good. > But memorization will be somewhat elusive. While you are waiting for > that elusive satori to bloom, remember one point: there is never a > good reason to do TCP/IP in the main thread, which in Android, is also > the UI thread. (or what did you mean by "global thread-based class?) > You really must move it to another thread. Mostly likely, you will > want that other thread to run in a Service, which itself will run in > the background (in both senses of the word: it will have no UI and > will be a thread separate from and ultimately subordinate to the main > thread). > > Now for some answers: > > 1) you don't. That's not your job. The system has the last word. > 2) I have no idea why you thought onResume() was the way to do this. > But how you really DO do this depends entirely on your implementation > of how Preferences are entered. But you didn't tell us this, though > you did suggest it strongly in the words "Preference Activity". > > Well, actually, I do have one idea why you thought that, but it would > be a mistake: perhaps you thought that you could count on onResume() > invocation implying that the user had finished entering the > preferences. But you cannot: lots of things cause onResume() to be > called. OTOH, if the PreferenceActivity is started via startActivity() > called from the main Activity, then when the user presses Back (during > the PreferenceActivity), the system calls finish() on the > PreferenceActivity, making the main Activity once more the top of the > stack: the system will display it, calling onResume(), when it gets > around to it. > > Are you really using a PreferenceActivity to read/set the preferences? > If so, the safe thing to do is always read the settings back in from > the XML whenever your main/first Activity reaches onResume(). This is > guaranteed to follow onCreate() and onStart(). This means that your > default preferences have to make sense. > > Now if that is too much computation for you, then before you try to > get clever and cut down on inflation (reading the XML), you really > will have to know the Activity lifecycle much better. Wait for that > satori. Then you can move on to more 'advanced' ideas such as using an > Application object to store global state. > > On Aug 12, 11:32 am, TheWanz <[email protected]> wrote: > > > > > > > > > I would like to know the best practice approach to accomplishing this > > in Android: > > > Main Activity: Contains 1 textview, 1 opens menu and 1 global thread- > > based class. The global thread-based class that opens a socket and > > reads in data via TCP/IP, and sends thread-safe notification to the > > main activity so that it can update its textview. This class is > > developed and works well when it is called from the main activity's > > onCreate method. > > Preferences Activity: This activity allows the user to choose options > > for host and TCP/IP. > > > Here are my questions: > > 1. How do I keep my global class from being destroyed when the onPause > > is called? Every time I rotate the phone or enter the preferences > > activity, the object is trashed. > > 2. How do I capture the event that the user has entered preferences > > and it is time to start my global class? I have tried onResume, but > > there is ambiguity between when the app is loaded and when the > > preferences screen was exited. > > > Thanks in advance... -- 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
