About Android App Components
Overview
Recently, I had to develop an Android application at an internship, and I had a hard time understanding the components, so I will write down what I learned instead of a memo. It's pretty rudimentary and may not be very helpful: satisfied:
Books used for study
Introduction to Android application development that you can learn from the basics
Overview and role of each component
- Activity
- It is a component for displaying the screen of the application, and there is a mechanism to save / restore the state and call other components. When calling other activities, the mechanism that conveys information to the system as a message is called intent .
- fragment
- An expression of the UI of the activity or a part of yesterday. It is convenient because you can change the display method depending on the size of the screen and you can make the unified UI and logic independent from the activity.
- Service
- A component that runs in the background and does not provide a UI. Since it can be operated separately from the main process, it is convenient when you want to perform the process in a way that does not interfere with the user's behavior, or when you want to continue the process without being affected by the lifestyle of the activity. However, since it basically runs on the main thread of the same process as the application, when implementing it, avoid writing the processing that overuses the CPU as it is, and run it after setting up a thread at the service site < / dd>
- Content provider
- A component that provides access to data managed by the app. It provides an interface that allows data to be acquired and manipulated regardless of the format of the managed data. The Android SDK comes with several content providers from the beginning, so you can easily get and update photos, calendar information, contact information, etc. taken with the camera.
- Broadcast receiver
- Receives the broadcast intent and processes it. The intent can be broadcast from a separate app, but it can also be issued by the system (when the device is connected to the charger, when the date changes, etc.). In addition, since the broadcast receiver displays a dialog asking the user whether to forcibly terminate the process if the process is not completed within 10 seconds by default, it is used only for the process of calling the service that updates the data, and the process itself. Should be done on the calling service side.
Component life cycle
- Activity
- The callback method is called every time the state changes. The developer performs the processing corresponding to each state to this callback method.
- Fragment
- Basically, the processing according to the callback method is described like the activity, but since the fragment is a component placed in the activity, the influence of the lifestyle of the activity Receive. If an activity is destroyed, the fragments placed on that activity are also destroyed.
- Service
- It takes different forms depending on the two startup methods, the "started" state by startService () and the "bound" state by bindService (). In the former case, the system will not stop unless it is stopped or explicitly terminated due to insufficient memory, so it is necessary to explicitly terminate it when it is no longer needed to prevent unnecessary memory occupancy. In the latter case, the executed component and service are a kind of client-server relationship, so if the caller unbinds, the service will stop. In this case, multiple components can be bound to the same service.
- Content Provider
- Generated when the app starts and will not be destroyed as long as the process continues. There is basically no need to be aware of the content provider's life cycle.
- Broadcast receiver
- onReceive () Only survives. When onReceive () finishes, it is considered an unnecessary object and will soon be destroyed. However, if you read the goAsync () method, it can be executed until you call the finish () method of the PendingResult class that is the return value.
(Reference) Activity life cycle
####
Life cycle visualization
Each component has its own life cycle, and the processing that can be done at each stage of the life cycle changes, which causes the complexity of smartphone apps. Classes that are responsible for lifecycle-sensitive processes such as display and user input should be designed to be as simple as possible. And processes such as business logic and data persistence should be designed so that they are not affected by the lifestyle of the activity.
Finally
The above is a brief summary of the components. I'm currently studying using a calculator and notepad, so if I feel like it, I'd like to write something about implementation instead of a memo. : kissing_closed_eyes: chu ☆
Ishikawa is still cold: mask: