Android Question Benefits of services

Discussion in 'Android Questions' started by Troberg, Feb 20, 2015.

  1. Troberg

    Troberg Well-Known Member Licensed User

    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?
     
  2. sorex

    sorex Expert Licensed User

    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.
     
    thedesolatesoul likes this.
  3. Troberg

    Troberg Well-Known Member Licensed User

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

    thedesolatesoul Expert Licensed User

    If your app never pauses then you dont need a service.
     
    NJDude likes this.
  5. Erel

    Erel Administrator Staff Member Licensed User

    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.
     
  6. udg

    udg Expert Licensed User

    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.
     
  7. Erel

    Erel Administrator Staff Member Licensed User

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

    udg Expert Licensed User

    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
     
  9. Erel

    Erel Administrator Staff Member Licensed User

    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.
     
  10. udg

    udg Expert Licensed User

    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?

    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.
     
    Last edited: Feb 22, 2015
  11. Troberg

    Troberg Well-Known Member Licensed User

    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).
     
  12. Erel

    Erel Administrator Staff Member Licensed User

    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.
     
  13. Troberg

    Troberg Well-Known Member Licensed User

    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.
     
Loading...
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice