asynchronous queries vs queries from a service module

A service module's code runs in the main thread. When you are running your batch of non-querries in the service it is still blocking the main thread (no other code can be executed) until the querries return.
Using asynchronous querries will always be better as long as they are a background process (i.e. you do not need the results immediately). They will not block the UI thread, and your app will be more responsive.

thedesolatesoul said:

A service module is still not asynchronous. Its code runs in the main thread. When you are running your batch of non-querries in the service it is still blocking the main thread (no other code can be executed) until the querries return.
Using asynchronous querries will always be better as long as they are a background process (i.e. you do not need the results immediately). They will not block the UI thread, and your app will be more responsive.

Click to expand...

Sorry for not mentioning it: The service module I use has a UI with just a 'start' and 'stop' button, for starting and stopping the service.
But, now that you say it: Sure that your first statement is 100% correct? In another app (client side) I use a service for non-queries, while at the same time I get back to a previous activity loading data by quering again. While this activity finishes loading, I can still see the icon of the foreground service, meaning (?) that the non-queries are still under process

Maybe I worded it incorrectly, I consider services to be async (due to the dynamic timing), yet they run on the same thread.

Without looking at your code it is impossible to say, but it is possible the main thread is ping-ponging between the subs in your service and main whenever it gets a break in between.

Have a look at this thread: http://www.b4x.com/forum/basic4android-updates-questions/9835-q-threads-b4a.html

Ty man!
Now about my code, nothing significant, just ordinary non-queries from a service, while refreshing an activity. Sure I can make a simple project and we can see what's happening. Either way, the whole subject is very interesting, while I think that asynchronous methods are surely great. I just don't want to begin a process of reconstructing a whole project, if I am not 100% sure that the new method is truly better in this particular case

thedesolatesoul is 100% correct. The service code runs in the main thread. There can be many services running at the same time. However the code is executed by the main thread.

If you create a very long loop in a service then the whole app will pause until it completes.

Ok, got to test the whole thing.
You're both right. The reason I've thought that this was not the case, was purely due to the small amount of time needed for my non-queries to be performed, so delay was just really small.
Attached source for non-quering from inside a service module. I'm inserting 10,000 integers. Takes again a small amount of time, yet, it's obvious that nothing else is working during this small period.
If I put a doEvents, events are triggered (no surprise, this is why it's named doEvents), yet, things can go bad, a forceClose is quite luckily to appear upon repeated button clicks. Thus, doEvents is not recommended in this case (at least I will never get to use it in such things).
Conclusion: I will keep my app running the way it does, since I perform no more than a dozen simple queries each time.
BUT, if and when, I need to perform a much bigger transaction, I will turn to aSync quering, thus it's really nice that we now have this option!
Thank you both for the info, it's really helpful!