My apologies: I thought I was responding to a different thread, concerning the rotating async task problem.
Responding to you question: Yes. Maintaining the state (and async task itself) in the application object is a reasonable way to handle this. If you need persistence across application/process instances, you'll need to persist progress in shared preferences or another persistent store. On Sep 26, 2:14 pm, joebowbeer <joe.bowb...@gmail.com> wrote: > I've also solved this problem in the way you've described: by managing > the task instance in the application object. This does burden your > application implementation with task details that logically are the > responsibility of an activity or fragment. In the interest of > robustness, though, I do like to keep a tight grip on thread instances > and centralized management via the application object accomplishes > that. > > The other approaches described in this thread are: > > 1. Stop/cancel the task on rotation but remember what it was doing and > restart it when the activity is restarted. > > 2. Don't stop the task on rotation but detach from it, retain its > instance (onRetainNonConfigurationInstance), and reattach to it when > the new activity is created. (A generalized version of Mark's async > task can be helpful here.) > > Joe > > On Sep 23, 6:29 pm, João Rossa <joao.ro...@gmail.com> wrote: > > > > > > > > > The use case is that the user should always see the loading progressbar if > > there's any background work being done in whatever activity the user is and > > if the task was launched from another activity. I tried putting a reference > > in the application class to the progressbar and then refresh it in the > > activities in the oncreate and onrestart,that the way the task will always > > have the refreshed reference on the postexecute method.... > > Any inconvinients on this procedure? > > > regards, > > > On Fri, Sep 23, 2011 at 7:13 PM, blake <blake.me...@gmail.com> wrote: > > > AsyncTasks are a nifty tool but they have a fairly limited specific > > > set of uses. The previous responses have pointed out a several > > > problems with this code: you can't keep static refs to Activites or > > > Views, multiple Activities can't share a progress bar, etc. > > > > I don't understand the use case, but I agree with Mark that, from the > > > code you've supplied, this might be better done as an IntentService or > > > as a pair of Fragments. > > > > I'm going to be giving a Webinar on the pitfalls surrounding > > > AsyncTasks next week, on the 29th: > > > >http://oreillynet.com/pub/e/2061 > > > > -blake > > > Programming Android, FTW! > > >http://oreilly.com/catalog/0636920010364 > > > > -- > > > 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 -- 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