Introduction example tutorial of viewpager view sliding switching class in Android

The introduction of viewpager into the example first gives you a global understanding. Go directly to the last project and see that such powerful functions can be completed only through these lines of code. Effect picture: realize the mutual sliding between the three views. The first view slides to the second view and the second view slides to the third view

1、 Create a new project and introduce the viewpager control viewpager. It is a class of an add-on package in Google SDK, which can be used to switch between screens.

1. Add in the main layout file

Where < Android. Support. V4. View. Viewpager / > is the component corresponding to viewpager, which should be placed at the position where you want to slide

2. Create three new layouts. The views for sliding switching can also be seen from the effect drawing. Our three views are very simple. There are no controls in them. Of course, you can add various controls to them, but this is a demo, so I only use the background to distinguish them, not the layout.

The layout codes are as follows:

layout1.xml

layout2.xml

layout3.xml

2、 Code practice first on the overall code, and then explain it step by step.

The amount of code is very small, and it is all placed in the oncreate() function. 1. Let's first look at the meaning of the declared variable:

First, the viewpager corresponds to the < Android. Support. V4. View. Viewpager / > control.

View1 and view3 correspond to our three layouts, namely, layout1.xml, layout2.xml, and layout3.xml. Viewlist is a view array that holds the above three views

2. Next is their initialization process:

The initialization process is not difficult, that is, the resources and variables are linked to layout, and finally the instantiated view1 and view3 are added to the viewlist. 3. Pageadapter - the adapter of pageview, which must be unknown to everyone. There are adapters in listview. Listview obtains the item to be loaded by rewriting the getview() function. The pageadapter is different. After all, the pageadapter is a collection of individual views.

The pageadapter must override the following four functions:

(1) Boolean isviewfromobject (view arg0, object arg1) (2) int getcount() (3) void destroyitem (ViewGroup container, object object) (4) object instantiateitem (ViewGroup container, int position) let's take a look at the functions above:

Getcount(): returns the number of views to slide

Destroyitem(): deletes the view of the specified position from the current container;

Instantiateitem(): two things are done: first, add the current view to the container, and second, return the current view

Isviewfromobject(): we won't explain this function first. At present, we know that it needs to be rewritten in this way, and we will rewrite it later. The meaning of these functions and knowledge about key will be explained in detail below.

The four functions of viewpager 1. The official description is that pageradapter is more common than AdapterView. Viewpager uses callback function to represent an update step rather than a view recycling mechanism. When necessary, the pageadapter can also recycle views or use a more ingenious method to manage views, such as using fragments that can manage their own views.

Instead of dealing directly with each view, the viewpager associates each view with a key. This key is used to track and uniquely represent a page. Moreover, this key is also independent of the location of the adapter where the page is located. When the pageadapter is about to change, it will call the startupdate function, and then call one or more instantiateitem or destroitem. Finally, finishupdate is called later in the update. When finishupdate returns, the object returned by instantiateitem should be added to the parent ViewGroup, and the object returned by destroyitem should be deleted by ViewGroup. Methodisviewfromobject (view, object) represents whether the current page is associated with a given key. For a very simple pageadapter, you may choose to use the page itself as the key. After it is created and added to the ViewGroup, return the page itself in the instantiateitem method. Destroitem will remove the page from the ViewGroup. The isviewfromobject method can directly return view = = object. Pageadapter supports the change of data set. The change of data set must be executed in the main thread, and then the notifydatasetchanged method must be called. It is very similar to the base adapter. Changes to the data set include the addition, deletion and modification of pages. To keep the current page active, you must provide the getitemposition method.

2、 Parsing the viewpager does not directly process each view, but associates each view with a key. This key is used to track and uniquely represent a page. Moreover, this key is also independent of the location of the adapter where the page is located. When the pageadapter is about to change, it will call the startupdate function, and then call one or more instantiateitem or destroitem. Finally, finishupdate is called later in the update. When finishupdate returns, the object returned by instantiateitem should be added to the parent ViewGroup, and the object returned by destroyitem should be deleted by ViewGroup. Methodisviewfromobject (view, object) represents whether the current page is associated with a given key.

For a very simple pageadapter, you may choose to use the page itself as the key. After it is created and added to the ViewGroup, return the page itself in the instantiateitem method. Destroitem will remove the page from the ViewGroup. The isviewfromobject method can directly return view = = object.

With regard to the above two paragraphs, I have two points to focus on:

1. The first paragraph explains the concept of key. The first thing to be clear here is that each sliding page corresponds to a key, and the key value is used to uniquely track the page, that is, each sliding page corresponds to a unique key one by one. Let's have this concept first. Let's talk about how this key came from.

2. The second paragraph briefly describes an application, that is, the view of the current page itself is used as the key. In fact, this application is the example application we talked about in the previous chapter. Not quite understand? It doesn't matter. Let's talk about it in detail. Now let's talk about key.

3、 About key, let me show you the official documents of several methods:

1. First, destroy item ():

The function of this method is to remove a page at a given location. It is the responsibility of the adapter to remove this view from the container. This is to ensure that the view can be removed when finishupdate (ViewGroup) returns. In the introduction example, we do this:

Sure enough, we removed the view at the given location from the container

2. Then look at getcount ():

public abstract int getCount ()

Return the number of views available.

Returns the number of currently valid views. Then we also:

The number of views to slide is returned, which is consistent with the official description.

4、 Here comes the hardest two

1. The function of instantiateitem (ViewGroup container, int position) is to create a page view at a specified location. The adapter is responsible for adding the view to be created to the container given here to ensure that this is done when finishupdate (ViewGroup) returns! Return value: returns an object (key) representing the new view page. There is no need to return the view itself here. You can also return other containers of this page. In fact, my understanding is that it can represent any value of the current page, as long as you can correspond to the view you added one by one. For example, the position variable can also be used as a key (finally, let's give an example to see if it is feasible)

Experience:

(1) As can be seen from the description, in the code, our responsibility is to add the view of the specified position to the controller

(2) Key problem: from this function, we can see that the return value of this function is the corresponding key we added to the view in the controller according to the parameter position!!!!!!!

(3) "It only must ensure this is done by the time it returns from inishupdate (ViewGroup)." this sentence also appears in the function description of destroitem(), which indicates that after finishing update (ViewGroup) is executed, there are two operations, one is to remove the original view (the view that is no longer displayed) and the other is to add a new display view (the view to be displayed)

In the example introduced at the beginning, we did this:

Here, we do two things: first, add the view of the position given in the parameter to the controller for creation and display.

Second: return the view of the current position as the key of this view. Remember the following paragraph in the official API documentation? For a very simple pageadapter, you may choose to use the page itself as the key. After it is created and added to the ViewGroup, return the page itself in the instantiateitem method. Destroitem will remove the page from the ViewGroup. The isviewfromobject method can directly return view = = object.

Here, pass the current view as a key!!!!

2. Isviewfromobject (view, object object) function: this function is used to judge whether the key returned by the instantiateitem (ViewGroup, int) function and a page view represent the same view (that is, whether they correspond, and the corresponding represents the same view). Return value: if the corresponding view is the same view, return true; otherwise, return false.

In the above example, we do this:

In instantiateitem(), we return the current view as a key, so when judging here, we directly judge whether the key and view are the same view by looking at whether they are equal.

5、 After the above explanation, you must have a clear understanding of the concept of key. Here is an example to illustrate the relationship between key and view. Since key and view should correspond one by one, I take the position of each view as the key and change it on the basis of the examples in the previous chapter. Let's look at all the codes first, and then see some explanations:

Two changes have been made here: 1. First, look at the location of the key, instantiateitem()

We also mentioned that in this function, the key corresponds to the view currently loaded into the container as a return value. So here we return position and container. Addview (viewlist. Get (position)); The viewlist. Get (position) in the corresponds to this view. 2、isViewFromObject （）

Judge whether the key returned from instantiateitem () can correspond to the current view. We know that the key passed from instantiateitem is actually position, so we need to find the view according to position, and then judge with view arg0 in the parameter.

However, there is a problem in the real operation. We must first convert the object correspondence to the int type: (int) integer. ParseInt (arg1. Tostring()); Then find the corresponding view according to position;

Effect picture: sliding switching between three views

Different from the previous chapter, only the upper part has sliding switching because I changed the layout file:

Here will be layout_ The height is changed to 200dip, so this is to tell you that the switching can be realized by adding < Android. Support. V4. View. Viewpager / > where you want to realize sliding switching, regardless of position and size, just like ordinary controls!!!!!!