The Toolbar (Part 2) and RecycleView are hidden when ListView or recycleview is rolled.

The Toolbar (Part 2) and RecycleView are hidden when ListView or recycleview is rolled.
Hide Toolbar (Part 2) When ListView or RecycleView is rolling)

>
* Original article: How to hide/show Toolbar when list is scrolling (part 2)
* Translator: chaossss
* Proofreader: the proofreader's github user name.
* Status: Completed

Hello, ladies and gentlemen !!! Today, I plan to continue with the previous blog post to explain the effects of displaying/hiding Toolbar. I suggest that you have not read the ListView or RecycleView to hide the Toolbar article when rolling. You should first read the blog and then read this blog article. Otherwise, it will not keep up with the pace of my explanation. In the previous blog, we learned how to implement the cool display/hide Toolbar of Google +. Today, I will explain how to make the effect of the previous blog evolve into Google Play Store Toolbar. If you don't talk much about it, let's start with the question:

Before we start, I want to tell you that I have reconstructed this project. I inherited the MainActivity of the project and implemented two new subclasses: PartOneActivity and PartTwoActivity. The source code is in the package partone and parttwo. You can select the one you like in the two packages.

Below is our final result. I will compare it with the Google Play Store Toolbar. You can feel it:

Preparations

I will not show you the build here. gradle file, because this and the first part of the build. the gradle file is the same, so we will start from this step -- create a layout for our Activity:

Similarly, there is only one RecyclerView and one Toolbar in layout (Tabs will be added later ). It is worth noting that the implementation here is to use the second method mentioned earlier (add Padding for RecyclerView)

Similarly, because our layout files, lists, and recycleradapters are the same as before, I will not explain them here.

Now let's take a look at the code of PartTwoAcitivty:

In PartTwoActivty, RecyclerView and Toolbar are still initialized, but you must remember to set OnScrollListener (row 27th)

I feel sleepy here, because the content mentioned above is basically similar to that mentioned in the previous article. But don't worry! I will talk about the most interesting part in this blog post-HidingScrollListener. Please hold on to me and keep up with the pace!

If you have read the first blog post, you may feel familiar with this situation (and may feel simpler ). What tricks do we play in HidingScrollListener? That is, the screen scroll offset associated with the height of the Toolbar-mToolbarOffset. To simplify the logic, only when the value of mToolbarOffset is between [0, the height of Toolbar] Can we implement our logic: When we scroll up, the value of mToolbarOffset increases (but does not exceed the height of the Toolbar). When we scroll down, the value of mToolbarOffset decreases (but not lower than 0 ). You may have many questions: Why do you need to reference mToolbarOffset? Why is the value range of mToolbarOffset between the two? Don't be afraid! You will soon understand why we want to limit the value of mToolbarOffset. What we must know is that although we try our best to avoid accidents, the reality is always unexpected, and it is no exception here, sometimes the value of mToolbarOffset will inevitably be out of our value range. However, due to our logic design restrictions, the final display effect will flash. (For example, quickly swiping and slide on the screen) this result is obviously not what our Android engineers want. Therefore, we need to crop mToolbarOffset to a certain extent, to avoid such risks. Based on this consideration, the onMoved () method -- onMoved () method is an abstract method called when we scroll the view. It may scare you, but don't panic. Hold on to me!

Next, we will go back to our PartTwoActivity design and implement the onMoved () method in our rolling listener.

Yes, that's all. After running the App, we can see our final effect:

Is it awesome ~ As we imagine, the Toolbar perfectly achieves the display/hide effect with the scrolling of the list. The credit is due to our restriction on the mToolbarOffset value range. If we omit the process of checking whether mToolbarOffset is in the range of [0, Toolbar height], and scroll up our list with the joy of completing the control, the Toolbar will indeed leave the screen as you expected, but at the same time, the Toolbar will be far away, far away, and never come back again. Then, when you scroll down with expectation, you will find that you have just said goodbye forever. If you want to meet it again, you must scroll down until mToolbarOffset = 0.

In the second case, you can scroll the Toolbar to the position where mToolbarHeight = mToolbarOffset. Now the Toolbar is just sitting on the top of the list. If you scroll up, no matter how you roll it, it will not move, but it will only sit quietly and laugh at the vicissitudes of life. And if you scroll down, it becomes the bright, cute little girl many years ago.

Although the final implementation effect looks very good, it is not what I want. Because we can stop the entire effect during the rolling process, so that some of the Toolbar is visible, and the other is invisible. But sadly, Google Play Games is doing this, and I always think this is a Bug ......

Stop Toolbar at a certain point

As far as my cognition is concerned, I think that rolling Views can be smoothly aligned to the corresponding positions, just like the Logo/SearchBar In the Chrome app or the Google Play Store app. I'm sure I have heard similar rules at the guidelines/checklist of Material Design or the Google I/O conference I have heard before.

Now let's take a look at the HidingScrollListener code:

Although we will make the HidingScrollListener code more complex to achieve the above results, I will say it again, don't panic, hold me tight! Now we only need to reload the onScrollStateChanged () method of the RecyclerView. onScrollListener class, and then do it as follows:

First, we need to check whether the list is in RecyclerView. SCROLL_STATE_IDLE status to ensure that the list is not rolling or waving (because if the list is rolling or waving, we need to consider the Y-direction position of the Toolbar as in the first blog)

If we raise our finger and the list has been moved (), we need to check whether the Toolbar is visible. If it is visible, we need to consider the value of mToolbarOffset. If the value of mToolbarOffset is greater than HIDE_THRESHOLD, we must hide the Toolbar. If the value of mToolbarOffset is smaller than HIDE_THRESHOLD, We need to display the Toolbar.

If the Toolbar is not visible, we need to do the opposite -- If mToolbarOffset is used at this time (mToolbarOffset is calculated from the top position, that is, mToolbarHeight-mToolbarOffset) if the value is greater than SHOW_THRESHOLD, We will display the Toolbar. If the value of mToolbarOfffset is smaller than SHOW_THRESHOLD, We will hide the Toolbar again.

The onScrolled () method is the same as that in the first blog post. We don't need to make any changes. What we need to do now is to implement our two abstract methods in the PartTwoActivity class:

Are you ready to see the magic?

Hey, you see, it's cool!

It may be a lot of trouble for you to add Tabs in your brain, but it is unexpected in your life.

Add Tabs

To add Tabs, you must add a tabs. xml file for the Activity layout.

You can find from the source code that I didn't add a real Tabs, just simulated Tabs in the layout. The above will not change any previous implementation, and you can put any View you want in it. Below are some Tabs implementations on GitHub that comply with the Material Design specifications. Of course, you can also implement them by yourself.

Adding Tabs means that they will slightly overwrite our list, so we need to add Padding. To reduce code operation complexity, we will not perform this operation in xml (delete the padding of RecyclerView in part_tuo_activity ), because the Toolbar may have different heights (for example, in the flat panel) when switching directions between different devices, we need to create a lot of xml to solve these messy and annoying problems. So I decided to solve this problem in the Code: This is very simple, we only need to sum up with the height of Tabs. If we set Padding to the height of the Toolbar and run it now, we will find something like this:

It looks quite normal ...... Our first item is just visible, and we can move and follow it. In fact, we did nothing in the HidingScrollListener class. The only change we need is done in PartTwoActivity:

Can you find anything has changed? We may create a reference for mToolbarContainer, but you should note that mToolbarContainer is a LinearLayout object instead of a Toolbar object, and in the onMove (), onHide (), and onShow () methods, we have changed Toolbar to mToolbarContainer. This will move the iner containing Toolbar and Tabs, which is exactly what we want to do.

If we run the modified Code, we will find that the actual running effect is exactly what we expected, but if you take it seriously, we will find that, there is actually a small Bug in it. There is sometimes a white line between Tabs and Toolbar. Although the time is very short, it is still very annoying. I personally think This is probably because when Toolbar and Tabs are displayed, they are not synchronized as we expected. Fortunately, this is not a Bug that cannot be solved ~

The solution is very simple, that is, to make the background of the Toolbar and Tabs consistent with the parent layout:

Now even if the mToolbarContainer is not properly synchronized during the display process, the white line will not appear. Just as I was about to celebrate the victory of our great campaign, there was another Bug .................. This Bug is the same as the Bug we encountered in the first blog. If we are at the top of the list, we can scroll up and drop it. If HIDE_THRESHOLD is small enough, the Toolbar will be hidden, resulting in a blank area (in fact, we set the Padding) on the top of the list, but I believe you should not be flustered now, because you already know that all bugs are very easy to solve in my eyes:

We only need to add another variable to store the total scroll offset of the list. When we are going to check whether we should display/hide the Toolbar, first, we should check whether our rolling distance is greater than the height of the Toolbar (if not, let's see the Toolbar again)

This is what we will talk about in today's blog. Let's take a look at the actual results!

The running effect is perfect, big brother ~ That is, other LayoutManagers do not need to change anything:

Some students in the comment area asked a question about the storage scroll status, which is indeed a small problem. If the text in the item in our list reaches two lines in the vertical direction and one line in the horizontal direction, the height of the item will become very strange ...... For example, if we scroll to the vertical position of 100, then rotate our device, and store the mTotalScrolledDistance value, after the rotation, we will scroll to the top of the list, then we will find that the mTotalscrolleddistance value is not equal to 0. At this time, even if I could not think of a simple solution to this problem, in our use cases, such a small problem would not have any impact. If you really want to solve this problem, my personal practice is to reset the value of mTotalScrolledDistance to 0 after rotation and display the Toolbar.

I feel like I have written a lot of content today. Do you feel tired here? However, this blog post is the last article in this series. I am very happy to learn the knowledge in the first blog. I am also touched by everyone's encouragement and praise. I will continue to write my blog and teach you more knowledge, but I do not know when to write 2333 IN THE NEXT blog.

In addition, I want to say that the methods I mentioned in these two blog posts may seem to run very well, but I did not perform very rigorous tests, so I am not sure if they can be used in enterprise-level applications (you can see that we have encountered several bugs ). The original intention of this series of blog posts is to tell you that even if you only use one or two simple methods in the standard API, they can achieve cool results. At the same time, I also found other interesting usage of these methods during my blog writing (for example, using the parallax background to create a viscous Tabs, just like on Google + personal pages ). In any case, I wish you more happiness in writing code!

Source code

The source code of the entire project has been uploaded to GitHub. You can download and use it. I love your Michal Z.

If you like this blog post, you can share it with your friends on Twitter or follow me on Twitter.