Hide Toolbar (Part 2) when a ListView or Recycleview scrolls

Hide Toolbar (Part 2) when a ListView or Recycleview scrolls

>
* Original link: How to hide/show Toolbar when list was scrolling (Part 2)
* Translator: Chaossss
* Reviewer: Here The reviewer's GitHub user name
* Status: Complete

Hello, dear friends, I am again!!! Today I'm going to go on a blog post and continue to show you how to show/hide the toolbar effect. I suggest that you have not read the ListView or Recycleview Scroll to hide toolbar This article's small partners first to see the blog post again to see this blog post, or will not keep up with my rhythm of the OH. In the last blog post, we learned how to achieve the cool Show/hide toolbar effect of Google +, and today, I'll show you how to make the effect of the last blog post evolve into Google Play Store toolbar, and that's nonsense. Let's get down to the chase now:

Before we get started, I want to tell you that I've already done some refactoring on this project--the mainactivity of my successor project has implemented two new subclasses: Partoneactivity and Parttwoactivity. Source in the package Partone and Parttwo, you can choose in these two bags you like the one that uses

Here's our final, I'll compare it with the Google Play Store Toolbar, and you can feel it:

Preparatory work

I'm not going to show you the Build.gradle file here, because this is the same as the first part of the Build.gradle file, so we'll start with this step-creating a layout for our activity:

Similarly, layout has only one recyclerview and one Toolbar (plus Tabs later). It is worth noting that my implementation here is using the second method mentioned earlier (add padding for recyclerview)

The same reason, because our layout file, list, Recycleradapter are the same as before, I will not give you here to explain.

Now let's take a look at Parttwoacitivty's code:

In Parttwoactivty, it is still simple to initialize Recyclerview and Toolbar, but everyone must remember to set Onscrolllistener Oh (line 27th)

I feel sleepy when we see this, because the content mentioned above is basically similar to the previous one. But don't panic! I am going to talk about the most interesting part of this blog post--hidingscrolllistener, please hold me tight, keep up the rhythm!

If you read the first blog post you may feel familiar with the situation (and may feel simpler). What tricks did we play in the Hidingscrolllistener? That is, the screen scroll offset--mtoolbaroffset that is associated with the height of the Toolbar is saved. To simplify the logic, we implement our logic only when the value of Mtoolbaroffset is between [0, toolbar height]: When we scroll up, the value of mtoolbaroffset increases (but does not exceed the height of toolbar) When we scroll down, the value of the Mtoolbaroffset is reduced (but not less than 0). You may now have a lot of questions: why quote Mtoolbaroffset? Why should we let the value of Mtoolbaroffset range between the two? Don't be afraid! You will soon understand why we have to limit the value of Mtoolbaroffset. What we must know is that although we try to avoid accidents, the reality is always unexpected, here is no exception, sometimes the value of mtoolbaroffset is inevitable in our range of values, but due to our logic design constraints, the final display effect will be flashing a bit. (For example: a quick swipe on the screen) The result is obviously not what our stylish Android engineers want, so we need to cut the mtoolbaroffset to some degree to avoid the risk. Based on this consideration, we overloaded the onmoved () method--onmoved () method is an abstract method that is called when we scroll the view. May scare you, but don't panic, keep holding me!

Next, we'll go back to our parttwoactivity design and implement the Onmoved () method in our scrolling listener.

Yes, that's all. When we run the APP, we can see the end result:

Does it feel like it's awesome? As we have imagined, the Toolbar perfect with the scrolling of the list to show/hide the effect. The credit is due to our limitations on the range of Mtoolbaroffset values. If we omit the process of checking whether Mtoolbaroffset is taking value in the [0, Toolbar height] range, scroll up with the joy of completing the control our List,toolbar will indeed leave the screen as you would expect, but at the same time, Toolbar It will be far, far away, out of view, never to return. And then when you scroll down like a promise, you'll find that good-bye is forever. If you want to meet it again, you will have to want to scroll down until Mtoolbaroffset = 0.

Second case, now you just roll the Toolbar to Mtoolbarheight = Mtoolbaroffset position, impartial. So now toolbar is just "sitting" on the top of the list, if you scroll up, no matter how you roll, it will not move, will only sit quietly and laugh at the vicissitudes. And if you scroll down, it becomes the bright, lovely little girl many years ago.

Although the final implementation looks great, it's not what I want. Because we can stop the whole effect in the rolling process, so that the Toolbar part is visible and the other part is invisible. Sadly, that's what Google Play games did, and I always thought it was a bug ...

Stop at some point Toolbar

As far as I'm concerned, I think scrolling views can be aligned in a silky smooth manner, like the Logo/searchbar in Chrome or the Google Play store app. I'm pretty sure I've heard a similar specification at Material Design's guidelines/checklist or the Google I/O conference I've heard before.

Now let's look at Hidingscrolllistener's code:

Although we will make Hidingscrolllistener's code more complicated in order to achieve the above-mentioned effects, I repeat, don't panic, hold me tight! Now we just need to reload the onscrollstatechanged () method of the Recyclerview.onscrolllistener class, and then do the following as follows:

First, we need to check if the list is in the Recyclerview.scroll_state_idle state to make sure the list is not scrolling or waving (because if the list is scrolling or waving, we need to think about it like the first blog post). Toolbar y-direction position OH)

If we lift our fingers and the list has stopped moving () We're going to check if the toolbar is visible, and if it's visible, we need to consider the value of Mtoolbaroffset. If the value of Mtoolbaroffset at this time is greater than hide_threshold we must hide Toolbar, Mtoolbaroffset value is less than hide_threshold, we need to let the Toolbar show.

If the Toolbar is not visible, we need to do the opposite-if mtoolbaroffset at this time (the calculation mtoolbaroffset to be considered from the top position, that is, Mtoolbarheight-mtoolbaroffset) More than Show_threshold we let toolbar show, on the contrary, if Mtoolbarofffset is less than show_threshold, we will hide toolbar again.

Onscrolled () The same way as the first blog post, we don't need to change anything. The last thing we need to do now is to implement our two abstract methods in the Parttwoactivity class:

So, are you ready to look at the magic?

Hey, send big star you see, is not very cool!

Now you may be in the brain to add Tabs will be more trouble, but brother Ah, life is a lot of surprises, do not believe you continue to look down

Add Tabs

To add Tabs, the first thing to do is to add a tabs.xml to our Activity layout.

You can find from the source, I did not add the real Tabs, just in the layout of the simulation Tabs. And all of this doesn't change any of the previous implementations, you can put any view you want in it. Here are some of the Tabs implementations on GitHub that meet the Material design specification, and you can, of course, implement it yourself.

Adding Tabs means that they will slightly overwrite our list, so we need to add padding. In order to reduce the complexity of the code operation, we do not do this in the XML (note the Recyclerview in the part_tuo_activity of the padding delete oh), because Toolbar It's possible to have different heights when switching directions in different devices (for example, in a tablet), so we need to create a whole bunch of XML to solve these messy and annoying problems. So I decided to solve this problem in the code: it's very simple, we just need to sum the tabs height. If we set the height of the padding to Toolbar and now run, we'll find something like this:

It looks like it's normal. Our first item is just as good as it is visible, and we can move on and follow it. In fact, we did nothing in the Hidingscrolllistener class, and the only changes we needed were made in parttwoactivity:

Can you see what has changed? We might as well create a mtoolbarcontainer reference now, but be aware that Mtoolbarcontainer is a LinearLayout object instead of a toolbar object, and in OnMove (), Onhide (), and In the OnShow () method, we all changed the Toolbar to Mtoolbarcontainer. This makes the container that contain Toolbar and Tabs moved, which is exactly what we want to do.

If we run the revised code, we will find that the actual effect is exactly what we expected, but if you look carefully you 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, but still very annoying. I personally think this is probably because when toolbar and tabs are shown, they are not synchronized as we expected. But fortunately, it's not something that can't be solved. bug~

The solution is very simple, which is to keep the background and parent layout of Toolbar and Tabs consistent:

Now even if the mtoolbarcontainer is not well synchronized in the display process, the white line will not appear. Just as I was going to eat a spicy strip to celebrate the victory of our great battle, there was a bug ...... This bug and we encountered in the first it the same bug, if we at the top of the list, we can scroll up a lost, if Hide_threshold is small enough at this time, Toolbar will hide. Cause there is a blank area (in fact we set the padding) at the top of the list, but I believe you should not panic now, because you already know that all bugs in my eyes are very easy to solve:

We only need to add a variable to store the total scroll offset of the list, and when we are ready to check whether we should show/hide the Toolbar, we should first check if our scrolling distance is greater than the height of the Toolbar (if not, let Toolbar appear)

That's what the blog is all about today, let's take a look at the actual effect!

Now the effect of the operation is absolutely perfect AH Big Brother ~ that use other layoutmanagers also do not need to change anything of OH:

Comment Area there are studious classmates asked a question about the storage scrolling state, which is really a little trouble. If the text in our list item is in the vertical direction of 2 lines, the horizontal direction of 1 lines, our item height will become very strange ... For example, if we scroll to the vertical 100 position and then rotate our device and store the value of mtotalscrolleddistance, after the rotation we will scroll to the top of the list and we will find The value of mtotalscrolleddistance is not equal to 0. This time, even if I can not think of an easy way to solve the problem, but in our use of the scene, such a small problem does not have any impact. If you really want to solve this problem, my personal approach is to reset the value of Mtotalscrolleddistance to 0 and show Toolbar after rotation.

Feel like writing a lot of content today Ah, you see here should feel very tired? But today this blog post is the last article in this series, I am really happy that we can learn the knowledge in the first article blog post. I am very moved by the encouragement and compliment, I will continue to write my blog, for you to impart more knowledge, but I do not know when the next post will write 2333.

I would also like to say that the methods I mentioned in these two posts may seem to be working well, but I'm not doing very rigorous testing, so I'm not sure if they can be used in enterprise applications (you see we don't have a couple of bugs). The purpose of this series of blogs is to tell you that even the one or two simple methods in the standard API can be used to achieve cool results. At the same time, I also found in the process of blogging that there are other interesting uses of these methods (e.g., using parallax backgrounds to make sticky Tabs, as in the Google + personal page). Anyway, I wish everyone to find more happiness in the process of writing code!

Source

The entire project source code has been uploaded to GitHub, you can go to download and use Oh, love your Michal Z.

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

Hide Toolbar (Part 2) when a ListView or Recycleview scrolls