Android learning route (25) comprehensive understanding of Android Navigation logic and androidnavigation
Reprinted please indicate the source: Android learning route (25) comprehensive understanding of Android Navigation Logic
App navigation consistency is an important part of the overall user experience. If the app navigation method is different and users cannot quickly understand it, this application will bring a lot of frustration to users, the user experience is greatly affected.
After Android 3.0, the system introduced significant changes in global navigation performance. A comprehensive understanding of the navigation effect and significance of "Back" and "Up" can greatly reduce the learning time of users, users can quickly learn how to switch between interfaces of applications.
Android 2.3 and its previous systems all use the "Back" button to navigate the app. The Actionbar that appears after Android 3.0 brings about another consistent navigation method: "Up", which is located at the far left of the Actionbar, usually composed of the application Icon and Title.
The following are examples of "Back" and "Up:
Up vs. Back The Up navigation logic is determined based on the hierarchy of the interface. For example, there is A list in interface A. Click the Item in the list to go to interface B. At this time, an Up button should be provided on interface B, and click Up to return to interface.
If an interface is the main interface of the app, The Up button does not need to be provided, and the Back button will work on all interfaces.
In an application, Back is returned to the previous interface. If you think of an open interface as an inbound stack, clicking the Back button will undoubtedly represent an outbound stack. You should always be able to find the previous interface through the back operation.
If the previous interface on the current interface is also the parent interface of the current interface, the Back and Up effects are the same. However, Up is mainly used inside the app, while Back enables the user to return to the main interface of the mobile phone, and even to return to other apps.
A simple example:
On the mobile phone's main interface, click the Gmail Application To Go To The Gmail main interface. The main interface contains the mail session List. Click one of the sessions to go to the session details interface. On the session details page, the previous interface and the upper-level interface of the interface are both session List interfaces. Therefore, when you click Back and Up, the interface returns to the session List interface. It can be found that there is no Up button on the main interface of session-based Gmail. At this time, you can click Back to return to the main interface of the mobile phone.
In addition to switching between interfaces, Back can also process navigation logic on a unified interface, such:
Click Back to disappear the dialog box on the current interface, highlight the text on the current interface, and hide the Input Keyboard.
Internal navigation of a single application
When there are many entries in an interface, you should click the Up button on the interface to return to the interface. The effect is the same as that of returning Back to the previous interface. For example, in the setting interface, there may be many places in the application to enter the setting interface. When you click Up or Back, the previous interface is returned.
If you want to switch a view within an interface, for example, if a page contains ViewPager, although sliding left or right leads to a view change on the interface, the page does not change at the app interface level, at the same time, no new navigation history is created. Therefore, such an operation will not cause a new action of "Up" and "Back.
For example:
On the session List page, click a session to go to the details page. On the details page, slide to view the details of the front and back sessions. However, this operation does not change the page (in the app interface level ), therefore, this does not affect the Back and Up effects.
However, if you click a button on the details page to go to another details page and create a navigation history. In this way, clicking Back will return to the previous page of the details page, and clicking Up will return to the interface at the upper level in the app layer.
For example:
We can also make navigation more intelligent. For example, we can click Item on the list page of a certain type to go to the details page of another type, click Back To go to the previous details page, and click Up to return to the List page of this type, as shown in:
As described above, we can get a general idea of the different roles and objectives of Back and Up. The user enters the App and switches to different interfaces. Each interface is added to a stack. Generally, Back is used to return to the previous interface in the stack; the Up interface has no direct relationship with this stack. In addition to the main application interface, other interfaces have a parent interface. The Up interface is used to return to the parent interface of the current interface.
However, in some cases, to make the Back effect more predictable, we should add interfaces to the Back interface stack so that users can know how to enter the current interface. For example, when you click Widgets on the Android desktop to enter a non-app main interface, if you do not manually insert the main interface of the app to the interface stack, click back to return to the Home page of the mobile phone, this experience is not good, so we will manually insert the interface into the stack. Details are shown in:
Cross-application navigation
In the same App, the Back and Up jobs are performed in different places. In the case of an application, the Back and Up are more different.
To understand the cross-App navigation effects of Back and Up, you must first understand the following three concepts:
Activities: we all know that an Activity is an application component that displays information interfaces and interacts with users. An app can be seen as a collection of multiple activities; the activities can be defined by the app or reused by other apps;
Task: indicates a complete operation process. For example, if you open an application, click share content on a page of the application, and select share by email. Such a process is called a task, and you can see that this process is cross-app, this task contains multiple activities;
Intent: Intent indicates the Intent of the interface jump. You can specify the interface jump, or you can jump according to the action supported by the interface. For example, the "Share" Intent in the system lists all apps that support sharing in the system;
After understanding the above concepts, let's take a look at this example:
The user clicks share on a page to jump to Gmail to share the content. This process is a task. If you click Back, it will be returned to the previous app. If you click Up, it will stay in Gmail and jump to the main interface of Gmail (the parent interface of the current interface). This process is a new task. This new task overwrites the old task. Click Back to return to the system Home interface.
Throughout the full text, we have learned the system-recommended navigation rules. We can follow the rules, but in our app, we can also analyze the specific situation. In short, one principle is to allow users to learn how to use the app more quickly, make the navigation of the interface more predictable.
This article roughly explains the Navigation mechanism recommended by the new Android system. For more details, see Navigation with Back and Up. I will also introduce how to implement Up navigation in ActionBar in subsequent articles.
Now, is it better for android to use the SlidingMenu open-source project to slide the menu bar, or is it better to use the Navigation Drawer that comes with android?
If you are learning the code, it is recommended to study the official version. However, SlidingMenu has many functions, such as controlling the background behind the menu when sliding out. It seems that the background of Navigation Drawer cannot be moved. It is a trend to replace open-source projects with official APIs, because everyone thinks that official interfaces are safe to use, but open-source projects may be more flexible.
Android learning route
If java is done, it will be easier for android to learn.
Android BASICS (debugging in the Android development environment, Android Application structure, interface components and interface programming, and four main components)
Android intermediate (file IO and SQLite, graphics, images and animations, audio and video recording for playback, sensor programming, and GPS applications)
Android advanced (Network Programming and Web Service, OpenGL-ES 3D development, integration of Google services, using NDK development, java and c mutual calls)