unoplatform / uno

Build Mobile, Desktop and WebAssembly apps with C# and XAML. Today. Open source and professionally supported.
https://platform.uno
Apache License 2.0
8.6k stars 693 forks source link

`Page` back navigation should behave the same as in UWP/WinUI #8608

Open MartinZikmund opened 2 years ago

MartinZikmund commented 2 years ago

Current behavior

Currently during page navigation, non-Windows targets behave as if NavigationCacheMode was set to Enabled - e.g. when some fields are filled by the user or some data are loaded in lists, they are preserved when user navigates to another page and back, whereas in case of UWP/WinUI they are presented with a "blank state" instead, unless NavigationCacheMode is explicitly enabled.

WASM (or any other target)

wasmtest

UWP

uwptest

Expected behavior

Match UWP behavior.

How to reproduce it (as minimally and precisely as possible)

No response

Workaround

No response

Works on UWP/WinUI

Yes

Environment

Uno.UI / Uno.UI.WebAssembly / Uno.UI.Skia, Uno.WinUI / Uno.WinUI.WebAssembly / Uno.WinUI.Skia

NuGet package version(s)

No response

Affected platforms

iOS, Android, WebAssembly, macOS, Skia (WPF), Skia (GTK on Linux/macOS/Windows), Skia (Tizen)

IDE

No response

IDE version

No response

Relevant plugins

No response

Anything else we need to know?

No response

marwalsch commented 1 year ago

This issue has some really wicked side-effects on iOS and Android, most of which cannot even be reproduced on UWP with NavigationCacheMode set to Required. For instance, checkboxes maintain their visual checked-state when navigating away and back to the page containing it. This is just as easy to reproduce at it is to build a workaround for though.

However, the real facer I came across is certain UI elements not reflecting their actual state or refusing to fire specific events. The most notable encounter with this relates to swipe-items visually responding to all interactions, but not firing their assigned Invoked events. This behaviour pops up rather arbitrarily and is hence hard to provide a reproducible sample for, but it occurs exclusively when the page bearing the control is navigated back to.

This looks a lot like a dirty-cache issue to me, albeit I do not venture to say whether this is on Uno's end or to be blamed on the native OS. The most obvious workaround to me is intercepting the page initialization and force a true reload when elsewise only a cache reload would take place:

protected override async void OnNavigatedTo(NavigationEventArgs e)
{
    base.OnNavigatedTo(e);

    if (e.NavigationMode == NavigationMode.Back) 
    { 
        // call 'Frame.Navigate(typeof(CurrentPage));'
    }
}

This is far from ideal as it almost doubles the time the navigation takes due to 'OnNavigatedTo' not being called until the page's tree has been build. The suggestion from #4156 to set the Frame.CacheSize to zero bears no notable effect here.

I wonder if anyone has encountered similar or happened to have a clue for a better workaround.