Lesson ii – Android Components – Activity, Service, Content Providers, etc.
In Android App Development, Each Application, regardless of its purpose, entrusts its functionality to four types of Android components. These are
- Content Providers and
- Broadcast Receivers.
They exist so that our application can integrate perfectly into the Android ecosystem.
Before going into the explanation of each of them, it is useful to focus for a moment on two inspiring principles that, among others, are the basis of most of the design choices made by the creators of Android.
Being designed for embedded systems, historically endowed with few memory resources, Android has immediately had a thrifty spirit. We will see that, without losing the user-experience fluidity, Android is particularly good at destroying and recreating parts of the application in a way that is almost imperceptible to the user. Who will have to face this attitude will be the programmer, obviously.
Fortunately, this will not cost you great effort but only special care in taking certain precautions to be applied with the necessary awareness. It is worth emphasizing that when it comes to the scarcity of resources in Android, the most common objection revolves around the recent marketing of smartphones that can also count on 12 GB of RAM.
The system will, therefore, win the challenge of survival only if it knows how to adapt even to contexts that offer much more uncomfortable conditions than those that a new Samsung device can offer;
Each application is a user in its own right and lives in its own process in which a new instance of the virtual machine is allocated, in order to prevent the crash of an application from spreading instability to other running apps. This form of “isolation” is also reflected on the mass memory as each application has its own space in which to work and keep its data.
In this regard, any practice that leads an app to invade the space reserved for another is Absolutely not recommended. Despite this, our applications are not forced to live in the absence of communication between them, rather Android encourages a “healthy” dialogue between them by providing easy mechanisms for sharing content and functionality between system components.
This is known as Permission, this is known as the set of faculties of action that is granted to a new app installed. Android permission capabilities have been strengthened over the years, making the user of the device more and more aware of what an application actually can do in the system and of the exact moment in which this possibility is granted.
The time has, therefore, come to present the building blocks of an application more closely.
The Components of Android App
An Activity is a user interface. Each time you use an app, you generally interact with one or more “pages” through which data is consulted or inputs are entered. It is a single module related to an application’s functionality and is often directly related to a single user interface. For example, a wake-up application may have an activity that allows you to view a list of set alarms on one page and a second activity to set a new alarm on another page.
Obviously, the Understanding of Activity is the starting point of every Android programming, since it is the component with which the user has the most direct contact. The Activities as a whole constitute the flow into which the user goes to exploit the features made available.
This, therefore, requires not only the understanding of the interfaces in themselves but also a correct design of the navigation between them, offering the possibility to browse the contents and to trace them hierarchically in a coherent manner.
A Service plays a role, if you will, opposed to the Activity (although, at the level of class inheritance, they are related). In fact, it represents a job – generally long and continuous – that is carried out entirely in the background without the need for direct interaction with the user.
For example, an app that allows you to start audio that does not stop when closing its interface is probably based on a Service.
Their uses are of the most disparate and, depending on the case, the user might not even notice their start up but obtaining the benefits.
From a structural point of view, Android Services are of two types: started and bounded Services. The example of background music is part of the first case study: a Service is started when an app needs to carry out background activities, aimed at a specific purpose until they are completed. The second kind of service, the bounded ones, are activated only if another app needs to connect to them. It is a type of Service that allows the interaction between different processes and responds to a logic similar to that of the API in web services.
It should also be noted that this sector has also been revolutionized over the years, in particular with the birth of Job Schedulers that allow jobs in the background with economical use of the battery.
A Content Provider is born with the purpose of sharing data between applications. Its purpose recalls the security principle of the application mentioned earlier. These components allow you to share, within the system, contents stored in a database, on files or available through Internet access. These contents can be used by other applications without invading the memory space but establishing that “healthy” dialogue we mentioned.
Lesson 4 – Android Components – Android App Development
A Broadcast Receiver is an Android component that reacts to a sending of messages at the system level – precisely in broadcast – with which Android notifies the occurrence of a specific event. For example, the arrival of an SMS or a call or solicits the execution of actions. These components, as you can imagine, are particularly useful for the instantaneous management of certain special circumstances.
Broadcast Receivers do not use a graphical interface, although they can forward notifications to the status bar to alert the user of the event. Furthermore, their execution should be instantaneous by delegating to Service or JobScheduler any operations to be activated.
It is very important to remember that one component can activate another through specific system invocations. This intention is encoded with an Intent usable as a normal Java class but which implies a powerful Android communication tool. We will also use Intents from the next Lessons.
We are sorry that this lesson was not useful for you!
Let us improve this lesson!
Tell us how we can improve this lesson?