I have a service which provides current location of the device. Several activities in my app can call this service at the same time. If I call stopService() in an activity, can it make the service running in different activity stop? I have read Android document but still confused about that. Please make it clear for me. Thanks.
There is only one instance of the service. You can call startService() from multiple activities, but it will have only one instance. As soon as any of the activities calls stopService() it will be stopped for all activities.
Related
I have a doubt that if i start a periodic service using alarm manager and start the service from the onCreate method of an activity. How can i prevent the service from triggering multiple times if that activity is launched again and again.
Assuming that you are creating a Normal Service (and not an IntentService), as per the Android Service documentation, when app invokes startService call, service will be instantiated and started (creating a process for it if needed).
Also, if it is running then it remains running.
So, to put it in simple terms,
Life cycle of "Started" service is independent of the life cycle of
Activity which has started this service. This is true irrespective
weather both are running in same process or different processes
So even though your Activity may be getting created multiple times, and if Service you created earlier is still running, then service object that already exists will be reused.
However, if there is a call to startService() from onCreate() of an Activity, this will invoke each time onStartCommand().
Hence, you need to ensure that you have a appropriate code/logic to handle multiple invocations of onStartCommand()
As far as I understood you must do something in either onCreate/onStart and onStop or onResume and onPaused. By do something I mean, in onCreate create what you need, alarm manager, etc then in onStart you can start the service and in onStop you stop the service or unBind from it, in case you want a foreground service. or in onResume or onStop.
Take a look here:
https://github.com/toaderandrei/live_tracking/blob/master/app/src/main/java/com/ant/track/activities/ServiceConnectActivity.java.
It is a tracking app that is based on MyTracks app from google.
I want to write an android service that will run with an app. I want to run this service across multiple activities and have the ability to pass information back to the UI with all activities, not just the activity that starts the service.
From what I understand, I have call startService and not bind it to the activity. Is this correct?
Also, I do not want to start a new instance of the service, I want to use the same instance. If i call startService in each activity, will that use the same, running instance of the service?
startService will start the service only if there's not a previous service running, it won't spawn a second service.
Once you start your service, you can connect to it from any Activity you want, but to pass information back and forth, you need to bind to the service, so you can obtain a pointer to it.
Make sure to read Android's documentation, because the way services work is a little confusing at the beginning.
I have an Activity that starts a service. When the activity is closed, I want the service to continue running in the background. I have a couple of questions here.
Will closing the activity screen cause the activity to actually stop? Or do I need to forcibly stop it to cause it to stop?
If closing the screen does cause it to stop, then I assume I need to use startService to start it. Is that correct? If that is the case, is there a way to get a handle to the running service next time the activity starts? If it is not the case, then I can just bind to the service.
When your Activity is no longer visible on the screen, it is stopped. Stopping an Activity bound to a Service does not stop the Service. However, you'll want to make sure you unbind from the Service when your Activity calls onDestroy() to make sure you don't have any dangling handlers and suchlike.
You can rebind to a running Service the same way as you did the first time. Sending an Intent to start a Service that's already running doesn't create a second instance of it, so that's safe.
A good way to start a Service like you're describing is to start it using the Context.BIND_AUTO_CREATE argument to your call to bindService().
The details of all of this can be found at the Android docs about bound services. It can be a little confusing at first. Follow the tutorial code closely since it sounds like your problem maps well onto the sample they provide.
I need an advice for my latest app. It will show the user the latest subtitles released, and it will give him a notification in case new subtitles of his favourite series have been released; what should I use to achieve this?
I was thinking to create and run a service which will include a
timer.scheduleAtFixedRate(new TimerTask() {...
but at the same time I really don't know how to make it interact with my app (if the app is opened I don't need any notification but I need to update the GUI).
I could use a thread but I'd like it to run it even after the main activity has been killed...
or I could use a AsyncTask so it would be easier to deal with the Application GUI.
Which solution should I use? I was thinking I should simply use a service (the first solution), but I'm not too sure about it, and furthermore I don't know if there is any way to make a service communicate with an activity periodically...
Thanks for your help.
A service communicating with an activity is called bound service, that's what you should use IMO.
However, you say that when the activity dies, the service should keep running. But if the service is bound to your activity and the activity is dies, the service dies too.
I suggest you to read here about it.
Check and see if you can bind a service to an activity, and when it dies, unbind and let the service continue to run independently.
If you can't, the activity could unbind itself, then start the service independently (with startService rather than bindService).
if you are showing notifications, why not use C2DM messages for communicating with the app. The only thing would be that there would be popups shown to the user even if your app is not running. No need to use threads/services.
I have an Android app, in which Activities fire long running operations that run in the background. These operations interact with the Activities when done. I'm developing a component that handles the Activity/Long-Running-Task coupling, taking care of activities being destroyed and recreated.
Right now that component is implemented as an Android service. The activities call bindService and use the resulting IBinder to start and track tasks. I decided against using startService, because I prefer the richer API possible through a Java interface.
Now the problem. Activity A start ups, binds to the service and calls serviceApi.runTask(...). Activity A is then destroyed (because the user flips the phone, for instance) and recreated as Activity A'. A' then binds again to the service, announces its existence and everything should be running nicely.
Except that my Service gets destroyed. When Activity A is destroyed, it unbinds from the service. Android sees there are no more clients, and kills the service. When Activity A' is created, the service is created again, and I lose everything the old service had.
The only solution I can see is using a singleton for the service. And then it doesn't really have to be an Android service, just an instance that's accessible to everyone. Is that frowned upon in Android? Is there a better design that fits this problem?
Editted: Even if I call startService and then bind to it, nothing guarantees that the service instance will exist as long as the application is running. Android can kill sticky services if resources are low. Killing the service will cause the application to malfunction, and I can't have that.
Even if I call startService and then bind to it, nothing guarantees that the service instance will exist as long as the application is running.
Correct.
Android can kill sticky services if resources are low.
Also correct. All "sticky" means is that Android might restart the service.
Killing the service will cause the application to malfunction, and I can't have that.
It is impossible to create a service that is guaranteed to run forever. For starters, users can get rid of your service whenever they want, because users detest developers who have pointless services that run forever. Writing everlasting services is necessary only in very few cases; otherwise, it's just sloppy programming.
The only solution I can see is using a singleton for the service. And then it doesn't really have to be an Android service, just an instance that's accessible to everyone. Is that frowned upon in Android?
Singletons (a.k.a., static data members) will go away when the process is terminated. The process will be terminated eventually, particularly if there are no active services and none of your activities is in the foreground..
Call startService and in onStartCommand return START_STICKY. It should keep the service going.
You may also want to look into foreground services:
http://developer.android.com/reference/android/app/Service.html#startForeground(int, android.app.Notification)
Yo have to create persistent service. Refer to this manual.
In a few words - don't call bindService, call startService.