Which is the best way to use binded service? - android

I have few activities and a single service in my app. Most of these activities need to bind to this service and use the services offered by it. There is only one entry point into the app and that activity binds to this service. Once the service is bound i get the instance of my service and save it in a static reference. Would it be okay if i use this same static reference in other activities to make use of the services offered by the service? Or do I have to bind to the service from every activity that wants to use the service?

No. You should update each individual Activity to bind to the service. You should not count on a static reference being retained in memory.

Maybe it is even better to start service from "entry point activities" and then to bind other activities to the service when u need it later..

Related

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:
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.

How to bind multiple activities to a service

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

Best practice for communication with service in android

What is better and right, use singlenton object that bind to the service on start app, or binding to service and unbinding from service in every activitiy, that use it?
To bind to a service you need a context. If you implement a singleton object and base its context on an activity you will have trouble as the activity may not live for the duration that you access the service.
If you take the context from the application you will run into the trouble of establishing when to disconnect from the service and may get memory leaks / unnecessary use of memory.
I would recommend binding to the service per activity but use a inheritence-scheme to only have to write the code once.
Best of luck!

Is there a way to get a service in Android synchronously?

I need to grab a service synchronously in Android. I'm sure it's already running, I just need to access it in my adapter. Should I just pass a reference once the service becomes available, or can I use something to the effect of context.getService(...) to get it? What is the recommended solution?
I believe you have an activity where the adapter is created and destroyed. Therefore the adapter's lifecycle should match the lifecycle of your activity. The conclusion would be to pass a reference of the service to the adapter on its creation, as it is the activity that binds and unbinds the service. :-)
What you are interested in is the concept of making a bound service. Take a look at the Local Service Sample example on the Service SDK page:
http://developer.android.com/reference/android/app/Service.html
This example shows how to bind to a service you create so you can get a standing reference to it and make direct calls to it while you are bound. When you bind/unbind to a service in this fashion, you also do not have to worry about calling start and stop explicitly. The service is only running as long as there is at least one component bound to it.
Hope that helps!

Android: Get an instance from a service running

I have a service running in background. I started it from an Activity, but I want to recover an instance of that service from another activity (in the same app) in order to call one method.
Is it possible?
There is only one instance of the service, at most. You cannot have two instances. Hence, just have the second activity bind to the service ("recovery an instance").

Categories

Resources