A particular Service component is managed as a global singleton in the system, that is there will only ever be one instance of a Service component created at a time.
The core Service functionality allows you to tell the system about work being done by your application outside of the normal activity/receiver/provider models and to provide a central point for rich application within or across applications by either manually starting a service or binding to it and performing calls on its IPC interface. There are a number of situations where a separate thread is not needed for a service (for example if it is going to watch the accelerometer or GPS location) or where a service has specific ways it wants to manage its threads (such as media playback being run in a thread created in the media framework, or networking with a pool of worker threads), so the Service class itself does not force a particular threading model on the developer and instead leaves it up to subclasses to do what they find appropriate. On Thu, Dec 18, 2008 at 9:38 AM, JP <[email protected]> wrote: > > > > On Dec 18, 2:41 am, sukumar <[email protected]> wrote: > > hi, > > > > Thats not my doubt. My service needs to read some data using htttpget, > > this action is performed onStart method of the service. While service > > is in middle of reading data from web. If someone starts the service > > again. What happens to the task started first? Will the service ends > > the first task and starts again from onStart function or Will service > > run the two task in separate two threads? > > > > -Sukumar. > > Creating a service does not create a new thread. This makes the > concept of Service almost seem pointless? I have had similar doubts > and I wondered what the point may be for the creation of background > processes. I ended up implementing a Service anyway, to conform with > the app model. From the overridden onStart() method, I create threads > that handle things as if they were created straight out of the main > app. This makes it easier to handle all those "dark" state changes. > Beware: You are blocking your main app thread if you call httpGet from > the onStart() method as you describe. If the handset cannot get > through to the web, the main thread is blocked, and you will get those > Kill-app/wait dialog boxes. I've isolated interactions with web > servers in a separate thread where I don't bother the main app and > bodge the user experience. This also allows me to manage threads just > as I normally would, e.g. blocking the creation of duplicates etc. > Now that's just what I came up with. Perhaps I understand something > wrong there, but it works and appears reasonably well architected. > > > > -- Dianne Hackborn Android framework engineer [email protected] Note: please don't send private questions to me, as I don't have time to provide private support. All such questions should be posted on public forums, where I and others can see and answer them. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
