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!
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 have a started service that handles a connection and that keep an array of objects. On the other hand, I have a singleton that should bind to that service in order to get one of the objects handled by the service. So, how could I bind the service from the singleton? Is it a good practice to bind the service when the singleton is initialized by using the application's context? Is there a better alternative?
Thanks in advance!
This is a perfectly good way to do it. Your singleton gets initialized and binds to the service using application context. The singleton will stay bound until the process hosting your singleton is killed by Android (or until you intentionally unbind). Be aware that if you intentionally unbind then you will need to intentionally bind again if your app starts again before Android has destroyed the hosting process (or you'll need to destroy your singleton so it gets reinitialized later).
In the case where Android kills your process and the user returns to the app, your singleton will get recreated and will rebind to the service.
My Android app runs a service instance that is not accessible from other apps. I know that the service runs in the same process the app's Activity, because I can read and write to a static variable on the Service class from the activity and the Service sees the changes.
Communicating with the service via static variables/methods (or more properly singletons), is much, much simpler than communicating with it using a Handler or an Intent, which requires making all passed parameters Parcelable. It seems like these two communication methods are really designed for services running in a separate process, and are unnecessary overhead for an in-process service.
It seems like I must be missing something big. What is wrong with using a singleton to talk to a service if you know it is local to your app?
Communicating between a Service and an Activity is one of the main reasons to use a bound service: you can build a Binder class that defines the interface between your Service and Activity and pass any objects you want between them without having to worry about parcelling them (as binders require both to be on the same process).
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..
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!