Using a custom ArrayAdapter doesn't seem to me to relate to your question, unless your problem is that it's broken. For example, if yours doesn't notify the registered DataSetObservers that the data has changed.
As for async tasks -- what you're describing IS a one-shot task, in any sense that applies here. sure, you'll have more than one shot. But in between those shots, with an ASyncTask, that thread and all the memory required for its stack, will be available for use by OTHER AsyncTasks, including ones possibly launched by the SDK. You do have to create a new AsyncTask each time -- but that's a small price to pay for significantly smaller memory usage. So it's going to be more efficient than creating your own thread. Use your own thread if you have something that has continuously evolving state -- say some recursive process. Even then, you can generally modify it to work with an ASync task. I've read, on this list, I think, that early versions of ASyncTask limit the pool of threads it uses to one. If that's the case, and you run very long tasks, they may prevent other tasks from running. I wouldn't worry about that unless you run into it as a problem; then would be a time to either move your task into its own thread, or to split your task up so it operates as a series of smaller pieces. And it's my understanding that the pool is no longer limited to one thread, so this is a limitation that will fade. Still, if you are usually consuming one of those ASyncTask threads, you're really not getting any benefit from using an ASyncTask other than a convenient interface to moving that final action back to the UI thread. But it's not hard to do that yourself, either. If you DO run it on your own thread, you can post a message back to the main thread, using a Handler aimed at the main thread's Looper, which you can get via getMainLooper() on any Activity or Application or Service, or the static method Looper.getMainLooper(). If you just call Handler(), it picks up the Looper for the current thread -- I believe that's why AsyncTask states in its threading rules: "The task instance must be created on the UI thread.". Basically, you'll be doing what AsyncTask does - but you'll have the flexibility to direct it t the UI thread even if you create it elsewhere. It seems like a character flaw that ASyncTask's default constructor isn't hardwired to send things to the UI thread -- it would prevent a lot of preventable bugs. Just put any code you'd have put in the onPostExecute(Result) method into the runnable you post to your handler. By default, when you flip the orientation, indeed, your activity is destroyed and recreated. But you can specify in the manifest what configuration change events you're prepared to handle yourself, and handle them in onCofigurationChanged(Configuration). If all that's needed is a layout change, you may not need to do anything at all in this method other than call super.onConfugrationChanged(newConfig) -- which, of course, means you don't really need to define the method at all. I recommend doing so, however, to flag that you're actually doing this, and that here's where any configuration change happens. If you have elements of your UI that scroll, you may need to reset the scroll position here. I've seen a number of apps that appear not to do this, and it's annoying. While you can tell that a Thread has ended by checking its state, that's not how you SHOULD be doing things. In Android, use a Handler and post whatever action you want to perform when the thread is ended. At a lower Java level, use the wait/notify protocol to synchronize. There's a clear and reliable usage pattern you can use, but it's a bit complicated to describe, and doing it wrong results in subtle bugs. You may want to consider using a try block, and posting your final action from the finally clause. Declare a variable 'ok' at the start of your function, and set it to true when you reach the end of your code. Choose what code to run in the success and error/failure case based on the flag. This is a good way to communicate errors back to the main thread. I hope all that makes sense... On Feb 18, 4:03 pm, Ken H <hunt1...@gmail.com> wrote: > But what if you're using a custom ArrayAdapter? Also, I *think* > AsyncTask is meant for one shot type tasks. A user of this app may > update this listview multiple times. > > But here is something I've discovered: if I change the orientation of > the screen, the list is properly updated. Question: how can I mimic > that screen orientation change? What is actually happening when you > flip the phone? It's restarting that activity right? > > Another question (I'm hitting this problem from multiple angles), how > do you tell is a thread has ended? If I can tell when the thread ends > I can do this listview update in the main thread -- which I know > works. > > Ken > > On Feb 18, 1:33 pm, Mark Murphy <mmur...@commonsware.com> wrote: > > > > > Ken H wrote: > > > I wasn't able to get the AsyncTask to work (although I have used it > > > successfully in another app). > > > Here's an example of using AsyncTask to asynchronously populate a ListView: > > >http://github.com/commonsguy/cw-android/tree/master/Threads/Asyncer/ > > > -- > > Mark Murphy (a Commons > > Guy)http://commonsware.com|http://twitter.com/commonsguy > > > Android App Developer Training:http://commonsware.com/training -- 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
