• Various Components of an Android Application.

    components of an android application

    Application components are the essential building blocks of an android application.
    These loosely coupled components are bound by the application manifest file which contains description of each component and how they interact. Each component is an entry point through which the system or a user can enter your application. Some components depends on others. There are 4 different types of application components:-
    • Activities
    • Services
    • Broadcast Receiver
    • Content Provider
    Each type serves a distinct purpose and has a distinct life cycle that defines how the component is created and destroyed. All the four types of app components are briefly discussed below:

    Activities :

    An activity is the entry point for interacting with the user. It represents a single screen with a user interface. For example: an email application might have one activity that shows a list of new emails, another activity to compose an email and another activity for reading emails.
    Although the activities work together to form a cohesive user experience in the email application, each one is independent of the others. As such a different application can start any one these activities if the email application allows it. For example: A camera application can start the activity in the email application that composes new mail to allow the user to share a feature.

    An activity facilitates the following key interactions between systems and application:
    i. Keeping Track of what the user currently cares about. i.e. what is on the screen to ensure that the system keeps running the process i.e. hosting the activities.

    ii. Knowing that previously used processes contain things the user may return to (Stopped Activities).

    iii. Helping the application handle having its process killed so the user can return to activities with their previous state restored.

    iv. Providing a way for apps to implement user flows between each other and for the system to coordinate these flows. We implement an activity as a sub class of the Activity:
    Public class MainActivity extends activity {}

    Services :

    A service is a general purpose entry point for keeping an application running in the background for all kinds of reasons. It is a component that runs in the background to perform long running operations or to perform work for remote processes. A service doesn’t provide a user interface. 
    For example: A service might play music in the background while the user is in a different application or it might fetch data over the network without blocking user interaction with an activity. Another component such as an activity can start the service and let it run or bind to it in order to interact with it. There are actually two very distinct semantic services tell the system about how to manage an application.

    i. Started Services tell the system to keep them running until their work is completed. This service also represents two different types of services.
                  a> Music Playback is something the user is directly aware of so the application tells the system this by saying it wants to be foreground with a notification to tell the user about it. In this case system knows that it should try really hard to keep that services’ process.

                  b> A regular background service isn’t something the user is directly aware as running. So, the system has more freedom in managing its process. It may allow it to be killed and then restarting the service sometime later, if it needs RAM for things that are of more immediate concern to the user.

    ii. Bound Services run because some other application or the system has said that it wants to make use of the service. This is basically the service providing an API to another process. For example: Live Wallpapers, notification listeners. A service is implemented as a subclass of Service.

    Public class MyService extends Service{}

    Broadcast Receiver :

    Broadcast Receiver is a component that enables the system to deliver events to the application outside of a regular user flow. Allowing the application to respond to a system wide Broadcast announcements. Because Broadcast Receivers are another well-defined entry into the app the system can deliver broadcasts even the two applications that aren’t running. Many broadcasts originate from the system. For example: A Broadcast announcing that the screen has turned off, the battery is low or a picture was captured. Apps can also initiate broadcasts. 
    For example: to let other apps know that some data has been downloaded to the device and is available for them to use.
    Although Broadcast Receivers don’t display a user interface, they may create a status bar notification to alert the user when a broadcast event occurs. A broadcast receiver is implemented as a sub class or Broadcast Receiver and each Broadcast is delivered as an intent object.

    Public class MyReceiver extends BroadcastReceiver{
     public void onReceive (context, intent){}
     }

    Content Provider :

    A content Provider manages a shared set of app data that we can store in the file system. In a SQLite database, on the web or on any other persistent storage location that our app can access. Through the content provider, other apps can query or modify if the content provider allows it.
     For example: the Android system provides a content provider that manages the user’s contact information. As such any app with the proper permissions can query the content provider to read and write information about a particular person.
    A content provider is implemented as a sub class of content provider and must implement a standard set of APIs that enable other apps to perform transactions.

    public class MyContentProvider extends ContentProvider{
     public void onCreate(){}
     }
  • You might also like

    No comments:

    Post a Comment

search topics

NEWSLETTER

Get All The Latest Updates Delivered Straight Into Your Inbox For Free!