As always, thanks Mark! I definitely see your point - its better to do short chunks of work in an AsyncTask than creating long running background threads.
My app makes a lot of http requests. After the download is complete, it updates a database. I thought it would be better to create a single background thread that does this work and then notifies the UI when its finished. I thought this would be more efficient than opening a network connection, opening the database, doing work, closing the database, etc. each and every time. I suppose I could open the database in the main Activity thread and close that in onDestroy and pass it to the AsyncTask each time. On Thu, May 20, 2010 at 9:58 AM, Mark Murphy <mmur...@commonsware.com>wrote: > > This leads me to a new question....when do I actually destroy the > > threads then? > > As soon as their work is done. All else being equal, choose a model where > you do not keep your own threads hanging out forever (e.g., use AsyncTask > rather than forking your own threads). > > > Part of me is wondering if I even need to bother > > destroying the threads - won't the OS do that automatically when it > > needs to? > > No, it will not, except by terminating the process, which may not happen > for quite some time after your activity is destroyed. This yet another > reason to use AsyncTask rather than forking your own threads -- threads > *Android* forks *Android* is responsible to clean up. > > Moreover, please bear in mind that your activity may be in a stopped state > for an extended period of time (a.k.a., days). Your goal, while stopped, > should be to avoid doing anything much. This is yet another reason to > design your application to avoid forking your own threads that hang around > indefinitely, but rather do your background work in short discrete chunks > in AsyncTasks. > > > One of the threads has an open database connection. I > > imagine that should be handled more gracefully. The question is when > > should I do this? > > As soon as your work is done. > > > When an Activity starts, there is a way for you to tell if you have > > saved state. > > In your case, if getLastNonConfigurationInstance() is not null, you have > saved state, in the form of the object returned from > getLastNonConfigurationInstance(). > > > When the Activity ends, I wish there was some reliable > > way to determine whether the Activity is going to restart right away > > or if its being destroyed for good. > > Call isFinishing(). > > -- > Mark Murphy (a Commons Guy) > http://commonsware.com > Android App Developer Books: http://commonsware.com/books.html > > > -- > 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<android-developers%2bunsubscr...@googlegroups.com> > For more options, visit this group at > http://groups.google.com/group/android-developers?hl=en > -- 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
