Just tried the asynctask again, and it works. Basically I put the time consuming part in doInBackground(), and then launched a progressDialog in onProgressUpdate() to let users know nothing froze, and finally dismissed the progrssDialog in onPostExecute(). Also added the final refresh of the listview there.
Thanks again guys. Ken On Feb 18, 10:10 pm, Ken H <hunt1...@gmail.com> wrote: > 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
