App Components

App components are the fundamental elements, the building blocks of an Android app.

There are four different types of app components and each of them is an entry point to the app through which either the system or the user can access it:

• Activities
• Services
• Broadcast Receivers
• Content providers

Each serves a different purpose and has a different lifecycle that determines how they are created and destroyed.

Activities

Activities are the way the app interacts with the user. It has one screen and an interface. One app might have many activities (although single activity architecture is widely used, this is something for another post). For example, a Recipe App can have one activity which is the app’s main screen where the user can search for recipes and filter them by type. A second activity would display a list of recipes based on the user search criteria and the third one would display the actual recipe after the user clicks on it.

The Activities are independent of the other, even though they work together to compose the app. So each of them can be initiated separately, given the correct means to trigger them. For example, a messaging app. You might have one activity that displays all your current active chats, one activity for the actual chat with one of your contacts, and from your Recipe app you can share a recipe directly with one of your contacts without having to open the messaging app main activity:

Activities can facilitate important interactions between the app and the system. For example, it keeps track of what it’s important for the user (what is on the screen) to make sure the system keeps running the necessary processes that are hosting the activity. It helps the system know about previous processes the user might return to and, based on this, prioritize which processes it kills first/last. It helps the app handle having its process killed so the user can return to activities with their previous state restored. It also provides a way for the app to create user flows, enabling sharing, for example, or when you open the camera app from within Instagram.

Services

Services are a general-purpose entry point responsible for keeping an app running in the background. For example, when you hit play on Spotify and then open another app, or when you open your Kindle app, it starts syncing your library and then you check Instagram.

There are two types of services: Started and Bound.

Playing music in the background or retrieving data from the server are two different types of Started services.

In the first one, the system keeps it running until completion. Until the music ends, or the playlist ends. The system prioritizes this type of service because the user is aware it is happening and would be really upset if it was interrupted. They expect the music to be playing until they say otherwise.

The other type of Started Service, like retrieving data from the server, on the other hand, can be interrupted if the system needs more RAM and this can be done without disrupting the user experience since they are not aware this service is actually running. When you open your Kindle app and it starts syncing your library, but if you open a different app and the system needs more RAM it can interrupt the sync process.

The second type of service is Bound Services, It runs because something else ( it can be an activity with the app, a different app or the system, etc) said it wants to make use of this service. This is basically the service providing an API to another process. In this case, the system is aware of the dependency (bound) between the services and will try to avoid killing one if the connected service is not supposed to be killed. In other words, if process A is important for the user and process B is bound to it, therefore, process B must also be important to the user.

Broadcast Receivers

A Broadcast Receiver is a component that allows the system to deliver events to the app outside the normal user flow letting the app respond to system-wide broadcast announcements. This can be also done to apps that are not currently running. For example, you can trigger the system to schedule an alarm or a calendar reminder even if your Clock or Calendar apps are not running. A lot of broadcasts are originated from the system (low battery, picture captured, etc) but apps can originate them too. One example is the broadcast that data has been downloaded.

While broadcast receivers don’t present a user interface, many of them can create a status bar notification to let the user know about the broadcast.

Content Providers

Content providers manage a shared set of app data that you can store on any persistent storage location. The data can then be accessed by other parts of the app (although this is not a common practice anymore) or by another app on request. Through it, other apps can request or modify data, depending on what the content provider allows them to do. For example, the system provides a content provider that handles the user’s contact information. So, any app with the right permissions can request the content provider, such as ContactsContract.Data, to read and write information about a particular person.