YouTip

# Android Application Components Application components are the basic building blocks of an Android application. These components are loosely coupled by the application manifest file. AndroidManifest.xml describes each component of the application and how they interact. The following are the four main components that can be used in an Android application. | Component | Description | | --- | --- | | Activities | Describe UI and handle user interaction with the device screen. | | Services | Handle background operations associated with the application. | | Broadcast Receivers | Handle communication between the Android operating system and applications. | | Content Providers | Handle data and database management issues. | ## Activities An activity represents a single screen with a user interface. For example, an email application might have one activity to show a list of new emails, another activity to compose an email, and another activity to read an email. When an application has more than one activity, one of them should be marked as the activity that is shown when the application is launched. An activity is a subclass of the **Activity** class, as shown below: public class MainActivity extends Activity {} ## Services A service is a component that runs in the background to perform long-running operations. For example, a service might be playing 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. A service is a subclass of the **Service** class, as shown below: public class MyService extends Service {} ## Broadcast Receivers Broadcast receivers simply respond to broadcast messages from other applications or the system. For example, applications can initiate broadcasts to let other applications know that some data has been downloaded to the device and is available for them to use. Thus, broadcast receivers intercept these communications and take appropriate action. A broadcast receiver is a subclass of the **BroadcastReceiver** class and each message is broadcast in the form of an **Intent** object. public class MyReceiver extends BroadcastReceiver {} ## Content Providers The content provider component provides data from one application to another on request. These requests are handled by the methods of the **ContentResolver** class. The data may be stored in the file system, the database, or somewhere else entirely. A content provider is a subclass of the **ContentProvider** class and implements a standard set of APIs to allow other applications to perform transactions. public class MyContentProvider extends ContentProvider {} We will cover the application components in separate chapters with details of their tags. ## Auxiliary Components There are additional components that are used for the construction of the above-mentioned entities, their logic, and their interconnections. These components are: | Component | Description | | --- | --- | | Fragments | Represents a behavior or a portion of user interface in an activity. | | Views | UI elements that are drawn on-screen, including buttons, lists, etc. | | Layouts | A hierarchy of View objects that control screen format and appearance. | | Intents | Messages that connect components. | | Resources | External elements, such as string resources, constant resources, and drawable resources. | | Manifest | The configuration file for the application. | ## 1 Note Write Note 1. #0 ive***vip.qq.com (https://baike.baidu.com/item/%E6%9D%BE%E8%80%A6%E5%90%88/10317075?fr=aladdin) [](#)221 A loosely coupled system is typically a message-based system where the client and remote service do not know how each other is implemented. Communication between the client and service is governed by the architecture of the messages. As long as the messages conform to the agreed-upon architecture, the implementation of the client or service can be changed as needed without worrying about breaking the other. Loose coupling communication mechanisms offer many advantages that tight coupling mechanisms do not, and they help reduce the dependency between the client and the remote service. However, tight coupling can often provide performance benefits and facilitate a more integrated connection between the client and the service. There is a growing interest in comparing the loosely coupled and tightly coupled approaches to application interaction. The main technical reason for this trend is that with standards like UDDI (Universal Description, Discovery and Integration), web services can dynamically discover and bind to other services. The main business reason is that enterprises increasingly need to be flexible in handling changes in business processes and interactions with partners. The advantage of a loosely coupled system is that updating one module does not cause changes in other modules. Traditionally, business processes were developed within the enterprise scope, or even within different business units of an enterprise. These activities are managed with the help of detailed, real-time information. Processes that span multiple business units or the entire enterprise must be more flexible to accommodate a wide variety of requirements. In such cases, there may be more uncertainty: participants and their roles change constantly, and the types of interactions required also change. [](javascript:;) ive***vip.qq.com (https://baike.baidu.com/item/%E6%9D%BE%E8%80%A6%E5%90%88/10317075?fr=aladdin) 8 years ago (2018-06-19) ### Click to Share Note