My Android Chapter III: Introduction to Android Components

The small part extracts the Android document to introduce the basic contents of Android four components, feel the content of the document is written in a very detailed, so the small part of it written to the blog

Android is developed using the Java language. The Android SDK tool compiles code-as well as arbitrary data and is packaged into an Android package with related resources, which is a .apk compressed file with the suffix. .apkall the code in a file is a program. this. apk file is used to install this program on Android devices.

Once the installation is successful, the Android program has its own running sandbox (a sandbox is a practice of running applications in a restricted security environment, which restricts the code access granted to the application.) ）:

• The Android operating system is a multi-user Linux system, and each of these applications is a standalone user.
• By default, each application is assigned a unique Linux user ID (this ID is only used by the system and is unknown to the application). The system sets permissions for all files of an application, so only the user ID assigned to the application can access them.
• Each process has its host virtual machine (VM), so the code for one application runs independently of other applications.
• By default, each application runs in its own Linux process. Android will start this process when any component of an application needs to be called. The process is then closed when no component is called or when the system needs to reclaim memory for other applications.

In this way, the Android system implements the principle of least privilege . That is, every application, by default, can only invoke the work components it needs. This creates a very secure environment in which an application cannot access parts of the system that are not granted its permissions.

Nonetheless, there are many ways to share data with an application and other applications, or to have an application invoke system services:

• It is possible to assign the same Linux user ID to two applications so that they can access each other's files. To conserve system resources, applications that have the same user ID can also be run on the same Linux process and share VMS (they must be signed with the same certificate).
• Applications can access device data by requesting permissions, such as contacts, SMS messages, pluggable storage (SD cards), cameras, Bluetooth, and so on. All application permissions must be granted by the user at the time of installation.

The above summarizes the way an Android program exists in the system. Next you will be introduced:

• Assemble those core framework components of your application.
• A configuration file that declares components and requests device attributes for your program.
• Code-delimited resources that optimize your program's ability to run flawlessly in different device configurations.

Application components

Components are a critical building block for an Android program. Each component is a different way of getting your system into your application. But not all components are the real portals of the user's entry into the program, some of which depend on other components, but each component exists in its own unique form and plays a special role; each component is a unique module that helps you implement the various behaviors of the program.

There are four different kinds of application components. Each component has its sole purpose and has a unique life cycle, which defines how attachments are created and destroyed.

Here are four types of application components:

Activity

An activity provides a separate interface for a user interaction. For example, a mail program might have an activity that presents a list of new messages. Another activity is used to edit the message, and one is used to read the message. While these activity combinations form a cohesive user experience, each one is relatively independent. Similarly, other programs can initiate these activity (if this is allowed by the mail program). For example, a camera program can start this mail program's edit mail activity if the user wants to share a photo.

An activity is Activity implemented as a subclass. You can also learn more by activities the developer Guide.

Service

a service is a component that runs in the background. It is used to perform time-consuming operations or remote processes. A service does not provide an interface for user interaction. For example, when a user is using another program, a service may be playing music or fetching data over the network, which does not block the user's interaction with the activity. Other components, such as an activity, can start a service and let it run or bind to it, and can interact with it after binding.

A service Service is implemented as a subclass of a class. You can learn more through the Services Developer Guide.

Content Provider

A content provider is responsible for managing the data sharing set of the application. You can store data through file systems, SQLite databases, websites, or other persistent storage locations that your application can access. With content provider, other applications can query or even modify your data (if the content provider allows them to do so). For example, the Android system provides a content provider to manage contact information. Similarly, any program that has the appropriate permissions can query the content provider (for example ContactsContract.Data ) to read and write information about someone.

The Content provider is also useful when reading and writing programs ' private data. For example, the note Pad sample program uses a content provider to save notes.

A content provider is ContentProvider implemented as a subclass. And some standard set of APIs must be implemented so that other applications can perform transactions. For more information, please refer to the Content Providers Developer's Guide.

Broadcast receiver

broadcast receiver is a component that responds to system-wide broadcasts. Many broadcasts emanate from the system itself. -for example, the notification screen has been turned off, the battery is low, and the photo is being photographed. Applications can also initiate broadcasts. -for example, notifying other programs that some data has been downloaded to the device and available for use. Although the broadcast does not provide a user interface, they can also create a status bar notification to alert the user that a broadcast event has occurred. Even more so, a broadcast is just a "gateway" to other components and tries to do a little bit of work. For example, it might initiate a service and perform the work related to this broadcast event through the service.

Broadcast receiver is a BroadcastReceiver subclass implementation, and each broadcast is passed through an Intent object. For more information, please read the BroadcastReceiver class.

A unique aspect of the Android system design is that any program can launch components from other programs. For example, if you want the user to use the device camera to capture a photo and have another program do it, then your program will be able to invoke it instead of developing a photo activity yourself. You do not need to embed code from the camera program or even link code. Instead, you can simply start the activity of taking pictures in the camera program. When the photo is completed, the photo will be returned to your program for your use. From the user's point of view, it's like a camera is part of your program.

When the system launches a component, it actually initiates the process of the program (if the process has not been started) and instantiates the classes required by the component. For example, if your program initiates activity in the camera program to take a photo, the activity is actually running in the process of the camera program, not your own process. Therefore, unlike other programs in the system, the Android program is not a single entry (for example, it does not have a Main method).

Because the system runs the program in a separate process and uses file permissions to restrict access to other programs, your program cannot activate the component directly from other programs. Still, the Android system can do it! To activate a component of another program, you must send a message to the system, which needs to specify your intent to start a specified component. The system will then activate the component for you.

Activating components

The Three-fourths component types-activitie, service, and broadcast receiver-are activated by an asynchronous message called Intent . Intent binds separate components at run time (you can think of them as messages that request actions from other components), whether they belong to you or any other program.

A intent is created using an Intent object that activates a specified or specified type of component. -A intent can be displayed or implicit, respectively.

For activity and service, a intent defines the action that will be performed. (for example, what to view or send) and you can specify the data URL that the action needs to perform (the other data that the component needs to know to boot). For example, a intent may send a request for an activity to display a picture or open a Web page. In some cases, you can start an activity to receive a result, and this activity also returns the result by one Intent . (For example, you can send a intent to let the user get a personal contact and let the result return to you-the returned intent contains a URI that points to the contact you choose).

For broadcast receiver, intent simply defines the announcements that need to be broadcast (for example, a broadcast with a specified device's low battery level contains only a known action string: "Low power").

Another component type, content provider, is not activated with intent. Relatively, it is activated by a ContentResolver request that initiates a point to it. This content resolver master the direct transaction of all content provider, so the component that executes the transaction with this provider does not need to execute directly but to invoke the ContentResolver method of this object. It places an abstraction layer between the content provider and the component request information (for security).

There are different ways to activate various types of components:

• You can start an activity (or let it do some new work) by passing a Intent given startActivity() or startActivityForResult() (when you want an activity to return a result for you).
• You can start a service (or send a new instruction to a running service) by passing a Intent given startService() . Or you can bind a service by passing a Intent given bindService() .
• You can initialize a broadcast by passing one Intent to some method like sendBroadcast() , sendOrderedBroadcast() or sendStickyBroadcast() .
• You can have content provider perform a query operation by invoking ContentResolver the query() method.

For more information about intent, check out the intent and intent Filters documentation. More information about activating specific components is contained in the following documents: activities, Services, BroadcastReceiver and Content Providers.

Configuration file

Before the Android system can start a program component, the system must AndroidManifest.xml know whether the component exists by reading the program's file (the "Configuration" file). Your program must declare all of its components in this file. This file must be placed in the root directory of the program project.

In addition to declaring program components, this configuration file does some other work, such as:

• Determine which user rights The program requires, such as network access or reading the user's contacts.
• Declare the minimum API level required by the program to refer to which APIs are used by the program.
• Declares the hardware and software features that the program uses or requires, such as cameras, Bluetooth services, or multi-touch screens.
• The program requires a linked API class library (other than the Android framework API) such as the Google map class library.
• Other

declaring components

The primary task of a configuration file is to inform the system which components are used by the application. For example, a configuration file can declare an activity as follows:

<?XML version= "1.0" encoding= "Utf-8"?><Manifest... >    <ApplicationAndroid:icon= "@drawable/app_icon.png" ... >        <ActivityAndroid:name= "Com.example.project.ExampleActivity"Android:label= "@string/example_label" ... >        </Activity>        ...    </Application></Manifest>

In the <application> element, the android:icon attribute specifies an icon resource for the application.

In the <activity> element, the android:name attribute specifies the Activity complete correct class name for the subclass, and the android:label property specifies a string that displays the user's visible label for the activity.

You have to declare all the components like this:

• <activity>Elements of activity
• <service>Elements of the service
• <receiver>Elements of the broadcast receiver
• <provider>Elements of the content provider

Activitie, service, and content provider that you include in your program but are not declared in the configuration file are not recognized by the system and therefore cannot be run. However, broadcast receiver can be either declared in the configuration file or dynamically created (as an object) in the code BroadcastReceiver and registered in the registerReceiver() system by invocation.

To learn more about how to build your program's configuration file, consult the Androidmanifest.xml documentation.

Declaring the purpose of a component

As discussed in the previous article activating the component, you can use one Intent to start a activitie, service, and broadcast receiver. You can explicitly declare a target component in intent (using the component's class name). But the best part of intent is its action concept, which, using action, you can simply describe the action you want to perform (and you can specify what data you want to put on the action) and allow the system to find the component that can perform the action on the device and start it. If more than one component can perform this action, it is up to the user to decide which to execute.

The way the system recognizes the components that can respond to intent is to compare the intent in the configuration file of the received intent and other programs of the device filters

When you declare a component in a program's configuration file, you can selectively include the intent filter to declare the functionality of the component so that it responds to intent initiated by other programs. You can <intent-filter> declare a intent filter for your component by adding a child element that acts as your component.

For example, a mail program that contains an edit new mail page might want to declare a intent filter in the configuration file as a portal to respond to "send" intent (in order to send mail). One activity in your program is to create a intent that contains the "Send" action ( ACTION_SEND ) so that the system startActivity() compares the "send" page of the mail program and launches it when you call the intent.

More about creating intent filters, view the intents and intent filter documentation.

Declaring a program's configuration requirements S

Android devices are diverse, and not all of them offer the same features and capabilities. To avoid installing devices that do not meet the requirements of your program, it is important that you clearly declare the device and software requirements in the configuration file to define which devices are supported by your program. These statements are mostly reference information and the system does not read them. But additional programs such as Google Play will filter the user's search for the app.

For example, if your program requires a camera and you use the API (API level 7) described in Andriod 2.1, you should declare these requirements in the configuration file. That way, you won't be able to install your app from Google Play without a camera and Android version less than 2.1.

Nonetheless, you can also declare your program to use the camera, but it is not hard to ask . In this case, your program must perform a checksum at run time to determine if the device has a camera function and disable all features that use the camera on devices that do not have a camera.

Here are some of the device features you need to consider when designing and developing your application:

Device size and pixel density

to classify devices according to screen type, Android defines two device features: Screen size (physical size of the screen) and screen pixel density (the physical density of the screen pixels, or the number of dots per inch called dpi-). To simplify the different types of screen configurations, the Android system summarizes them as selectable groupings so that they can be easily adapted.

Screen sizes include: small, normal, large, and extra large.
Screen pixel densities include: low density, medium density, high density, and extra high density.

By default, your application can adapt to screens of all sizes and pixel densities, because the Android system makes the right adjustments to your UI layout and image resources. Nonetheless, you should create a dedicated layout for specific screen sizes, providing specialized image resources for specific pixel densities. You want to use an optional layout resource and use the <supports-screens> element to precisely declare the screen size supported by your program in the configuration file.

For more information, see Supporting multi-screen documents.

Input settings

many devices offer different forms of user input. For example, a hard keyboard, trackball, or a five-direction navigation board. If your program requires a special type of input hardware. Then you need to use elements in the configuration file <uses-configuration> to declare them. However, it is rarely necessary for a program to declare a particular input configuration.

Device features

There may be many hardware and software features that are not necessarily supported by an existing Android device. For example, a camera, a light sensor, Bluetooth, a specific version of OpenGL, or a precise touch screen. You may never be able to conclude that a particular feature is supported by all Android devices. (unless it's the standard class library for Android), you should use <uses-feature> elements to declare the attributes that your program uses.

Platform version

different Android devices often run different versions of Android platforms, such as Android 1.6 or Android 2.3. Each successive version typically contains additional APIs that were not supported by the previous version. To indicate which APIs are available, a platform specifies an API level. (For example, Android 1.0 is API 1,android 2.3 is API 9). If you use the API that was added after the 1.0 release, you should declare the minimum API level where the APIs are located and need to use <uses-sdk> elements to declare them.

It is necessary that you declare these requirements for your app, because when you publish your app on Google Play, it will filter out which apps are applicable to those devices based on those claims. Therefore, your program should only apply to devices that meet the needs of your program.

For information on how Google Play filters apps based on these (and other) requirements, check out the filtered documents on Google Play.

Program Resources

An Android app is not just composed of code-it also requires code-delimited resource files, examples, audio files, and anything related to the program's visible content. For example, you should define the layout of animations, menus, styles, colors, and user interaction pages described by an XML file. Using program resources makes it easy to modify many of your program features, and you don't have to modify the code. -and by providing an optional collection of resources-it also enables you to configure the optimizer for different devices (for example, different languages and screen sizes).

The SDK build tool defines an integer ID for each resource used by the Android project, and you can get a reference to the resource in the code or to other resources in the XML by this ID. For example, if your program contains a logo.png picture file named (saved in the res/drawable/ directory), the SDK tool generates a R.drawable.logo resource ID called, which you can use to refer to the image and add it to your user interaction.

An important ability to provide source-delimited resources is to provide a choice of resources for different device configurations. For example, if you define a string of UI in XML, you can translate these strings into other languages and save them in separate files. Then, depending on the language modifier you append to the resource directory name (for example res/values-fr/ , the value of the French string) and the user's language settings, the Android system will provide the appropriate language string to your UI.

Android supports a number of different modifiers to support optional resources. These modifiers are short strings that are added to the resource directory name. This is defined to define the specific configuration of the device to ensure that resources under this directory may be used. For example, you might create a different layout for your activity because of the screen orientation and size of your device. For example, when the screen is upright (high), you may want to arrange a set of buttons up and down, and when the screen is sideways (wide), you want the buttons to be arranged horizontally. The way you change the layout depends on the direction of the screen, you can define two different layouts, and then add a suitable modifier to the directory name for each layout. The system then requests the appropriate layout based on the direction of the current screen.

For more information about the different types of resources your program can import and how to create optional resources for different device configurations, consult the Application Resource Developer Guide.

My Android Chapter III: Introduction to Android Components