Android service details 3: deriving a service from a class service

Derived from class service

As you can see in the previous section, using the intentservice class makes it very easy to implement a "start" service. however, if you want your service to be executed in multiple threads (instead of working queues), you need to derive from the class service to process each intent.

In contrast, the following example derives from the class service and implements exactly the same work as the previous intentservice example, that is, processing each "start" request serialized in a thread.

Public class helloservice extends Service {<br/> private Looper mserviceloader; <br/> private servicehandler mservicehandler; </P> <p> // process the messages received from the thread <br/> private final class servicehandler extends handler {<br/> Public servicehandler (low.low.low.com) {<br/> super (logoff); <br/>}< br/> @ override <br/> Public void handlemessage (Message MSG) {<br/> // we usually do some work here, such as downloading a file <br/> // In our example, we only need to sleep for five seconds. <br/> long endtime = system. currenttimemillis () + 5*1000; <br/> while (system. currenttimemillis () <endtime) {<br/> synchronized (this) {<br/> try {<br/> wait (endtime-system. currenttimemillis (); <br/>} catch (exception E) {<br/>}< br/> // use startid to stop the service, so that we will not stop the service while processing another job <br/> stopself (MSG. arg1); <br/>}</P> <p> @ override <br/> Public void oncreate () {<br/> // start the thread that runs the service. note that I have created a <br/> // separate thread, because the service usually runs in the Process <br/> // main thread, but we do not want to block the main thread. we also set the new thread <br/> // as the background-level priority to reduce the impact on the UI thread (main thread ). <br/> handlerthread thread = new handlerthread ("servicestartarguments", <br/> process. thread_priority_background); <br/> thread. start (); </P> <p> // get the handlerthread's logoff and use it for our handler <br/> mserviceloaders = thread. getlooper (); <br/> mservicehandler = new servicehandler (mserviceloading ); <br/>}</P> <p> @ override <br/> Public int onstartcommand (intent, int flags, int startid) {<br/> toast. maketext (this, "service starting", toast. length_short ). show (); </P> <p> // For each start request, a message is sent to start work once, and <br/> // start ID is also passed, so when we finish a job, we know which request to stop. <br/> message MSG = mservicehandler. obtainmessage (); <br/> MSG. arg1 = startid; <br/> mservicehandler. sendmessage (MSG); </P> <p> // restart if the returned message is killed. <br/> return start_sticky; <br/>}</P> <p> @ override <br/> Public ibinder onbind (intent) {<br/> // we don't provide binding, so return NULL <br/> return NULL; <br/>}</P> <p> @ override <br/> Public void ondestroy () {<br/> toast. maketext (this, "service done", toast. length_short ). show (); <br/>}< br/>

As you can see, you have to do more work than when using intentservice.

However, because you process each onstartcommand () call, you can execute multiple requests at the same time. this example does not do that, but if it is what you need, you can create a new thread for each request and run them immediately (instead of waiting for the previous request to complete ).

Note that onstartcommand () must return an integer. this integer describes how the system continues the service in the event where the system kills it (as described above, the default Implementation of intentservice handles this for you, and you can rewrite it as well ). onstartcommand () must also return one of the following constants:

• Start_not_sticky

  If the system kills the service after onstartcommand () is returned, do not re-create the service unless there is a pending intent that needs to be transmitted. this is the best option to avoid running your service when it is unnecessary and when your application can simply restart any unfinished work.

• Start_sticky

  If the system kills this service after onstartcommand () is returned, it will re-create this service and call onstartcommand (), but will not resend the last intent, instead, an nullintent is used to call onstartcommand (), unless there are some pending intent, in which case the pending intent is dispatched. this is suitable for media players (or similar services). It does not execute commands, but runs indefinitely and waits for a job.

• Start_redeliver_intent

  If the system kills the service after onstartcommand () is returned, re-create the service and use the last intent to call onstartcommand (). any pending intent is delivered sequentially. this is suitable for services that actively execute a job and should be restored immediately, such as downloading a file.