In this series, we are learning the essential features of Android development that you need to know to start building apps. So far, we've looked at the structure and typical elements in an Android app, including user interface elements and data storage. You can use what we've covered already to start creating your own apps. But before you do, we will run through some common Android components in this tutorial, before having a quick look at the SDK samples in the next tutorial.
Introduction
There are four main Android app components: activities, services, content providers, and broadcast receivers. Whenever you create or use any of them, you must include elements in the project manifest. In this post, I will briefly introduce you to all these components, including information about their role in an app and so on. I'll also mention a couple of resources your apps are most likely to use, including fragments and the action bar.
1. Activities
Activities are an important component of Android apps because they give users an interface to interact with your app. An activity basically represents a single screen of your app. If we take the Contacts app as an example, then the screen that displays the list of all contacts is one activity, and the screen that appears when we click on a contact to see more details is another activity.
What makes activities amazing is that even though an app can consist of multiple activities, like the Contacts app in our example, all those activities are independent. This means that the different activities of an app can also be started by some other app installed on the device. For example, if anyone sends you a contact on messaging apps such as WhatsApp, then WhatsApp will be able to start an activity of the Contacts app to save the contact if the Contacts app allows such behavior. This allows WhatsApp to seamlessly integrate that functionality without writing any implementation code.
Activities are implemented as a subclass of the Activity class when creating our own Android apps.
2. Services
A service in Android is a background process. Services are typically used for processes that are ongoing or that take a significant amount of time. A service doesn't have a user interface, so it's often combined with other components such as activities. A typical example is an app in which an activity starts a service running on user interaction, with the service perhaps uploading data to a web resource. The user can continue to interact with the activity while the service runs because it executes in the background.
If you want to carry out background processing such as fetching Internet data, you don't necessarily need to implement a service class. Depending on the needs of your application, it may be more appropriate to use the java.util.concurrent package or Kotlin coroutines inside your activity.
Earlier, this was done using the AsyncTask class, but that has been deprecated due to problems such as missed callbacks and crashes that occurred on configuration changes such as screen orientation.
To add a service component to the manifest, use the following syntax with the element placed inside the application element:
1 | <serviceandroid:name=".ServiceClassName"/> |
The service element can contain the intent-filter element and the meta-data element within itself. There are a lot of other attributes that you can add to the service element. Keep in mind that any service that you implement in your app has to be present in the manifest file as well. Otherwise, the service will be invisible to the system and will never run.
There are three kinds of services that you should know:
- Foreground services must display a notification while they are running. These services are used to perform tasks that are noticeable to users, such as playing audio or saving an edited video.
- Background services do something that isn't noticeable to users, such as storage optimization. Keep in mind that Android places some restrictions on background services in order to optimize performance.
- Bound services are where an application component binds to the service by calling the
bindService()method. Bound services provide an interface that allows them to interact with app components, and these services only run as long as they are bound to an application component.
You can create a service class in Android Studio using the same process you would for an activity, choosing service as the superclass. Services are different from the activity components that we've looked at previously, in a number of important ways. If you start a service that runs from an activity and the user navigates away from the activity to another app, the service will continue to run. A service, therefore, has a different lifecycle to the one we explored for activities. You need to bear this in mind to ensure your apps are efficient.
Some other apps can bind to services, requesting and receiving data from them. If a bound service is running, it stops when all of the components that are bound to it stop. Although a service is separate from the app user interface, a service started in an activity will run in the same thread as the activity. However, if your service is going to use a significant amount of processing resources, you can create a separate thread to run it in. For more on services, see the Android Developer Guide.
3. Content Providers
A content provider is a component for managing a data set. This data set can be private to your application or can be shared, with other apps able to query and modify the data. If you create a content provider to manage data for your own app, your UI components such as activities will use the content provider, typically through the content resolver class, to interact with the data. When used by other apps, the content provider manages access to the data through standard methods to interact with structured data sets such as databases.
If you are at all familiar with relational databases, you intuitively understand the methods used to access data with a content provider. The content provider presents data in a set of tables with rows and columns, and each column within a row (or record) includes a single data value. Handling data returned through a content provider is therefore similar to handling database query results.
Although you may of course create a content provider app at some point, in your initial apps you are far more likely to access one created by another developer or the Android system itself, such as the device calendar or contacts. Content providers can define permissions that client apps are required to have in order to use them. To use a content provider in your app, you need to add the relevant permissions for it in your manifest.
If you simply need a structured data source to use in your app, you typically don't need to create a content provider. You can create an SQLite database which is private to your app, without the need to use the content provider classes at all. The only occasions in which you need to create a content provider are when you want other apps to access your structured data, where you want to copy structured data from your apps to other apps, or where you want to make use of the search framework.
The search framework in Android refers to all the tools that the OS provides you to help implement search functionality in your website. Besides implementing custom search suggestions in your application, you also need content providers for exposing your application data to different widgets and for the transfer of complex data between applications.
Android also has its own set of built-in content providers that are accessible to almost every installed Android application. These built-in content providers allow easy access to data such as the contacts, calendar, and media files on the device.
See the Content Providers section in the Android Developer Guide for more information.
4. Broadcast Receivers
The Android system makes various types of broadcasts an app can respond to. You can also develop apps to make these broadcasts, but this is far less likely than listening for existing broadcasts, at least for your first apps. System announcements include information about the device's hardware, such as the battery level, the screen shutting off, the charger being plugged into an outlet, etc.
To receive broadcast announcements on Android, your apps can use a broadcast receiver. A typical example of this is a battery level widget in which you want to update the display when the battery level changes. In this case, you could use a service class in conjunction with a broadcast receiver to let your app keep listening for announcements in the background.
The Android system models broadcast announcements as intents, which can be used to start an activity. An intent is an action that the system performs, such as launching an activity or making an announcement. To use a broadcast receiver, your apps must declare it in the manifest, along with an optional intent filter, indicating the actions you want to receive:
1 | <receiverandroid:name=".YourReceiver"> |
2 | <intent-filter> |
3 | <actionandroid:name="android.intent.action.BATTERY_LOW"/> |
4 | </intent-filter> |
5 | </receiver> |
This applies to a broadcast receiver in which your app can receive the battery low intent.
There are two ways for apps to receive broadcasts. The first one is the manifest-declared receivers that we just discussed above. In this case, the broadcast receiver acts as an entry point into your app. Basically, the system will be able to start the app and then deliver the broadcast if the app isn't running already.
Note that you can't receive all system announcements by declaring their actions in the manifest in this way. In some cases, you need to register to receive them in Java or Kotlin. One such example is the BATTERY_CHANGED action. It requires an explicit registration using the Context.registerReceiver() method. You also need to register and unregister any such broadcast receivers properly to prevent any context leaking or multiple registrations. See the broadcast receiver class for more on this type of app.
Broadcast receivers are implemented as a subclass of the BroadcastReceiver class in Android apps. These broadcasts are then delivered as Intent objects by using the sendBroadcast() method.
5. Other Classes
As we've seen, Android components are designed to provide interaction between apps. Just as broadcast announcements are available to any app on the system, Android provides certain actions you can use to carry out common tasks in your apps, such as dialing a number. Similarly, you can often use functionality provided by other developers to carry out processing, saving on the amount of code you must implement yourself and letting you focus on the unique aspects of your apps. When you launch one intent from another, you can set it up to return a result to the launching activity, even if the intent that is launched is not part of your app. This lets your app continue to function after the requested action is completed.
Other Android components you should be aware of include fragments and the action bar. Let me briefly run through them.
Fragments
Rather than simply using an activity and a layout to define the whole user interface for each app screen, it is often more efficient to use fragments. With fragments, you can divide the parts of your user interface into logical sections and even reuse those sections on more than one screen of your app. This saves you from the task of implementing the same visual/interactive elements more than once, and it gives you a single point of change for these sections. Fragments are modeled as part of an activity, so a fragment is tied to the lifecycle of the activity it is in. See the fragment section of the Developer Guide for more.
Action Bar
The action bar, also known as the app bar, is another key user interface element you may find useful. The action bar gives your app a user interface component that is consistent across the Android system, which makes it an intuitive element for the platform's users. Typical items displayed in the action bar include an indicator of the user's location within your app if appropriate and shortcuts to common actions, including navigation between the parts of the app.
To use the action bar in an activity, make sure that your class extends the AppCompatActivity class, and apply an AppCompat theme to the activity in the manifest. See the Developer Guide for more information about the action bar.
Conclusion
Which Android classes and components you use naturally depends on what your app does. However, the above components give you an overview of which classes and components you can choose from. It is often difficult to decide which component or class to use for a particular feature or function, so make sure you understand the purpose of each one before you make a decision. In the next few tutorials, we will look at the Android samples and the app publishing process.
This post has been updated with contributions from Nitish Kumar. Nitish is a web developer with experience in creating eCommerce websites on various platforms. He spends his free time working on personal projects that make his everyday life easier or taking long evening walks with friends.