Wow, dude...thanks! That was a thorough answer. Usually get a vague, one sentence response that leaves me more confused than before.
I don't know why I said that thing about the custom adapter...I think because I don't truly understand what it's doing and this activity revolves around it. Well, I need to digest all this and try it out. Thanks again. Ken On Feb 18, 5:24 pm, Bob Kerns <r...@acm.org> wrote: > 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
