-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
fix-next(tabview): visually pre-load tab items on android #5495
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
38d179c to
f916c22
Compare
| return this._viewPager.getOffscreenPageLimit(); | ||
| } | ||
| [androidOffscreenTabLimitProperty.setNative](value: number) { | ||
| console.log("----> androidOffscreenTabLimitProperty: " + value); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just noticed when looking at new PRs, probably didn't mean to include this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 thanks ^^
| transaction.remove(this._currentEntry.fragment); | ||
| transaction.commitAllowingStateLoss(); | ||
|
|
||
| this._currentEntry.fragment = null; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Removing currentEntry.fragment while animation is not completed will trigger problems with application restore.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, this fixes an issue with application restore. In the scenario - Tabs - Frames - Pages - all of the Frames fragments are restored before the Tabs fragments are recreated and they try to load their pages before they have been selected. The solution we came up with is to remove the Frame fragment on unload of the frame. A new problem came up - on suspend the Frame is unloaded after saveInstanceState, so the fragments are not really removed according to Android and it tries to recreate them on resume. That is why we set the currentEntry's fragment to null, so that on fragment create we can set it's contents to null, making it a non UI fragment. When the Frame is then loaded it will create a new fragment for the page.
Basically, we want the Android to re-create the Tab fragment, which loads its Frame which creates a new fragment for the Page. I'm open to other ideas.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I couldn't reproduce the problem that nullifying the fragment was supposed to fix, so I removed it 👍
| const entry = this.entry; | ||
|
|
||
| if (!entry) { | ||
| // On app suspend the Frames that are unloaded destroy their fragments after |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You need to match restored fragment to Page or TabItem otherwise you will have a blank pages in some cases when application is restored.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is connected to the currentEntry fragment assigned to null. It handles this case.
| // TODO: addCheck if the fragment is visible so we don't load pages | ||
| // that are not in the selectedIndex of the Tab!!!!!! | ||
| if (!page.isLoaded) { | ||
| if (frame.isLoaded && !page.isLoaded) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if frame.isLoades is false will only make page load later and it will break page transitions (pages will be empty)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you share a test case, so that I can check the problem?
| const index = tabView.items.indexOf(this); | ||
| // Don't load items until their fragments are instantiated. | ||
| if (index === tabView.selectedIndex && (<TabViewItemDefinition>this).canBeLoaded) { | ||
| if ((<TabViewItemDefinition>this).canBeLoaded) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This will load several views (before and after the selectedIndex). The whole point was an improvement so that we fire loaded only for the current selectedIndex.
Firing loaded may trigger another events like navigation, etc...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unfortunately, for Android we have to load as much views as the ViewPagerAdapter creates. Otherwise the swipe gesture of the TabView shows blank page before the navigation is completed. CanBeLoaded is assigned by the ViewPagerAdapter instantiate item method. We have also enabled androidOffscreenLimit to be equal to 0, which enables the scenario you talk about. The idea is to have it 0 when the TabView is on the bottom and there is no swipe to navigate.
f916c22 to
f5037c0
Compare
|
test branch_cuteness#tab-view-fragments |
|
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
No description provided.