Skip to main content

Service in Android


Service in Android

A Service is an application component that can perform long-running operations in the background, and it doesn't provide a user interface. Another application component can start a service, and it continues to run in the background even if the user switches to another application. Additionally, a component can bind to a service to interact with it and even perform inter process communication (IPC). For example, a service can handle network transactions, play music, perform file I/O, or interact with a content provider, all from the background.
These are the three different types of services:
Foreground
  A foreground service performs some operation that is noticeable to the user. For example, an audio app would use a foreground service to play an audio track. Foreground services must display a Notification. Foreground services continue running even when the user isn't interacting with the app.  
Background
  A background service performs an operation that isn't directly noticed by the user. For example, if an app used a service to compact its storage, that would usually be a background service.  
Bound 
  A service is bound when an application component binds to it by calling bindService(). A bound service offers a client-server interface that allows components to interact with the service, send requests, receive results, and even do so across processes with inter process communication (IPC). A bound service runs only as long as another application component is bound to it. Multiple components can bind to the service at once, but when all of them unbind, the service is destroyed.

Although this documentation generally discusses started and bound services separately, your service can work both ways—it can be started (to run indefinitely) and also allow binding. It's simply a matter of whether you implement a couple of callback methods: onStartCommand() to allow components to start it and onBind() to allow binding.

Service Life Cycle
To create a service, you must create a subclass of Service or use one of its existing subclasses. In your implementation, you must override some callback methods that handle key aspects of the service lifecycle and provide a mechanism that allows the components to bind to the service, if appropriate. These are the most important callback methods that you should override:
 

The system invokes this method by calling startService() when another component (such as an activity) requests that the service be started. When this method executes, the service is started and can run in the background indefinitely. If you implement this, it is your responsibility to stop the service when its work is complete by calling stopSelf() or stopService(). If you only want to provide binding, you don't need to implement this method. 
The system invokes this method by calling bindService() when another component wants to bind with the service (such as to perform RPC). In your implementation of this method, you must provide an interface that clients use to communicate with the service 
The system invokes this method to perform one-time setup procedures when the service is initially created (before it calls either onStartCommand() or onBind()). If the service is already running, this method is not called. 
The system invokes this method when the service is no longer used and is being destroyed. Your service should implement this to clean up any resources such as threads, registered listeners, or receivers. This is the last call that the service receives. 
Note:
I) If a component starts the service by calling startService() (which results in a call to onStartCommand()), the service continues to run until it stops itself with stopSelf() or another component stops it by calling stopService().
 II) If a component calls bindService() to create the service and onStartCommand() is not called, the service runs only as long as the component is bound to it. After the service is unbound from all of its clients, the system destroys it.



Comments

Popular posts from this blog

#3: Collapsing Toolbar

Collapsing Toolbar         CollapsingToolbarLayout is a ViewGroup that provides many of the visual characteristics and interactions for collapsing toolbars specified in the material guidelines. To create the collapsing toolbar, CollapsingToolbarLayout integrates with AppBarLayout, CoordinatorLayout, Toolbar, and a scrollable content view, such as RecyclerView. How to work with Collapsing Toolbar:     To add a collapsing toolbar to your layout, place the CollapsingToolbarLayout inside an AppBarLayout. Then, add a Toolbar and any other views as a child to the CollapsingToolbarLayout. Make sure that the entire view structure is inside a CoordinatorLayout to take advantage of CollapsingToolbarLayout’s scrolling and features. Sample Code: <android.support.design.widget.CoordinatorLayout     android:layout_width="match_parent"     android:layout_height="match_parent">     <!-- Scrollable view here -->   <com.google.android.mat

Activity Life Cycle States

      Activity Life Cycle Example  https://drive.google.com/file/d/1ald91YAfWEit05irie7NolPm4h1OFpIy/view?usp=sharing Activity Life Cycle         As a user navigates through, out of, and back to your app, the Activity instances in your app transition through different states in their lifecycle. The Activity class provides a number of callbacks that allow the activity to know that a state has changed: that the system is creating, stopping, or resuming an activity, or destroying the process in which the activity resides.       Within the lifecycle callback methods, you can declare how your activity behaves when the user leaves and re-enters the activity. For example, if you're building a streaming video player, you might pause the video and terminate the network connection when the user switches to another app. When the user returns, you can reconnect to the network and allow the user to resume the video from the same spot. In other words, each callback allows you