I have a user login screen. The user presses a login button and I create an IntentService to connect to my rest services and return back a authentication result.
Now here's the functionality I want to achieve: If the activity is paused (i.e. goes into the background) then the intent service should still run, and it does. But if I use the task manager to kill the application, the intent service should stop, although right now it doesn't. It continues executing onHandleIntent until complete. If I manually call stopSelf(), onDestroy() is called but the onHandleIntent method continues to execute. How do I force the onHandleIntent to stop? Calling "return" is not an option because it could be caught up in one rest method call.
Should I be using intent service for this functionality or something else (like service or asynctask)?
First off, if your service is doing something that you want done while your app is running in the foreground, then you don't need a Service. Your activity or dialog can just spawn a thread to do your task, and these threads will end when your app ends, since they are within the task scope of your app. Otherwise, for tasks you want done all the time, when the user could be doing anything on the device, definitely use a Service.
I'm not sure why "calling return" is not an option for you? By this I assume you mean checking for a condition, and exiting the loop or block if the condition is met. This is generally how threads (in services or elsewhere) should end (although there are other approaches). Your service's thread can listen to a specific event that has occurred (like if the activity has been destroyed, by setting a property in a file or database when the activity's onDestroy is called, though if this is what you want then you probably should NOT use a Service), and then run() can return gracefully.
But if this is a task you want done no matter what the user is doing on his device (within or outside of your app), then it should be a task that should not be interrupted from the outside. It should keep going until it's done.
Maybe if you could better define when you want this service to be stopped?
stop it in your onDestroy() method
Related
I am new to IntentServices. I am using My IntentSevice to perform background webservices call. My application requires the user to sign in...
when the user signs in, the IntentService is started and in the onHandleIntent method I declared a TimerTask that runs every amount of minutes (please inform me if its the best solution to periodically perform a task in IntentService).
My question is, how can I stop the IntentService from periodically executing if the application was closed or the user signs out.
what I tried:
when the user signs out, i am cancelling the timer task. and so the webservices calls stop, but i don't know how to properly do that in case the application force quits (should i handle this or the IntentService will stop by itself in my case). also is cancelling the timer enough? (when the user signs in again, the IntentService will be called again so is that good?)
you should use the stopping method whenever you want to stop the service.
When ever you want to stop service just use "stopSelf();" method with in the service class.
By the way,the background services automatically destroyed when the application is removed from Ram.But You want to end the service with in the application then use "stopSelf();" method.
I hope this will help you.
There is some long processing that need to be completed, so I put it in a service. The activity must be able to connect to the service, show the user current results from the service. So I start the service with start Service and later call bind Service (with BIND_AUTO_CREATE) as in LocalService from http://developer.android.com/reference/android/app/Service.html#ServiceLifecycle. I want it to run until its job is done, and then self stop, even if client is still connected to it. (or determine the client to unbind) Is any way to do it with the sample LocalService?
I was considering passing a handler to the service so that it can send messages back to the activity, but I don't want the activity to get leaked. I am just getting used with services, so maybe I am misusing something.
EDIT: The workload consists of several threads, synchronized and run in parallel, so I guess is not a good candidate for intent service. Some data analysis is done in background service, and when the user restarts the activity that started the service, it should display some graphics according to current values computed by background service. All background processing is triggered at the beginning, and need only inspection later on, when activity connects to it. Android should not be able to stop the service. When the job is finished, the service should be able to terminate even if the activity is connected to it.
I just recorded a callback with the service. If the activity is not connected to service, it sets the callback to null. In this callback I call stopService() and then finish() on the activity. I am not sure that it is the best method, but it works fine for me.
If you want a service to be stopped when it is finished, I think what you are looking for is IntentService, they work as services, but run in another thread and when they are completed they dissappear.
Check this out
EDIT: NickT link is better, check that out! :)
I have an activity in which I do server sync with a back end server using a subclass of asyctask.
Given it is a network task and might take couple of seconds. I am afraid of the following scenario to take place.
The activity starts, and whenever the asynctask should start to run, it does so.
The onPrexecute() is called, executed, and over. Than the doInBackground() is called, and is done so, however, just when the method is being executed, the user presses the home button and swipes the app from the RECENT APPS. (this ofcourse causes the app to terminate and all the onDestroy methods get called of the alive activities..(Correct me if I'm wrong on this one)).
In my onPostExecute() method, I am inserting the data to DB and updating the VIEWs.
But since the app is 'terminated' the onPostExecute() method never runs.
my questions are :
When the user presses the home button and gets out of the app and swipes the app, is doInBackground halted at that moment ? that is, it is cut in the middle and does not continue what it does ?
What happens to the data that I was going to get from the server and put inside the DB ? Is it advisable to do put the data in the db inside the doInBackground ?
AsyncTask is a background task it will continue to run even if the app is closed and onDestroy() is called. The problem would be when the task enters onPostExecute() and tries to update any views associated with the activity it is bound to, as that activity no longer exists. If you're concerned about this, one thing I've done is to keep a reference to that AsyncTask in the calling activity, and then call the method myAsyncTaskReference.cancel(true) to cancel it in the onDestroy() of the calling activity.
Yes, I would put the DB operations in the doInBackground() method, as that runs in the background on a separate thread, and doesn't require a reference to the app activity.
Have you considered using a service for this type of thing instead? I would strongly recommend an IntentService, which is a subclass of service which is specifically designed to perform a single task in the background (similar to AsyncTask), and then kill itself once completed. It's quite easy to implement and usually only involves overriding one method - onHandleIntent() - which is called when the service starts.
It can handle all your DB operations and it has no reference to an activity and so the problem you're worried about in #1 would never occur. If you need to update a view, you can have your IntentService generate a broadcast once it's completed, and your Activity can register for that broadcast and update it's views accordingly when it receives it. And if your activity is no longer around once the broadcast is sent then it doesn't matter and nothing will fail.
When user presses 'Home', your Activtiy will pause but doInBackground will NOT, but may or may not terminate by system when system feels like it. Activity's onPause will be called. Your Asynctask doInBackGround will NOT halt. It will continue to run until the system kills your App process.
Yes, Db operations can take long. Its advisable to put in doInBackground because it runs on another Thread. onpre/onpostexcute runs on the main thread. If you are worried that System may terminate half way of your db operations, you shouse set Transcation, and only when you are done, you called commit.
Check out this post, I have tested it.
no, it doesn't stop.
It is relly better to put it to datastorage of some kind and then work with it
It is always better to use service for such goals. AsyncTasks just don't fit here. Ask your service to do the work, and then you may start or quit activities as you wish to.
If swiping app from recent stack, it is equivalent to close the app hence it will kill all tasks related to the process so async task will also get killed by the android system. ( even intent service is also get killed)
It is device dependent also. Manufacturers customised removing app from recents behaviour
I have a class that implements fileuploader service. Activites bind to it and supply it a list of files to be uploaded, and then unbind immediately. The files are then uploaded one-by-one by the service in a background thread(asynctask).
I start this service in my dashboard actvity using startService(), so that it keeps running until specifically stopService() is called.
Now, my question is when do I stop this service?
Basically I need to check two conditions: 1: all files are uploaded; 2: app has exited.
Also, to exit the App, user has to press back button on dashboard activity.
I could have overrided back button press and queriesd the service whether any files are left, but I dont want to use that method.
Any suggestions?
Activites bind to it and supply it a list of files to be uploaded, and then unbind immediately.
I would recommend then using startService() rather than bindService().
The files are then uploaded one-by-one by the service in a background thread(asynctask).
This seems like a much better fit for startService() and an IntentService (or a WakefulIntentService perhaps, if you are concerned about the device falling asleep during uploads).
I start this service in my dashboard actvity using startService()
This would not be needed if you used startService() for sending over the work.
so that it keeps running until specifically stopService() is called.
Ideally, the service would shut itself down, like IntentService does. After all, only the service knows when the service is done.
my question is when do I stop this service?
When you have no more work to do. IntentService does this automatically. If you really want to maintain your own thread pool for doing the work, then when your work queue is empty and all threads are done, call stopSelf() from within the service.
Basically I need to check two conditions: 1: all files are uploaded
Yes.
2: app has exited
No. Your UI should not care whether the service is running or not running. The service should take care of itself.
Also, to exit the App, user has to press back button on dashboard activity.
Users are welcome to leave your app however they please: BACK, HOME, RECENTS, a Notification, an incoming phone call, etc.
Any suggestions?
Use an IntentService. Send over the jobs to be uploaded via calls to startService(), packaging all needed data into the Intent used with startService() (e.g., extras). Do your upload work in onHandleIntent(). If desired, use LocalBroadcastManager to let activities in your app know about the upload status, so they can reflect that in their UI if they so choose. IntentService will handle stopping itself when its work queue empties.
My android application starts a service in the onCreate() callback of a class that extends Application. The service performs some background tasks that are relevant to the user only while the application is running. For that reason I would like to close the service when the application's last activity is closed. I've tried to perform closing the service in the callback onTerminate() , but it never gets called . So what would be the best place where a service should be closed ?
Thanks !
An Android service, once started, will continue running until the Context.stopService() or stopSelf() is called.
There are various hooks you can use to stop the service using Context.stopService (the service itself, or an onDestroy()/onPause callback in one of the activities, or a button click).
It's true that Android does some resource management itself, but it can take a long time before Android decides to terminate your services. And a service that's running but not doing anything just consumes resources on the phone that other apps might need.
In your case, the onPause method of your last activity would be a good that will get called, and as such is the correct place to stop the service.
The onPause() callback will be made when your activity is paused for any reason, and you know that when this happens your app will not be visible again until onResume() is called. If your service has a reason to run in the use case that your activity might be started again soon, you should add an entry to your service that onPause() calls, to set a delayed service termination. In onResume() you can cancel that delayed termination through another entry.