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
