I have done a lot of research on this, but still not sure if I can connect to an android service synchronously. startService() and bindService() service calls are asynchronous by nature and what I'm trying to do is make this behavior synchronous.
I tried writing startService(), bindService() and ServiceConnection object initialization (contains onServiceConnected() etc.) in a separate thread which is started from the main thread. And the main thread waits until onServiceConnected() is invoked on another thread and service object gets initialized, but since onServiceConnected() is only invoked by the main thread (http://developer.android.com/reference/android/content/ServiceConnection.html) which is blocked due to wait call, it forms a deadlock.
Does anyone know if my above reasoning is correct/incorrect? Is there another way to achieve the synchronous behavior? Or the only option is to invoke service functions after onServiceConnected() callback happens?
EDIT: (to explain it's not the exact duplicate of other question)
In the other question, the application connects with the service asynchronously and expect it to behave synchronously as it mentioned "By adding all kinds of Log.xx I found that the code after if(bindService(...)) actually goes BEFORE ServiceConnection.onServiceConnected is being called".
However, I'm already aware of this and the question is about if at all there is a way to connect with the service synchronously.
It's a VERY BAD IDEA to block Android's main thread. This will freeze the ENTIRE phone's UI.
If you're trying to prevent the user from doing anything between starting the binding and the connection succeeding, you could throw up a non-cancelable dialog, but it would only be up for a matter of milliseconds.
If your UI has a hard dependency on the Service being present, well, you should redesign so it isn't. By their design and nature, Services are asynchronous (from the UI) and transient. The system could kill them at any time to get more resources (though it probably won't). If it's a soft dependency (like an audio streaming app) you should just hide/change UI elements until the service binds.
So even if you find a way to do a synchronous bind, I ask you as an Android user and Android developer, please find a better way.
Related
There are several ways to connect to Service to Activity. I am only interested in local service and my LocalService will stand there untill user stops it(which also means end of app). I might know things wrong, if so please correct me.
On the reference page, it is stated that in order to use methods of local service directly, we should use ServiceConnection. After binding, we can have a reference to LocalService class, and we can use methods of this LocalService directly. AFAIK the methods we call using this reference run on main thread with relevant Activity.
The thing that confuses me, what if I use skeleton structure and access LocalService's methods by directly its static reference (ie. by LocalService.getInstance()). Well, I have already used it and did not face any problem, but still I am not sure which one is better, and why.
Thanks in advance. I might add additional info if requested.
edit:
In my previously mentioned solution, no activity is keeping a reference to the LocalService.
It is used to
start some LongRunningAsyncTasks(which are all halted and reference-nullified before service stop),
update the app Notification,
get getFilesDir(),
to keep an enum value (whose reference is not kept elsewhere, it is just used for comparison) in order to access from everywhere(not worthy of using SharedPreferences).
show some toasts
aware of static references of activities and services because they can be a reason of memory leak. if you don't want your service run in main process, then extract it into another process and work with service connection.
If you don't need any feedback from service, then just don't use connection and simply use startService() with several commands which will be executed in onStartCommand() method of the service.
If you need feedback from service, but not frequently, then use startService() and feedback from service with sendBroadcast() or through Handler class.
If you need feedback frequently (for example update slider of media player), then it's better to use service connection.
Remember that your service can be killed anytime without executing method onDestroy() and without any notification, that's why keeping static reference is not good idea.
It appears from what you are saying that you probably don't need a Service at all. Looks like you are not doing any long-standing task in your LocalService. If that's the case, you can as well use AsyncTask or Handlers and be done. The motivation to use a Service (Local or otherwise) is to do some long standing task inside it and not stall the main UI thread. If your tasks are not gonna take up too much time, then you don't need a Service.
The Service does run on the main thread by default. Unless it's an IntentService where a worker thread is created for you automatically and all tasks are queued and handled one at a time in this worker thread. Otherwise, it's your responsibility to create a separate thread for your service tasks.
So, first analyze if you really need a Service. If your task can quickly get executed, then don't bother having a Service even.
Hope that helps.
I have doubts when it comes to Services.
I know the service runs in the background, but I thought you necessarily needed to create a thread within the service, otherwise it would block the main thread and you would get an ANR error.
I thought I got it! But then I read this in the Android Developer guide:
…if your service performs intensive or blocking operations while the user interacts with an activity from the same application, the service will slow down activity performance. To avoid impacting application performance, you should start a new thread inside the service.>
The paragraph mentions "intensive or blocking operations", but doesn’t mention an ANR error, it mentions performance. So how a service works?
Supposing an Activity starts a Service. Does the Service run by default in the background of the main thread? Meaning that you can still use your activity while the service is running, but since your Activity and the Service are sharing the main thread’s resources, it would slow down the performance of your activity, and if Service is doing CPU intensive work, it could leave no resources for the activity to use, and eventually you would get an ANR error.
The best practice (but not necessarily, if the service is doing light work) would be to start a new Thread within the Service, now the Activity and the Service are using their own thread’s resources. Then you could close your activity, but Android keeps the service thread alive.
Is that it? Thanks =)
I thought you necessarily needed to create a thread within the service, otherwise it would block the main thread and you would get an ANR error.
Correct.
The paragraph mentions "intensive or blocking operations", but doesn’t mention an ANR error, it mentions performance.
Feel free to file a bug report at http://b.android.com to get them to improve this portion of the documentation. :-)
Does the Service run by default in the background of the main thread?
The lifecycle methods of a Service, such as onCreate() and onStartCommand(), are called on the main application thread. Some services, like IntentService, will provide you with a background thread (e.g., for onHandleIntent()), but that is specific to that particular subclass of Service.
and eventually you would get an ANR error.
Yes.
The best practice (but not necessarily, if the service is doing light work) would be to start a new Thread within the Service, now the Activity and the Service are using their own thread’s resources. Then you could close your activity, but Android keeps the service thread alive.
Basically, yes. Here, "light work" should be less than a millisecond or so. Also, some things that you might do are naturally asynchronous (e.g., playing a song via MediaPlayer), so it may be that the Service itself does not need its own thread, because something else that it is using is doing the threading.
I'm using Apache Commons to make my HTTP calls, and in my activity I have a thread that makes the call. If a call is made by a device and is sitting there waiting to connect (imagine that the network is congested and the call is taking some time) and in the mean time, the user exits the app and the Activity is backgrounded. What happens to my call? For that matter (come to think of it) what happens to any thread that was started within the activity? If I have a thread that's sitting there and doing its thing (whatever it is) and the activity is closed, do I have to handle killing the thread myself onPause()?
Edit...
So, given Ted Hopp's answer, what is the right way to kill the Apache request? I'm looking through the Commons documentation and there are a bunch of methods that *look like they would do the trick, but since the doc is so lacking in details (why even bother with a doc if you're not going to specify things?!) I'm wondering which of those methods I should call on my HttpConnection object before killing the thread that my connection is sitting in?
Closing an activity has no direct effect on the process in which the activity is hosted. All other threads continue running. You should override one or more of the life cycle methods (onPause, onDestroy, etc.) to detect that the activity is finishing and interrupt or otherwise terminate running threads. The activity method isFinishing() is useful for distinguishing between an activity being shut down and one that is being destroyed and restarted due to a configuration change.
Your thread should be written with a method to cancel execution. With apache-commons in particular, that method should have two steps. First, you should call abort() for the method that you passed to your HttpClient.execute() method. Second, you should close the connection itself:
client.getHttpConnectionManager()
.getConnection(client.getHostConfiguration()).close();
Actually, if you do just the last step, that should actually suffice to throw an IOException in the method and stop everything.
Google strongly advises developers not to make HTTP calls in an Activity. Service is the recommended model. Android apps are going to be paused for many, many reasons. Some of the most common are to answer a call, sms or email. I doubt that you want to cancel the call, and therefore have the user wait for it again when he/she returns, when it could all happen in the background.
The best option is to use a Service or IntentService to make the call and persist the data (perhaps into an SQLite database). When the Activity is resumed, it can simply check for new entries in the database.
If you haven't already seen it, check out the "Developing Android REST Client Applications" from Google I/O 2010. Be sure to notice the PDF download link.
Why do I read in the answer to most questions here a lot about AsyncTask and Loaders but nothing about Services? Are Services just not known very well or are they deprecated or have some bad attributes or something? What are the differences?
(By the way, I know that there are other threads about it, but none really states clear differences that help a developer to easily decide if he is better off using the one or the other for an actual problem.)
In some cases it is possible to accomplish the same task with either an AsyncTask or a Service however usually one is better suited to a task than the other.
AsyncTasks are designed for once-off time-consuming tasks that cannot be run of the UI thread. A common example is fetching/processing data when a button is pressed.
Services are designed to be continually running in the background. In the example above of fetching data when a button is pressed, you could start a service, let it fetch the data, and then stop it, but this is inefficient. It is far faster to use an AsyncTask that will run once, return the data, and be done.
If you need to be continually doing something in the background, though, a Service is your best bet. Examples of this include playing music, continually checking for new data, etc.
Also, as Sherif already said, services do not necessarily run off of the UI thread.
For the most part, Services are for when you want to run code even when your application's Activity isn't open. AsyncTasks are designed to make executing code off of the UI thread incredibly simple.
Services are completely different: Services are not threads!
Your Activity binds to a service and the service contains some functions that when called, blocks the calling thread. Your service might be used to change temperature from Celsius to Degrees. Any activity that binds can get this service.
However AsyncTask is a Thread that does some work in the background and at the same time has the ability to report results back to the calling thread.
Just a thought: A service may have a AsyncTask object!
Service is one of the components of the Android framework, which does not require UI to execute, which mean even when the app is not actively used by the user, you can perform some operation with service. That doesn't mean service will run in a separate thread, but it runs in main thread and operation can be performed in a separate thread when needed.
Examples usages are playing music in background, syncing data with server in backgroud without user interaction etc
AsyncTask on other hand is used for UI blocking tasks to be performed on a separate thread. It is same like creating a new thread and doing the task when all the tasks of creating and maintaining the threads and send back result to main thread are taken care by the AsyncTask
Example usage are fetching data from server, CRUD operations on content resolver etc
Service and asynctasks are almost doing the same thing,almost.using service or a asynctask depends on what is your requirement is.
as a example if you want to load data to a listview from a server after hitting some button or changing screen you better go with a asynctask.it runs parallel with main ui thread (runs in background).for run asynctack activity or your app should on main UI thread.after exit from the app there is no asynctask.
But services are not like that, once you start a service it can run after you exit from the app, unless you are stop the service.like i said it depends on your requirement.if you want to keep checking data receiving or check network state continuously you better go with service.
happy coding.
In few cases, you can achieve same functionality using both. Unlike Async Task, service has it's own life cycle and inherits Context (Service is more robust than an Async Task). Service can run even if you have exited the app. If you want to do something even after app closing and also need the context variable, you will go for Service.
Example: If you want to play a music and you don't want to pause if user leaves the app, you will definitely go for Service.
Comparison of a local, in-process, base class Service✱ to an AsyncTask:
✱ (This answer does not address exported services, or any service that runs in a process different from that of the client, since the expected use cases differ substantially from those of an AsyncTask. Also, in the interest of brevity, the nature of certain specialized Service subclasses (e.g., IntentService, JobService) will be ignored here.)
Process Lifetime
A Service represents, to the OS, "an application's desire to perform a longer-running operation while not interacting with the user" [ref].
While you have a Service running, Android understands that you don't want your process to be killed. This is also true whenever you have an Activity onscreen, and it is especially true when you are running a foreground service. (When all your application components go away, Android thinks, "Oh, now is a good time to kill this app, so I can free up resources".)
Also, depending on the last return value from Service.onCreate(), Android can attempt to "revive" apps/services that were killed due to resource pressure [ref].
AsyncTasks don't do any of that. It doesn't matter how many background threads you have running, or how hard they are working: Android will not keep your app alive just because your app is using the CPU. It has to have some way of knowing that your app still has work to do; that's why Services are registered with the OS, and AsyncTasks aren't.
Multithreading
AsyncTasks are all about creating a background thread on which to do work, and then presenting the result of that work to the UI thread in a threadsafe manner.
Each new AsyncTask execution generally results in more concurrency (more threads), subject to the limitations of the AsyncTasks's thread-pool [ref].
Service methods, on the other hand, are always invoked on the UI thread [ref]. This applies to onCreate(), onStartCommand(), onDestroy(), onServiceConnected(), etc. So, in some sense, Services don't "run" in the background. Once they start up (onCreate()), they just kinda "sit" there -- until it's time to clean up, execute an onStartCommand(), etc.
In other words, adding additional Services does not result in more concurrency. Service methods are not a good place to do large amounts of work, because they run on the UI thread.
Of course, you can extend Service, add your own methods, and call them from any thread you want. But if you do that, the responsibility for thread safety lies with you -- not the framework.
If you want to add a background thread (or some other sort of worker) to your Service, you are free to do so. You could start a background thread/AsyncTask in Service.onCreate(), for example. But not all use cases require this. For example:
You may wish to keep a Service running so you can continue getting location updates in the "background" (meaning, without necessarily having any Activities onscreen).
Or, you may want to keep your app alive just so you can keep an "implicit" BroadcastReceiver registered on a long-term basis (after API 26, you can't always do this via the manifest, so you have to register at runtime instead [ref]).
Neither of these use cases require a great deal of CPU activity; they just require that the app not be killed.
As Workers
Services are not task-oriented. They are not set up to "perform a task" and "deliver a result", like AsyncTasks are. Services do not solve any thread-safety problems (notwithstanding the fact that all methods execute on a single thread). AsyncTasks, on the other hand, handle that complexity for you.
Note that AsyncTask is slated for deprecation. But that doesn't mean your should replace your AsyncTasks with Services! (If you have learned anything from this answer, that much should be clear.)
TL;DR
Services are mostly there to "exist". They are like an off-screen Activity, providing a reason for the app to stay alive, while other components take care of doing the "work". AsyncTasks do "work", but they will not, in and of themselves, keep a process alive.
This is the scenario:
User has a main activity used for UI.
Program needs to communicate with peers and keep connection and wait for messages
When a message comes it is shown in the main activity.
So the question is should I use a service for the communication and what type of service?
And also should I use AsyncTask in the service in order to keep my UI responcive and why?
The important thing here is that any CPU intensive work or blocking I/O (including waiting for incoming network connections) occurs in a thread separate from your main UI thread.
If you just need network communication to stay running while your activity is alive, then use a second thread within your activity. If you need to maintain network communication even after your activity has been killed, you'll need to use a service.
Keep in mind that default behavior is for a service to share the same process and thread as anything else in the same application (including the activity that provides your UI). For this reason, even if you use a service, you'll still need to spawn a new thread to get the desired effect.
AsyncTask is used to perform a task in a separate thread that will eventually terminate and return a result. If this sounds like your application, then feel free to use it. But if you're keeping a port open across several requests (meaning you don't have a single return value), using this class would just be a burden.