> peculiar problems in the way the classes are designed. Service by > definition is already in the background, it HAS no UI thread, so why
Services, by default, run in the same on process and on the main/UI thread. > http://developer.android.com/reference/android/app/Service.html > Note that services, like other application objects, run in the main thread of > their hosting process. This means that, if your service is going to do any > CPU intensive (such as MP3 playback) or blocking (such as networking) > operations, it should spawn its own thread in which to do that work. On Sep 11, 4:55 am, Indicator Veritatis <[email protected]> wrote: > Option 4 certainly sounds like it will work, but it suggests some > peculiar problems in the way the classes are designed. Service by > definition is already in the background, it HAS no UI thread, so why > do I need an AsyncTask there at all? The whole point of the latter is > to communicate between UI thread and worker thread. > > As for documenting what works, I hope Google takes your hint and > documents what the right way to do this really is. After all, these > are the same people who keep warning us that "if it's not documented, > then it is subject to change w/o notice". > > On Sep 10, 10:04 am, Mark Murphy <[email protected]> wrote: > > > On Fri, Sep 10, 2010 at 12:46 PM, Romain Guy <[email protected]> wrote: > > > Option #1 is a lot more intrusive. You lose the ability to > > > automatically switch layouts, drawables, etc. > > > Worst-case scenario: > > > Step #1: Take your UI setup that is in onCreate() and move it to a > > separate method (e.g., setupViews()) > > > Step #2: Call setupViews() from onCreate() > > > Step #3: Call setupViews() from onConfigurationChanged() > > > Done. ~4 lines of code. And it's the exact same code path that a > > destroy/recreate will go down, so it's not like this adds unusual > > performance overhead. There are certain circumstances where this may > > not work (e.g., GLSurfaceView and a game), but you needed to do extra > > work for those cases, anyway, to handle the destroy/recreate cycle. > > > > Saving and restoring an AsyncTask is not difficult. > > > No, it's not. The question is: is it reliable? > > > None of the AsyncTask documentation (class, article, etc.) covers this > > case. It *appears* that you can write an AsyncTask such that > > onPostExecute() or onProgressUpdate() will not be called in the middle > > of the activity transition. However, that's not documented and hence > > not guaranteed, and so while I'll describe a pattern that seems to > > work, I personally don't trust it any further than I can throw your > > large Froyo lawn ornament. If somebody could give us the recipe that > > is guaranteed to work (i.e., works today, and is going to work in > > Android 2.3/3.0/Turbo System 5000), that'd be *wonderful*. > > > Actually, I lied earlier. I'd choose Option #4: > > > Option #4: Don't do the AsyncTask in an activity. Use a Service and > > have it do the AsyncTask, or use an IntentService if the sole purpose > > of the service is to do stuff in a background thread. In particular, > > an IntentService would be good for a download that you want to happen > > regardless of what may go on with an activity (e.g., Android Market > > downloading an APK), and so you don't need to worry about canceling > > it. > > > -- > > Mark Murphy (a Commons > > Guy)http://commonsware.com|http://github.com/commonsguyhttp://commonsware.com/blog|http://twitter.com/commonsguy > > > Android Training in London:http://skillsmatter.com/go/os-mobile-server -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
