Please don't throw away view state

[anohren]

When a new top level view is selected in the main menu the previous view's state is immediately discarded. This is quite frankly super annoying. Imagine if iOS did this by default with all its tab bars; it'd drive people insane, for the last 15 years!

In less than 5 minutes I managed to twice fail an edge swipe to navigate up in a nav controller, instead had my swipe registered as "reveal main menu" whereupon I accidentally selected a new menu item. When I returned to the previous view it has reset the tab selection + entire deep navigation. This is the opposite of Design for Error, where mistakes should be reversible (think Back button in file/web browsers, etc).

I'd argue that more than any other open issue, this would single-handedly and significantly increase the experience of using the app. I urge you to consider this. I'd even make a case for persisting the navigation (if it can be made serializable), it's so important to the experience. You can easily navigate ten levels in the various sections.

It's always possible to respond to low memory events if that later turns out to be a problem on 13 year old devices (but hasn't the iOS requirement gone up recently?)

[wutschel]

Yes, the app recreates the menu each time a menu is entered. The app was handling it like this since it got created >10 years back. Changing this can also trouble users. For example, I am personally using this behaviour to start fresh into navigating a menu. Technically it is of course possible to retain the menus and keep their state, but this needs more thinking on uses cases.

Let's exchange few thoughts on how the UI should behave from your point of view: If menus are always keeping their state, how would you support entering a menu from its root ("clean" start)? I'd like to keep this possibility as it is tedious to navigate back from a deep level by pressing "Back" many times.

[anohren]

Sure thing

how would you support entering a menu from its root

I usually fall back on platform conventions for default solutions unless there's a good reason not to. In other words I'd do it like it's been done with horizontal tab bars (exact same component — different orientation) for over a decade on iOS: tapping the already selected tab loads the root view controller of the embedded nav controller. Edit: more specifically, it pops all view controllers currently pushed on top of the root.

That one was easy 🙂

Edit 2: But also, since we in practice have nested tab bars here and the second level ("real") tab bar is the system default, it already supports this behavior (!) and the only reason it's inaccessible is because the app currently hides the tab bar upon navigation (unconventional).

And even then, there's the tap and hold shortcut on the nav bar back button that can, if somewhat less conveniently (large screen anyone?), accomplish a pop to an arbitrary level of navigation, including the root.

[wutschel]

Let's assume you are deep in the Music menu and you then go back to main menu.

1. You enter Movies (or any other menu) and then go back to Music -> the retained Music menu is shown.
2. You again press Music -> the Music menu is loaded from its root.

Do I get it right?

[anohren]

You've got it, that's what I'd suggest. If you want the horizontal tab to reset at that point too (but why?) it'd be as trivial to do.

[wutschel]

You've got it

Ok, on iPad the menu behaves different right now. When you select the current selected/shown menu, the view stack is closed. If we should go for your suggestions, this option is gone. Good thing at least: Since several versions there is a "close stack" button at the iPad's toolbar which can do the same. Before, there was no other way to close a menu stack than selecting again the active menu.

If you want the horizontal tab to reset at that point too (but why?)

This is at least how it feels right for me.

Just did a very hacky proof-of-concept change. Generally the logic can be implemented with not too many changes. But: There are functional issues, like sliding not possible for menu which were retained. So, this needs a deeper look (most likely some code needs to move to different lifecycle methods) and will not be done for the next release, which I still hope to have out before christmas. But I see your point and will continue with this.

[anohren]

the view stack is closed.

Do you mean that it hides the sidebar in a split view? Sorry, don't have an iPad at hand.

Whatever the outcome, thanks for taking this into consideration.

[wutschel]

The sliding issue for iPhone is resolved, but the implementation for iPad needs a lot more thinking ...

[anohren]

The sliding issue for iPhone

Which one is that exactly? You mean my example? Solved by saving state, or in some other way?

iPad needs a lot more thinking

If you describe the problem maybe someone has some ideas. I'm still not sure exactly what's happening.

[wutschel]

Which one is that exactly? You mean my example? Solved by saving state, or in some other way?

The issue was that after (re-)opening a retained menu which was showing the details view on top (e.g. movie details), the pan gesture to move back to the main menu was not working. Reason was simply a missing initialization, which had no impact in the older implementation. In the old implementation this initialization was always done in the menu step before reaching the details view.

If you describe the problem maybe someone has some ideas. I'm still not sure exactly what's happening.

I already advanced further on this, the solution is not elegant, but conceptually works. I was not sure which instances to retain: keeping the whole StackViewController for each menu, or keeping only the views inside it. Now I went for creating multiple instances of StackViewController (on demand), and retaining them.

One thing which I am still not sure how to do on iPad: How shall the stacks behave when selecting NowPlaying in the manu or when pressing the NowPlaying icon in the toolbar. Until now, both would fully delete the stack content and result in newly entering menus on selection. Now, I can either hide or delete the stacks, whereas

• Hide = view hierarchy is retained
• Delete/remove = view hierarchy is deleted, newly entering the menu next time

Impressions:
iPad
iPhone

[anohren]

I had no idea you had a whole Xbox 360 blades interface on iPad. I've been missing out. Ok, that is more complicated.

Only looking at the video and not the code I'm assuming Now Playing is a special case that isn't contained in a stack, which is why it needs special treatment (maybe it's always loaded even?) I think I understand.

The simple answer usually works: all menu items are presented as equal, so they should behave as much the same as possible. To favor consistency it'd be preferable to not throw away any stack, or you'd end up with users perceiving it as a lottery whether they'll retain their place or not when selecting a menu item.

If anything that'd be even more aggravating than always losing your place, because the latter is at least predictable behavior. I'd go with hiding the stack and see how it works.

[anohren]

Checking in to see if you made progress or if you put it on ice, and to ask if you have a TestFlight build of this that you'd want tested?

[wutschel]

Checking in to see if you made progress or if you put it on ice, and to ask if you have a TestFlight build of this that you'd want tested?

I wasn't working on this in the past weeks. There were other issues (releases, hotfixes) to tackle first. Please do not expect progress on this in the next time. First, some other rework which already has PRs raised needs to go in. And there's real life as well 😎