Android Question Benefits of services

[Troberg]

I have an idea for an app that I know will remain the front app, with a main activity that will stay active, and I know the device won't go to sleep while using it. The app will need to do a lot of stuff in the background though (such as gathering data from various sensors, playing music and so on).

Is there any benefit to making these background tasks as services, or does it just add an unnecessary layer of complexity?

 

[sorex]

it depends on how the app is supposed to work, will you read out the sensors when the screen goes out?

if so you need a service as your app will pauses then.

 

[Troberg]

The screen won't go out, it's very much an always on app.

 

[thedesolatesoul]

If your app never pauses then you dont need a service.

 

[Erel]

Services are simpler than activities.
This is a secret known only to a few but it is the truth.

If your application has more than one activity than you should consider using services for any asynchronous task such as HttpUtils2.

 

[udg]

I would have said that a service could come in handy to avoid Main thread's halt by the OS due to very long and intensive processing.
That along with the async cases already cited by Erel.

 

[Erel]

I would have said that a service could come in handy to avoid Main thread's halt by the OS due to very long and intensive processing.

I'm afraid that this is a common mistake. Services run in the same main thread as the activities.

 

[udg]

Services run in the same main thread as the activities.

Hi Erel, let me understand it better.

A service (sticky or not) called by an intent set in the Manifest, its main activity empty.
When it come time for the OS to awake and launch that service, in memory we have:
- the process
- an empty activity
- the service
So, the service is running in the context of its "fake" activity? Is there active a single thread?
If so, we always need to think about manually starting a second thread when we know we have to deal with intensive processing.
I mean, main thread used just to call the service1 alive and service2 on secondary thread doing the heavy job. Am I right?

udg

 

[Erel]

There is no empty activity unless an activity was started.

Yes, the service code runs in the same thread like all other app.

What do you mean with intensive processing? Slow operations like network related operations are all done with background threads. There are very few cases where creating a second thread in your code is the correct solution.

 

[udg]

Sorry for the delay, but I had to go out with the family.

Intensive processing: I had in mind something like what it is discussed here.
In a scenario where his second activity is moved to a service for all the math, should we think of starting a dedicated thread for that service so to have no negative impact on Main's own thread or it will be ok to run it on the same thread with its activity?

There is no empty activity unless an activity was started.

Does this means that the OS reserves space in memory just for a process and the service called by the intent? Here I'm referring to the "manifest-case" I proposed in post#8, obviously.

I like the idea to have a "general" service callable from many apps. So any app aware of its existence could rely on its features and the occurence it is "always" in memory ready to reply. In this case I'm considering a bootable, sticky service, "empty" (i.e. no code) main activity and listening on some intents.

udg

ps: maybe the whole subject should be summarized in a tutorial titled "Services: how to properly use them" showing different recommended approaches for different cases.

 

[Troberg]

Services are simpler than activities.
This is a secret known only to a few but it is the truth.

If your application has more than one activity than you should consider using services for any asynchronous task such as HttpUtils2.

Well, I'm working on a framework that will keep it all in a single activity (although, to some extent, dynamically loading and unloading parts of the GUI).

For stuff like networking, a background thread will probably be used (especially since it will run in an environment where networking is unreliable at best).

 

[Erel]

For stuff like networking, a background thread will probably be used

You don't need to create a background thread if you are using B4A libraries. The libraries already take care of properly using an internal threads pool.

 

[Troberg]

You don't need to create a background thread if you are using B4A libraries. The libraries already take care of properly using an internal threads pool.

That was what I meant. It's a background thread, but I don't have to manage it.

If I can, I always avoid threading unless it's either:

* Securely encapsulated in a library/component.
* No synchronization issues, ie just a "fire and forget".

Everything else is too prone to errors that are extremely hard to diagnose.