Xamarin.forms: Time lag before closing Shell flyout menu

[gnout]

Description

I created a new project in VS just by choosing the Shell template. I converted the AppShell to have flyout menus instead of tabs.
In the attached screen cast, when I tapped on the item that is currently displayed (the first tap is on the about page) then the side menu closes very smoothly which is the expected behavior.
When I tap on the second item (which is not currently displayed) then there is lag before the side menu closes. It seems as if the app is frozen for a few milliseconds.

Expected Behavior

I was expecting the closing of the side menu, in all cases, to be smooth

Actual Behavior

When tapping on one of the flyout menu items (not the one that is currently visible), there is a time lag before the flyout menu is closed and it looks (for a few miliseconds) that is app freezes. This behavior is displayed also to views that don;t have any data (i.e the About page)

Basic Information

• Version with issue: 4.2.0.778463
• Last known good version:
• IDE:
• Platform Target Frameworks:
  
  
  
  • Android: 9.0
  
  
• Android Support Library Version: 28.0.01
• Affected Devices: Nokia one 3.1, Samsung Galaxy J3

Screenshots

Screen cats is from an actual device and not an emulator

screencast.zip

[lv1il0s]

Seems related to https://github.com/xamarin/Xamarin.Forms/issues/5216 (which is closed but apparently not resolved). I'm experiencing the same issue on physical devices (Samsung S8, A3, Sony Z1 Compact) and emulators. On the other hand, iOS seems to be smooth. I hope this issue will be looked into soon.

[wagenheimer]

I also have this problem!

[Mikilll94]

Is it going to be fixed? This problem exists from the very beginning and it makes flyout unusable.

[denzerd]

I have the same problem with a really simple setup.
I assume this won't be fixed it is the same bad behaviour as it was for many years with the MasterDetailPage.
The problem is that the rendering of the underlying ContentPage takes that much time that the animation of the menu is interrupted. But even with an empty content page the rendering is not fast enough to not have at least a small stutter. And I'm on a Galaxy S8 which should be powerful enough.
I'm looking for a way to apply the MasterDetailPage workaround to this (a short delay before actually closing the menu), no luck so far.

[VirtualNomad00]

Guess it's still not solved, which is a bit frustrating as this is a major UX issue

[Mikilll94]

@samhouts @jfversluis @davidortinau

[RedChops]

Moving all pages except for one top level ShellContent from the Flyout Menu to MenuItem, navigating to them with GoToAsync, and manually closing the menu is significantly more performant. It's crazy, the performance by going this route is probably on-par with the iOS experience.

There is still an always noticeable shutter when going back to the home page which looks pretty sloppy. This is very unfortunate, especially since it seems like navigation is pretty central to the whole Shell interface. It appears to be a performance hitch related to pushing a new page on to the root of the navigation stack alone.
I found above to be not entirely correct actually. The hitch on back navigation to the home page in my case was caused by a logic problem issue causing the OnAppearing method to always fire off a 'load data' command. It still doesn't feel like a good behavior though, even if the data was actually needed to load each time, it's only setting up a couple layouts.

[DanKyungu]

@PureWeen, can you have an alternative to avoid this lag because we must go in production and i need to know if there is something we can do until the issue to be resolved, if not we'll have to move to the default MasterDetail Navigation...

[Mikilll94]

@DanKyungu
It seems that there is no workaround. You need to go back to the old Master Detail page.

It's very sad that the Xamarin team is enjoyed with the Shell but with this bug, the Shell is really unusable because you cannot use the flyout.

[wagenheimer]

This bug is really annoying! I don't understand why something so critical seems to be ignored.

[samhouts]

We're definitely not ignoring it! We've marked this as one of our highest priority Shell issues to resolve in the near future. If we discover a workaround in the meantime, we will post it here. Thanks for your patience!

[Jason424242]

I have also noticed a similar looking stutter on the Google Play store and the Outlook app. Google Play store especially when I select "My Apps & games" off the menu. Outlook sometimes when I choose a new folder. I thought it may be an inherent Android problem when starting a network fetch while an animation is running.

I just tried some things out in the debugger and the animation does not begin until OnAppearing has completed. Maybe a way to kick off my async refresh after the animation completes would help.

[nhadro]

This ia a really big issue for us. We have to release in a month, any idea if something might be in place to fix this before then? I really don't want to go back to MasterDetail.

[tossingc]

I have a workaround - it's not pretty, but it stops the flyout jitter on close. My hope is that it sheds some light to the development team on a fix for this and get others a temporary workaround.

It looks like the problem is that there is too much going on in the main thread while the flyout close transition is trying to run. (Android DrawerLayout CloseDrawer() animation)

NOTE: this workaround addresses the Xamarin Forms logic for creating and setting the page blocking the UI thread, but any other app logic running on the UI thread will cause the same jittery "close drawer" animation. One way to mitigate this would be to listen for FlyoutIsPresented to become true and pause any update logic running from running on the UI thread until FlyoutIsPresented has been false for some period. (i.e. 1000ms)

In your subclass of Shell:

1. override OnPropertyChanged and store the last time the FlyoutIsPresented property was set to false
2. override OnNavigating and if the last time the FlyoutIsPresented property was set to false is less than some value (using 1000ms in the code below), then assume the Flyout was just hidden and perform the following:
3. cancel the navigation
4. set FlyoutIsPresented to false
5. raise OnPropertyChanged for the FlyoutIsPresented to trigger the ShellFlyoutRenderer to close the drawer
6. wait a brief period for the flyout to close
7. set a flag that we cancelled the navigation so we know to skip this check on the next call to OnNavigating
8. re-run the original navigation in the arguments passed to OnNavigating the first time

    public class AppShell : Shell
    {
        ...

        private DateTime LastFlyoutHiddenUtcDateTime { get; set; }

        protected override void OnPropertyChanged(string propertyName = null)
        {
            base.OnPropertyChanged(propertyName);

            if (propertyName == nameof(FlyoutIsPresented))
            {
                if (!FlyoutIsPresented)
                {
                    LastFlyoutHiddenUtcDateTime = DateTime.UtcNow;
                }
            }
        }

        private bool WasNavigationCancelledToCloseFlyoutAndReRunAfterADelayToAvoidJitteryFlyoutCloseTransitionBug = false;

        protected override async void OnNavigating(ShellNavigatingEventArgs args)
        {
            if (!WasNavigationCancelledToCloseFlyoutAndReRunAfterADelayToAvoidJitteryFlyoutCloseTransitionBug)
            {
                // if the above value is true, then this is the re-run navigation from the GoToAsync(args.Target) call below - skip this block this second pass through, as the flyout is now closed
                if ((DateTime.UtcNow - LastFlyoutHiddenUtcDateTime).TotalMilliseconds < 1000)
                {
                    args.Cancel();

                    FlyoutIsPresented = false;

                    OnPropertyChanged(nameof(FlyoutIsPresented));

                    await Task.Delay(300);

                    WasNavigationCancelledToCloseFlyoutAndReRunAfterADelayToAvoidJitteryFlyoutCloseTransitionBug = true;

                    // re-run the originally requested navigation
                    await GoToAsync(args.Target);

                    return;
                }
            }

            WasNavigationCancelledToCloseFlyoutAndReRunAfterADelayToAvoidJitteryFlyoutCloseTransitionBug = false;

            base.OnNavigating(args);
        }

        ...
    }

@nhadro @wagenheimer @Mikilll94 @DanKyungu @VirtualNomad00 @denzerd @lv1il0s @gnout

[whitedevils]

news about resolution? is very annoying this problem. :(

[JAdeloye]

Any update on this, has been here a while and really should be resolved?

[stavroaudi]

Why returned to backlog? This should be the very first priority because it essentially prevents anyone who wants to release a half-decent app from using Shell.

[denzerd]

@tossingc
Thank you, somehow I saw your comment only now (Github mails go to spam in my mail account apparently)
However, back in the days I managed to have the same result as I have with your solution by simply doing this in the AppShell.cs

protected async override void OnPropertyChanged([CallerMemberName] string propertyName = null)
{
    if (propertyName.Equals("CurrentItem") && Device.RuntimePlatform == Device.Android)
    {
                FlyoutIsPresented = false;
                await Task.Delay(300);
    }
    base.OnPropertyChanged(propertyName);
}

I would really love to see this issue officially fixed!

[holecekp]

I have tried denzerd's workaround. Unfortunately, I could not use it because it introduces a new problem - after the shell menu is closed, there is still the old page displayed and it takes a surprisingly long time (1-2 seconds) before the new one appears. Tested on XF 4.8 Service Release 1.

I would also really like to see an official fix. This is an important issue. It results in poor user experience for Android applications that use shell. It is strange because everything is super fast on UWP.

[stavroaudi]

Same here. I’m using it right now but would like to see it fixed officially. Using the workaround for now.

Stavro

On 1 Sep 2020, at 19.37, holecekp [e-mail] wrote:


I have tried denzerd's workaround. Unfortunately, I could not use it because it introduces a new problem - after the shell menu is closed, there is still the old page displayed and it takes a surprisingly long time (1-2 seconds) before the new one appears. Tested on XF 4.8 Service Release 1.

I would also really like to see an official fix. This is an important issue. It results in poor user experience for Android applications that use shell. It is strange because everything is super fast on UWP.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.

[DanKyungu]

Until now, i suggest to use MasterDetailPage

[lv1il0s]

How can we be confident in choosing Xamarin for cross-platform development when a glaring issue like this one hasn't been addressed for over a year?

[coommark]

Any temporary workaround for this? I have a production ready app, but this has become a big issue for us.

[Nelo-cool]

Any temporary workaround for this? I have a production ready app, but this has become a big issue for us.

No.