Add a TabLayoutOnPageChangeListener that implements ViewPager.OnPageChangeListener

[aurelhubert]

Add a TabLayoutOnPageChangeListener that implements ViewPager.OnPageChangeListener

[consp1racy]

This widget is not supposed to be used with ViewPager. Read the specs. You're supposed to crossfade between - let's say - Fragments.

[ncapdevi]

Maybe not entirely necessary, as you can do it this way

mBottomNavigation.setOnTabSelectedListener(new AHBottomNavigation.OnTabSelectedListener() { @Override public void onTabSelected(int position, boolean wasSelected) { mContainer.setCurrentItem(position); } });

But doing it this way still doesn't fully follow the spec, as it allows for horizontal scrolling between tabs, so you have to override that as well. That's why this implementation would be nice, as it eliminates a lot of boilerplate code and follows the spec.

[ncapdevi]

@consp1racy That doesn't mean it can't be used with a ViewPager. You can disable the horizontal swipe, and leverage the ViewPager's ability to instantiate, manage, and recycle fragments.

[consp1racy]

@ncapdevi Correct, I like and use this behavior myself. However since ViewPager itself is not issuing swipes, ergo not changing current position, it does not need to notify anyone of it rendering the need for suggested listener obsolete.

You can change the current item either by clicking a bottom navigation item or calling setCurrentItem on the bottom navigation view in which case the associated OnTabSelectedListener is invoked and the change propagated to the view pager. In any case bottom navigation is always the cause of change in the view pager. One issue comes to mind. Saved state. One of these would make a solution:

• Either saving last selected item (library maintainer),
• or setting current item before assigning listener (library client)
• or creating a setupWithViewPager method which does the above for you (library maintainer).

@aurelhubert I advise picking whatever TabLayout does for the sake of consistency.

Off-topic:

This got me thinking how to crossfade the fragments when we're using the view pager to manage them. We could disable caching pages on the view pager so the fragments are not preloaded and then override [onCreateAnimation](http://developer.android.com/reference/android/support/v4/app/Fragment.html#onCreateAnimation%28int, boolean, int%29) in each fragment we're using and supply a fade animation. What do you think of this? Would it be possible to verify this behavior?

[ncapdevi]

Agreed. I posted this before I actually implemented it, and the OnTabSelectedListener seems to suffice without being cluttered.
Off-topic:
That's actually something I have in my pipeline to worry about as well. If it's too much of a hassle, then it negates the benefits of using a ViewPager, and means that we should be managing Tabs/Stacks entirely on our own, which is a bit of a hassle. I also (blasphemy!!!) don't feel the need to live and die by the spec sheet. It really depends on your application, and if the slide animation makes sense. That being said, it happens to not make sense for my application, and so I'll be needing to figure out a way to crossfade between tabs. I'd love for Android to implement some sort of ViewPager-esque object for this specific purpose, but who knows when that will come up. Once I get to that bridge and need to cross it, I'll send you any solution that I come up with if you'd like?

[consp1racy]

@ncapdevi TBH I didn't even know this thing was in MD until I saw the library. This is something I'd expect on iOS and old HTCs.
Definitely! If you find anything, hit me up. Thank you.

[aurelhubert]

@ncapdevi @consp1racy I've detected the lack of saveStateInstance (for example when the orientation changes). If you have any suggestions for the implementation or want to submit pull requests, it could be great guys 👍 Maybe we can rename the issue?

[aurelhubert]

@ncapdevi @consp1racy If you want to develop the functionality, feel free to ask for a pull request (I'm not sure to have the time to look at this in the next days). Thansk!

[natario1]

@ncapdevi crossfading between fragments is super easy, it just takes fragmentTransaction.setCustomAnimations(fade_in, fade_out) . No? Crossfading views might be trickier but not so difficult I’d say (Transition APIs would do this).

Apart from that, in my opinion this widget should be left completely unlinked to the child-switch process. It should just fire callbacks when a certain item is clicked, and let the client do whatever. We can’t predict how it’s going to be used.

I would also (except for very simple apps) not use any ViewPager here, since the bottom navigation is intended to give access to top level fragments, and these are presumably heavy. I would not like them to stay in memory. But that’s just my case.

Congrats for the library, I’m starting to use it now and will definitely work on state restoration, which is quite mandatory for me.

[aurelhubert]

Thanks for all the feedback. I will close this issue for now (because of all the reasons listed in this thread). @miav feel free to submit a pull request :)