I have a service that opens a Bluetooth connection to a device. I need to have access to this connection from 2 activities. I know how to bind one activity to a service but what if I need to bind 2 activities to a service.
If I bind to the second activity to the service, will it create a second instance of the service?
The other answer is not really correct (I don't think they read their own doc references). You can bind multiple times to a service without any problems. Each connection to the service will operate independently of each other, and their ServiceConnection objects will reflect when they independently connect and disconnect.
There will only ever be one instance of a service as defined in the manifest. When a client is bound for the first time, the service object will be created. Each new client will not create a new object instance of that service. But when the last client is unbound, the service destroy (as long as it is not also currently "started") by onStartCommand.
You can verify all this behavior by using well-placed log statements in your code.
will it create a second instance of the service?
Yes, it does
However, multiple instance of the same service cannot be run simultaneously!
Possible solution to your problem would be :to bind the Service in the onResume() method, and unbind it in the onPause() method. This allows you to give two un-related Activities access to the service, while only having one bound at a time.
For further info, read these questions as well:
here
here
Also, consider reading this article on local bound services
Related
I have a service, I need to communicate to with it (one service - many fragments/activities). There are two options for this:
Have a singleton that controls the service - starts it and then binds to it (using the app context)
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).
Bound and unbound services are both usable patterns and you should pick whatever pattern is better for you use case.
You should pick bound service if you want your service to have the same lifecycle as the components that bind to it. If you need an independent service use an unbound version.
The only benefit of one approach versus another is the simplicity of implementation.
In you case, I think you need the service only while there are running activities and fragments, then the easiest way, in my opinion, would be to make a bound service and make every activity bind to it. With that, you'll get a simple communication interface between you activities (and fragments, since they have access to containing activity) and your service.
The benefits of this approach are:
the service will stop itself if all activities unbind and start itself when first activity binds to it.
you won't need to track all running activities in the singleton and manually unbind
you won't need to maintain a singleton manager, less code -> less bugs
sometimes onDestroy can be skipped by the system and you can leak the service with the 2 approach.
Since you need your service to be running the correct option will be to use a started service and make each activity bind to it when needed. It's a common pattern.
Started service will run until you explicitly stop it or it stops itself, you can have a singleton manager that will be responsible for that.
But at the same time you can communicate with the service from your activity using binding.
So basically comparing with the first suggested approach, you'll need some instance that will start and stop the service, but the communication between activities and service will be the same - using binding.
Yes, using a bound service in Android is a much better option when communicating with Views like Activities/Fragments. This is because of the following reasons,
It runs synchronously.
You can have more control on the service data when to show on UI thread of the view. You can choose when to call it in async/sync way.
LocalBroadcastManager only runs Asynchronously.
I am trying to dive deep into service architecture.
Just for testing purpose I am creating music app.
Without doubts music should be played in service, but what kind of communication to use ?
As far as I know service can be bound or started (or both at the same time)
Firstly, I need to play/stop/pause/set source...
Secondly, I need to notify UI if music player is opened about events like progress, buffering...
Here my thoughts about this.
I think about mixing bound and started service.
As far as song can be set only from UI as well as paused/played/stopped/seek I choose communication with service from UI using binder. (Bound service inside activity and get binder back to communicate with service)
Notifications like track completed, next track , current track position coming from the service. I decided to use Broadcast receiver to send such notifications, because it can be multiple interested components.
So my question are
What is the best choice of communication (bound or broadcast) for music player service ?
How does System knows what kind of service is ? I mean that even if the service is bound I need to call startService method at first and than bind it. Does it mean that if even one bindService method was called it is considered as bound service and it would be killed when unbind method is called ?
Does LocalBroadcastManager make sense in communication with service ? As far as LocalBroadcastManager is local for each app, why not to use bound service than ? Global broadcast makes sense in case other apps are interested in events.
Please help to understand this mechanism.
Best choice of communication is using both LocalBroadcasts as well as Binder methods as per your requirement. If you want to do something in service from your bound component like activity then you should use binders. If you need to send result back to application you should use LocalBroadcast.
There is one more option available to use messaging. In this case both activity and service use same ibinder hence two way communication is easy. You can send message from activity to service and service to your activity
In this point you are wrong about starting bound service. You don't need to call startservice in this case. Just a call of bindservice method is required.
bindService(new Intent(this, MessengerService.class), mConnection,
Context.BIND_AUTO_CREATE);
you can bind multiple components to this service. When all of them are unbound then service will be stopped.
Yes LocalBroadcastmanagers make sense. Lets say you want to broadcast something in your app. There are 4-5 components that you want to update.How will you achieve this. Hence the use of localbroadcasts is a good feature.
For example lets say there are two services starting from different activities and second service starts its work when first service has done its work. So, only way to achieve this is send a broadcast and second service will be registering for this broadcast. Hence it will receive it.
Yeah. Services are pretty hard to understand.
There are some things that are easy. A bound service is always started with a bindService method. A started service is always started with a startService method. You do not need to start a bound service, or bind a started service.
A lot of what follows is gross generalization...
Started Service
A started service is nearly useless, unless it is an IntentService. IntentServices are pretty good tools for running asynchronous tasks. You send them a small bundle of parameters and they go off and do whatever those parameters indicate. They are like void methods in that one expects to use their side-effects, not a return value.
Bound Service
A bound service is harder to explain. Although the metaphor breaks down on careful examination, a bound service something like a singleton factory. It is, for instance, a way of providing a single object, with is single state, to all of the Activities in a application. Among its interesting features is that, as long as the service that provided the singleton object is bound, the hosting process is less likely to be killed off. Note that, the "singleton" object that the bound service provides has little to do with the service that provides it. Unbinding the service does not invalidate it.
Bound services are also the main means of doing inter-process communication, in Android.
What should you do?
Well, that's a pretty general question. Here's a thought. Putting your music player in a service makes a lot of sense. If the communication to it is mostly one way -- commands to the service -- there is a chance that you can do it with an IntentService. Until there's a specific reason to do something more complex, an IntentService has the advantage of being simpler.
I want to use a started (foreground) service to manage a network connection that should persist when the user leaves the application for a short time, and that the user should be aware of (so he can return to the app and maybe disconnect). This service will only ever be used locally by activities in the same process.
Maybe it's just because I am new to Android, but I find it unnecessarily difficult to bind to this service in every activity that uses it - in particular, the asynchronous nature of binding, which only really seems to be necessary for accessing services in a different process. Is there any indication against just accessing the started service through a static variable instead?
Maybe I'm understanding your question wrong, but there is no need to bind to the started Service from every Activity. Instead, you could simply start the Service from wherever you need to interact with it. This calls the onStartCommand() if the Service is already started. You could include an extra with the Intent that starts the Service to distinguish between the first start and subsequent ones.
Of course - this addresses the use case where you do not want to have a client-server mode of interaction between your activities and the Service - that scenario requires binding and if you really need binding, then you need to bind from every component that needs to be served by the Service.
Right now the main Activity (Act. A) starts a Service which holds the Bluetooth Connection.
(It binds the Service)
The Service is a modified version of BluetoothChatService (Android BluetoothChat Sample)...
... modified with an added Messenger and Handler in accordance with MessengerService (Android Remote Messenger Sample)
Activity A makes sure that the Bluetooth is connected to an external device, and later starts another activity (Act. B).
The problem is to get the Service to keep running and serve the Bluetooth Connection to the new activity smoothly. I don't know how to:
Make sure that the Service is not restarted or reinstanced, when it switches from activity A to B
Make sure that the messenging functionality works as desired (from the currently active activity)
Do I need to rebind the Service to the new activity, and how do I assure that the BT connection is not lost (due to other instance of Service)?
Or do i need to pass along the Messenger object to the new activity to communicate with the alread instantiated Service. If so, how do I do that best?
Very thankful for answers!
Make the service "sticky" so that it will continue to run. And create a base Activity class for your 2 activities. The base Activity class can handle all the common functionality of binding with the service and providing the proper communication. I would definitely recommend unbinding your service when the activities pause and re binding them in the activities when they resume. But this can be done once in the common base class activity.
Binding to the service should only start it if it is not already running and if you bind/unbind in Resume/Pause you should have only one active connection to the service at any given time.
You either subclass Application and store information in there (see here), or you could make your "service" a singleton, so it has a static member of its own type that you initialize only if it's null.
This is an old question, but I ran across this situation today and came up with a solution that works based on the other responses. Since I couldn't find a working implementation, I will post it up for others who may be curious. I created a "sticky service" and then a ServiceManager class that is responsible for managing the life-cycle and binding for the Service. Then I put the ServiceManager class into a sub-class of Application so the Activities can access it as a scoped global. It works well. Source is available on GitHub.
I have a situation which I will try to explain clearly. I have two services, Service A and Service B.
Activity C connects to service A using onBind(). Service A connectes to Service B using a callback object. I want Service A's onbind to not be executed until Service B is connected to Service A. What will be a good way to achieve this?
The right answer is: combine the two services into one.
The next-best answer is: redesign your app such that A is not binding to B, or that C does not care whether A is bound to B.
You can't delay the call from the onBind. If your service's interaction is such that it may not be ready for use until later, you could have a method on the interface returned by onBind that allows a client to get a callback when it is ready. (You could even have this set up where the main interface is just "getRealInterface" that takes a callback, which is given the real interface for your service once you are ready to give it.)