Closed crazytonyli closed 3 weeks ago
App Name | Jetpack Alpha | |
Configuration | Release-Alpha | |
Build Number | pr23578-345b07c | |
Version | 25.3 | |
Bundle ID | com.jetpack.alpha | |
Commit | 345b07cbcdd901e29cb975a3495c8b0869730016 | |
App Center Build | jetpack-installable-builds #9719 |
App Name | WordPress Alpha | |
Configuration | Release-Alpha | |
Build Number | pr23578-345b07c | |
Version | 25.3 | |
Bundle ID | org.wordpress.alpha | |
Commit | 345b07cbcdd901e29cb975a3495c8b0869730016 | |
App Center Build | WPiOS - One-Offs #10675 |
It’s a great start. I didn’t think of preserving the state when switching tabs, but it makes so much sense. In terms of the architecture, it’s a great idea to extract the individual tabs.
I noticed an issue where when you switch from “Notifications” to “Reader”, the main sidebar loses the selection state or shows the previous selection, but I think I also saw this in trunk.
@kean I believe I have addressed all your comment. Do you mind having another look?
I noticed an issue where when you switch from “Notifications” to “Reader”, the main sidebar loses the selection state or shows the previous selection
I couldn't reproduce this issue...
The updates are looking good!
I fixed the menu showing incorrect selection issue separately here https://github.com/wordpress-mobile/WordPress-iOS/pull/23595.
In term of memory warnings, I think it's fine to keep, but I'm not sure there is much value. I'd rather remove them.
In term of memory warnings, I think it's fine to keep, but I'm not sure there is much value. I'd rather remove them.
Ops. I forgot about your comment about the memory warnings. I'm okay with removing that.
I didn't really measure how much memory the Notifications and Reader may take. It's just a gut feeling that they may take up a not small amount of memory because there are potentially a few view controllers in those "tabs", not just the one at the root level.
Issue
I'd expect the content in step 2 is displayed. But the actual result is the root-level of the Reader is displayed.
(*) The same issue can happen on a site or the Notifications.
Changes
This PR preserves the previously viewed content by keeping the relevant view controllers in memory and using them instead of creating new ones when switching back.
At the moment, other than sidebar, there are three things that can be displayed within the split view: site details, Notifications, and Reader. I have create dedicated types for those content, so that they are better organized in code than storing view controller instances directly as
SplitViewRootPresenter
properties.Please note, when switching between sites, the previously viewed screen in the last site will still be lost. It'd be a simple change to preserve that too. I'm open for suggestions, but I don't feel like it's as important as preserving previously viewed screen in the Notifications and Reader.
Regression Notes
Potential unintended areas of impact
What I did to test those areas of impact (or what existing automated tests I relied on)
What automated tests I added (or what prevented me from doing so)
PR submission checklist:
RELEASE-NOTES.txt
if necessary.Testing checklist: