Hey James, good to know, thanks!
-Matthias On Oct 21, 9:30 pm, James Yum <j...@google.com> wrote: > Hi Matthias, > Thank you for the good question (shows you're thinking). > > Check the Application Fundamentals dev > guidehttp://developer.android.com/guide/topics/fundamentals.html > > Near the bottom: > > "Because a process running a service is ranked higher than one with > background activities, an activity that initiates a long-running operation > might do well to start a service for that operation, rather than simply > spawn a thread — particularly if the operation will likely outlast the > activity. Examples of this are playing music in the background and uploading > a picture taken by the camera to a web site. Using a service guarantees that > the operation will have at least "service process" priority, regardless of > what happens to the activity." > > Also from the Service class doc: > > "Note this means that most of the time your service is running, it may be > killed by the system if it is under heavy memory pressure. If this happens, > the system will later try to restart the service. An important consequence > of this is that if you implement > onStart()<http://developer.android.com/reference/android/app/Service.html#onSta..., > int)> to schedule work to be done asynchronously or in another thread, then > you may want to write information about that work into persistent storage > during the onStart() call so that it does not get lost if the service later > gets killed." > > As far as the tasks, you can probably devise a simple (and try to keep it > simple) way to track the different tasks. I'd probably add some sort of > timeout check to clear out threads that never terminated for whatever > reason. > > Cheers, > James > > On Wed, Oct 21, 2009 at 8:27 AM, Matthias <m.kaepp...@googlemail.com> wrote: > > > Hi, > > > in our app we're doing background photo uploads. The current > > implementation works using a combination of a Service and an > > AsyncTask. The former will trigger the latter, which will do the > > actual network I/O. > > > My question is: since the user can trigger many uploads in parallel, > > is this the correct implementation pattern? The problem is that I can > > never call Service.stopSelf() from an upload task when it finishes, > > because those tasks don't know anything about each other or the > > service that triggered them (because of the very nature of AsyncTask). > > > Do I even need a Service here at all? I always thought services were > > meant for long running background tasks, but their documentation > > clearly states that one must execute blocking operations in a separate > > thread. What's the purpose of Services then? You could just fork an > > AsyncTask from an Activity, it would make no difference at all. > > > What would you suggest doing in my case? > > > Cheers, > > Matthias > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
