English subtitles

← App Lifecycle and Services - Developing Android Apps

Get Embed Code
10 Languages

Showing Revision 18 created 05/25/2016 by Udacity Robot.

  1. Back in lesson four we learned
    that the Android runtime
  2. will kill apps with
    no visible activities
  3. in order to free resources
    needed by the foreground app.
  4. But what if your app has tasks
    that need to continue
  5. when the activity isn't visible?
  6. Things like downloading files,
    uploading photos, or playing music.
  7. Well, there's an application
    component for that.
  8. Services.
  9. We've already introduced
    activities, content providers,
  10. broadcast receivers and intents.
  11. Services are the final piece
    to the Android app component puzzle.
  12. You start services
    much like you do activities,
  13. by passing in an intent
    to a startService call.
  14. And you can stop
    services the same way.
  15. By calling stopService
    and passing in the name
  16. of the service
    you want to stop.
  17. Unlike activities, services have
    no user interface
  18. and they run at a higher priority
    than background activities.
  19. This means that an app
    with a running service,
  20. is less likely to be killed
    by the runtime
  21. in order to free resources
    for the foreground activities.
  22. In fact, by default, the system
    will attempt to restart services
  23. that are terminated before
    they are stopped from within the app.
  24. This is reflected in
    this simplified lifecycle.
  25. Compared to activities,
    services are designed
  26. to execute longer running tasks
    that shouldn't be interrupted.
  27. Typically, you'll only need to
    override the onStartCommad handler,
  28. which is where you begin
    the background task
  29. you wish to execute.
  30. But notice that there are no handlers
    for monitoring changes in state,
  31. to reflect the app moving
    to the background.
  32. This is because the
    running service itself,
  33. sends a signal to the framework,
  34. that the containing app should
    be considered higher priority
  35. than other apps in the background
    that don't have running services.
  36. In some cases your service
    may performing a task,
  37. that while not having UI,
    can't be interrupted
  38. without interfering
    with the user experience.
  39. For example, playing music
    or helping with in car navigation.
  40. In these cases you can
    indicate that your server
  41. should be considered to be
    running in the foreground
  42. by calling startForeground.
  43. You'll notice that this call
    takes in a notification.
  44. This will be displayed,
    and can't be dismissed
  45. until the service has stopped
    or you call stopForeground.
  46. You'll learn more about notifications
    a little later, with Dan.
  47. But for now, note that a foreground
    service runs at the same priority
  48. as a foreground activity.
  49. Making it nearly impossible
    for the runtime to kill
  50. in order to free resources.
  51. Now you may be thinking to yourself,
    I could save a lot of trouble
  52. dealing with lifecycles,
    just by creating long running
  53. or even foreground services.
  54. Well, I grew up along
    the coast in Australia,
  55. so I learned young that
    swimming against the current
  56. is exhausting and ultimately futile.
  57. In this case, that means
    making it more difficult
  58. for the system to manage resources,
  59. ultimately leading to
    a worse user experience.
  60. Swim with the current.
  61. Use foreground services
    only when and for as long as
  62. absolutely necessary.
  63. And stop all service
    as as quickly as possible.
  64. It's also important to note
    that like activities and receivers,
  65. services run on the main thread.
  66. So you'll need to use
    a background thread or think task
  67. to execute the long running tasks
    you wish to do within your service.
  68. To make life easier, you can
    use the intent service class.
  69. Which implements the most common
    best practice pattern, for using intents,
  70. which are executed within a service.
  71. It creates a queue of incoming intents,
    passed in when start service is called.
  72. These are then processed sequentially
    on a background thread,
  73. within the onHandleIntent handler,
    within your intent service implementation.
  74. When the queue is empty,
    the service self terminates
  75. until a new intent is received,
    and the process begins again,
  76. Services are a powerful tool
    and it's important to understand
  77. how you can use them,
  78. but in practice there's often
    a framework alternative
  79. to rolling your own
    service implementation.
  80. Whether that be an intent service
    for executing background tasks
  81. or the sync adapter which you'll
    learn about later in this lesson.
  82. Perfect for performing background
    data synchronization.