UNIQUE_TAB_HISTORY & UNLIMITED_TAB_HISTORY not work as expected

[BlackHornet]

Hi,

i'm trying to evaluate this library and noticed, when using one of those popStrategies tab history gets corrupted.

I'm using version 2.4.0

In my first evaluation I only defined the root fragments, and tested the tab history.

I think the problem could be in both classes the tab history is popped/removed twice: see

UniqueTabHistoryController
    override val andRemoveIndex: Int
        get() {
            val tabList = history
            val currentPage = tabList[tabHistory.size - 1]
            val targetPage = tabList[tabHistory.size - 2]
            tabHistory.remove(currentPage) <---
            tabHistory.remove(targetPage)  <---
            return targetPage
        }

In fact I think only currentPage needs to be removed. Regards

[ncapdevi]

@mateherber Thoughts?

[mateherber]

Hey @BlackHornet I'm sorry I've missed this Question entirely. Yes you're absolutely right this seems odd. The reason behind it is that we know that there will be a navigation to the target page soon and that triggers the page to be added to the history.

Let's see the following scenario: We have tab A and B in the stack [A,B] We tap the back so we'd like to go back to A tab We clear the entire stack [A,B] BUT we also call FragNavSwitchController.switchTab() callback with tab A (this you have to provide and implement properly) Then FragNavSwitchController.switchTab() will trigger a switchTab on fragnav (the same way as the user would have done) and we'll get back A to our history: [A]

For this to work properly you'll have to provide FragNavSwitchController and implement it to drive your bottom bar the same way as user does.

[mateherber]

The reason behind this implementation is that most of the time the developer can't switch the bottom bar library to a tab without raising the same callback when the user had tapped and switched and in that case without this "optimization" it would get [A, B] -> [A] -> We programatically switch to tab A -> we get again an A to the stack [A, A] which would be wrong.