Thursday 19 July 2018

Bound Service vs Unbound + singleton for communication

I have a service, I need to communicate to with it (one service - many fragments/activities). There are two options for this:

  1. Have a singleton that controls the service - starts it and then binds to it (using the app context)
  2. Have a singleton that controls the service - starts it, the service when ready registers back as a delegate to the singleton (in a WeakReference)

Solution no 2 seems simpler to me, but whenever I read about communication with services there is the concept of the bound service.

Is there any benefit of having a bound service instead of the service registering itself as a delegate (and unregistering with onDestroy)?

Edit 1: The service is to keep the communication alive, it's expensive to set up a new communication channel. Even if no one requested any data it should keep the channel alive (heartbeat).

The service is foreground, it should run even if the activity that requested the data gets killed by the system. The next time it is created the data will be there. The data requested by one screen might be useful for some other (therefore has to be stored in a singleton).



from Bound Service vs Unbound + singleton for communication

No comments:

Post a Comment