Shulou(Shulou.com)05/31 Report--

Today, I would like to share with you the relevant knowledge of Android naming conventions, which is detailed in content and clear in logic. I believe most people still know too much about this, so share this article for your reference. I hope you can get something after reading this article. Let's take a look at it.

PROCESS

In the "using solution Domain name" section of the book, Martin writes:

Remember, only programmers will read your code. So feel free to use computer science terms, algorithmic names, pattern names, and mathematical terms.

That's how the name Process (process) comes from. In the Android system, Process is just an ordinary computing process, which is what computers care about, and users naturally don't care about it. In fact, developers seldom use this concept. When we talk about processes, multi-process implementations, and inter-process communication, you think about how this is done in a computer.

In Android, each Application is opened in its own Linux thread, and when the system needs to reclaim memory, it eventually kills a process. The five states of the process are: forground (foreground), visible (courseware), service (service), background (background) and empty (empty). So to put it simply, a process includes an instruction set and memory space, and it is a unit that can be killed by the system.

TASK

In the book "using names derived from the area of the problem", Martin writes:

If you can't name the task at hand in terms familiar to programmers, use names from the problem area in question. At the very least, the programmer responsible for maintaining the code can consult a domain expert. Code that is closer to the problem area in question should use a name derived from the problem domain.

What is the most basic problem solved by Android devices? They can help people accomplish their tasks. It may seem simple, but think about how people envisioned it when smartphones were first invented. No one knows what people will be able to accomplish with their mobile phones in the future, but the tools developed by developers are basically designed to help people accomplish tasks, namely task (tasks). Task is a people-centered term that contains an unknown number of steps but has a core theme. What are the examples of tasks in daily life? Cleaning the room, driving to work and going to the supermarket are all tasks. People may have to accomplish many tasks in life, but they can only do one task at a time. People can start or stop doing tasks, or they can switch between tasks.

The same is true in Android. Users start a task when they click the application icon, and they can see the latest task in the recent task interface, pause or restart the task, or even destroy the task completely by removing a task from the recent task interface. Most importantly, users can only interact with one task at the same time.

ACTIVITY

Like task, activity is a term in the problem domain. Each task contains one or more activity. When a person is carrying out a task, he needs to complete many activities. For example, when cleaning a room, a person may be folding clothes, and when he has finished folding clothes, he will start to clean the bathtub. Before completing an activity, he can pause and jump to another activity under the current task.

When a person switches between tasks, he needs to pause one of the tasks and then start an activity in the second task. For example, when a person shifts from cleaning a room to driving to work, he needs to stop folding clothes and start walking to his car.

Although a person can switch between multiple activities, he can only carry out one activity at a time. No one can fold clothes and clean the toilet at the same time, and if someone tries, the picture must be quite entertaining. Even if he jumps back and forth between activities, he has to do the task linearly.

Similar to Activity in Android, Activity is a user-oriented concept that describes what the user is doing. A Task contains one or more Activity, but the user can only interact with one Activity at the same time, and the Activity gets all the user's attention by occupying the entire screen. The user stops and starts Activity while switching tasks, and each Task remembers which Activity the user is using, so that when you roll back through the back key, you will return to the correct Activity.

The concept of Activity is based on the user, so it is responsible for presenting data to the user and responding to input, and therefore, it should not do any behind-the-scenes operations, such as database reads and writes, network requests, and mass computing. These code modules should be decoupled from Activity and out of the user's view.

The computer operates the Activity lifecycle only when changes that have a direct impact on the user occur. These changes are called changes in configuration information, such as device rotation.

That's why we shouldn't keep the AsyncTask in stock while the equipment is spinning. Robospice seems to help developers who want to start AsyncTask in Activity. In fact, this class library should not have done this because there is a more concise architectural pattern in Android to handle these situations.

Fragment

Activity needs to be split into smaller components when it is large enough, and we don't have a term for this widget for the time being. These Activity parts are user-oriented, so we can't look for the name of the solution domain. We may think of the names "Sub Activity", "Component", "Part" or "Partial Activity", but these are inevitably misleading. Martin says in the "avoid misleading" section:

Programmers must avoid leaving false clues that hide the original meaning of the code. The use of words contrary to the original meaning should be avoided.

"sub Activity" may be misunderstood as a subclass of Activity. "Component" and "Part" are both too vague. "Partial Activity" implies that a "partial activity" is not enough, we need more than one of these components to build an Activity. To be honest, I guess there is the most heated debate about the naming of this component when insiders are designing the framework. The developer finally chose the word "Fragment", and I can't think of a better word.

Like Activity, the purpose of Fragment is to accomplish the task, but on a smaller scale. For example, the two activities of "cleaning the bathtub" and "cleaning the kitchen" need to start with the fragment of "prepare cleaning utensils". So the fragment of "prepare cleaning utensils" can be used in multiple activities, and it is not clear whether the overall activity is cleaning the bathtub or cleaning the kitchen. But for small activities such as "watering flowers", it does not need to be divided into pieces.

Some fragments are so small that they can be carried out at the same time. For example, "cleaning bathroom tiles" and "cleaning bathroom glass" can be done at the same time, although they are different fragments.

When a user stops a task or an activity in a task, a fragment is automatically stopped. A person can switch between multiple fragments without stopping activity. For example, a person can stop "preparing cleaning utensils" and start "filling buckets", but he has been "mopping the floor".

The same is true of Fragment in Android. An Activity can contain zero or more Fragment, and two Activity can contain different instances of the same Fragment. If a Fragment is small enough and closely related to another Fragment, they can be displayed at the same time, such as master/detail design pattern (master-slave view).

Users can switch between Fragment in any order. Developers can even allow users to roll back between multiple Fragment via the back button. When a user stops or pauses an Activity, Activity also stops or pauses its Fragment.

THREAD

Thread (thread), like Process (process), is the name of the solution domain. Like Process, thread is only a basic implementation of computer science concepts. Android didn't make things too complicated, using Java's thread directly. Most Thread in Android is Java Thread. Java Thread performs well, and Android only needs to inherit Thread once to implement HandlerThread.

Like Process, Thread is a computer-oriented concept. Thread is used to accomplish many things at the same time. Just like the concept of threading in computer science, multiple Thread instances can exist in a Process.

Consumers never care about what is happening on each thread or how many threads are running. Developers use Thread to tell computers to do it faster. Because developers are talking to computers, they need to think like computers. So issues involving threads are generally more difficult to understand with debug, developers need to consider computer time, not human time, developers need to think about memory access, and whether to restrict certain components to access the specified memory space at a specified time. One of the Thread, main thread, also known as UI Thread, is responsible for listening to user input and interacting with users. This thread should not perform any background operations. All Activity live in this thread and do all its work. There is only one thread when each application is opened, and it is a question for developers to consider whether multiple threads are needed. HandlerThread is a good option for background tasks.

APPLICATION

Like Process and Thread, Application is the name of the solution domain and a basic computer science concept. An Application is software that helps users accomplish (multiple) tasks. However, Application has become a concept familiar to both users and developers, so sometimes it brings some user-oriented problems.

Banks and supermarkets are Application in the physical sense, and they are created to help people accomplish tasks. Some parts of the supermarket interact directly with people, but some parts help the supermarket achieve its functions in the background, such as warehouses and accounting offices.

Many apps can be combined into one task to help users accomplish more, even if they are written by different people. If the user is doing the task of baking a cake, he can go to the supermarket to "buy raw materials" and then go home to continue baking the cake. As long as someone is interacting with an application, this application instance exists.

Opening an app can be said to be part of starting a task. For example, we are going to start the task of cleaning the room, which implies that the room already exists. When an application is no longer in use, it will be shut down. When all the people have finished the task of the supermarket, the supermarket will be closed. When a person has finished all the tasks he has to do at home, he will turn everything off.

The same is true of Application in Android. To start a Task, and then part of an Activity, is to start an Application. In general, developers only need to create an instance of Application to serve all the Activity, and when the user has completed all the Activity,Android, the Application may be destroyed.

When performing a task, the user can switch to another Application to help him with additional activities, such as through the camera application, the user can launch the mailbox application to send the mailbox with image attachments. These two applications can be developed by different developers, but both belong to the same task.

If the user forces the current task to stop in the mailbox application, the system stops the Activity in the mailbox application. If the user simply pauses and resumes the current task, the system immediately restarts the Activity in the mailbox application.

If the user starts the mailbox application directly, the system will start a new task. The Activity that belongs to the mailbox application in the camera task is not affected by the newly created mailbox task. That is, different instances of the same Activity can survive in different tasks.

Even if the user does not interact with any Activity, an Application can still exist, for example, when an Application is only doing background tasks, and the Activity is not displayed, the Application can survive.

CONTEXT

In our series of Android basics courses, I compared Context to a hook that goes deep into the operating system. Because Activity requires the system to boot, you need to use Context to ask the system to start an Activity). Because the system can populate the layout, you need to use Context to require the system to fill the layout. Because the system can send broadcasts, you can send broadcasts through Context or register for BroadcastReceiver (broadcast receiver). Because the system provides system services, you can access system services through Context.

But these things can't be done everywhere. For example, in Service, it makes no sense to ask the system to display a dialog box or launch Activity. In Application, for example, the system doesn't even know what the theme of the current Activity is, so it doesn't make sense for the system to populate the layout. So when you ask the system to complete the task, you need to tell the system in which Context (context) you want to do these things. When the system determines that what you want to do is reasonable for the current context. That's where the name Context comes from. Like Task and Activity, Context belongs to the name of the problem domain.

Context has many subclasses, but we will mainly use Application, Activity, and Service. These components describe different contexts and can do different things. Dave Smith's article details what they can do.

Context is temporary and changes over time. When dealing with Context, I always tell myself that this Context can be used to manipulate this class, but not necessarily other classes. A big source of memory leaks is passing Context around and letting other objects hold their references. If the Context here is an Activity, then the Activity will not be recycled at the end of the life cycle, so passing Context around is not a good idea, and we shouldn't do it.

When you do need to pass a Context object, to make sure that the scope of the Context object is as large as possible, generally we should pass an Application Context. When you pass a Context, don't assume that the person passing it has considered your needs, and don't assume that it's the correct Context.

Public void doSomething (Context context) {/ / Don't assume that Application mContext = context; / / always get ApplicationContext mContext = context.getApplicationContext () manually;.} above is all the content of the article "what's the naming convention for Android"? thank you for reading! I believe you will gain a lot after reading this article. The editor will update different knowledge for you every day. If you want to learn more knowledge, please pay attention to the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.