CODEWITHSUNDEEP
androidandroid-service
wodzu
wodzu

Reputation: 3172

Difference between using a binder and onHandleIntent at IntentService classes

According to the Android API an IntentService derived class creates a new worker thread for each received intent and passes it to the onHandleIntent() implementation.

So I assume (correct me if I'm wrong) my implementation should distinguish between all different kinds of intents I want to receive and then call a corresponding method within my service which handles this request. This would be all done within the worker thread, which has been created automatically in the onStartCommand() method.

My Question is, if a call to a binder, which just encapsulates the public methods of my service (see "Extending the Binder class" section) is being performed, will those methods be performed in dedicated worker theads as well? Or will it be done within the main app's thread? If I wanted to call a method from a homescreen Widget, would I need an additional Messenger to delegate those calls?

When do I use which approach anyway (Binder and onStartCommand())?

Upvotes: 1

Views: 1986

Answers (1)

s.d
s.d

Reputation: 29436

IntentService is not built for binding purposes. The current implementation returns null from its onBind() method.

Furthermore, the current implementation handles all requests on separate single thread. (Specially created when service starts). Intent messages just queue up on that thread's handler.

If you extend IntentService, and simply provide a Binder to clients, the methods of binder will be called on same thread which invokes the methods.

If you implement your own extension of IBinder or use Messenger pattern, methods will be invoked on the thread you initiate the message Handler.

Upvotes: 4

Related Questions