Splash screen for application startup

[llfab]

Because I had not found a working description in the past discussions, I found this sample application for a working splash screen extremely useful. Maybe that helps others as well.

https://github.com/kivarsen/AvaloniaSplashScreenDemo

[llfab]

Relates to #4155

[llfab]

Relates also to #2674

[maxkatz6]

I think it would be great addition to the https://github.com/AvaloniaUI/Avalonia.Samples
cc @timunie

[timunie]

For sure 👍

[llfab]

I am also not sure whether I understand why calling Window.Show() manually here is necessary (is possible resp.).

I kind of understand that the .Show() is necessary to first show the splash, then create main windows and do mainWindow.Show() to prevent that the "framework" will shut down due to the splash.Close(). But since in the "normal" startup code there would not be any .Show() at all (must be done automatically by the framework) that may cause some confusion. Some comments in this in a sample may make sense.

Although my own version in a larger app works, I am not sure whether I would be able to explain exactly why each .Show() call is there.

[Mrxx99]

The second window.Show() is required because this is an async void Method (and it has to be to be able to work *). As soon as the first await is executed in the method, it returns to the caller and finishes the initialization without a mainwindow (So at the place normally the window is shown, the MainWindow is still null). The code that follows is executed after initialzation is already completed. So you have to call Show manually.

* If you did not have an await in async void that early returns, you would not see a splash screen as the splash window would be opened and closed again before the framework is initialized and the thread is ready to show a Window (the UI Thread would be blocked until Initialize Method returns)

[llfab]

Thanks. Makes sense!

[mightypanda]

Hello @llfab
I am on preview8 and would like a "quick splash screen" too.
Have you advanced your research or tested it on later previews?

[llfab]

As far as I discussed with the Avalonia team, the principle that is used in above sample is still the way to go. Because you override the OnFrameworkInitializationCompleted using async, you need to call .Show() and .Hide() yourself. It works nicely on preview6. I believe it should work in the same fashion on preview7/8

[llfab]

There are plans to provide Splash more explicitly in the future but I guess it is not a priority (also because there is a working option)

[llfab]

@maxkatz6 @timunie
I found that the async override of OnFrameworkInitializationCompleted() has drawbacks. It actually means that parts of the application specific startup code will run in a thread different from main (UI) thread. This is generally not a problem. I just ran into one though, which is very specific but could happen in various areas:

• Within the async OnFrameworkInitializationCompleted() I had started a new task with await that creates the model level of the application which can take some seconds. The splash would initially appear, so everything looks nicely to the user
• Now I had added more controllers to the model level whereas one of these controllers must be started in the main thread (it uses a windows specific device change notifier using WinPro on the Windows OS). The WinProc would be successfully initialized but would never receive any messages...
• I have now concluded that creating the model level in a different thread is not such a great idea. So the async override may not be the best solution

Fortunately, I have found a solution for splash without async as follows:

public override void OnFrameworkInitializationCompleted()
{
    if (ApplicationLifetime is IClassicDesktopStyleApplicationLifetime desktopLifetime)
    {
        // Open splash screen as early as possible
        _splashScreenWindow = new SplashScreenWindow();
        desktopLifetime.MainWindow = _splashScreenWindow;

        // delegate actual application start to when UI thread has time again
        Dispatcher.UIThread.Post(() => CompleteApplicationStart(), DispatcherPriority.Background);
    }
    base.OnFrameworkInitializationCompleted();
}

public void CompleteApplicationStart()
{
    if (ApplicationLifetime is IClassicDesktopStyleApplicationLifetime desktopLifetime)
    {
        // Start the system which is taking some seconds
        _pixrBunionSystem = new PixrNpcSystem(startupParameters);
        _pixrBunionSystem.Init();

        // create the window with its data context
        _mainWindowViewModel = new MainWindowViewModel();
        _mainWindow = new MainWindow()
        {
            DataContext = _mainWindowViewModel,
        };

        desktopLifetime.MainWindow = _mainWindow;

        // Show main window to avoid framework shutdown when closing splash screen
        _mainWindow.Show();

        // Finally, close the splash screen
        _splashScreenWindow.Close();
    }
}

So this does not use an other thread. Just before leaving the OnFrameworkInitializationCompleted() we are now posting an action with low priority to the Dispatcher. Once the dispatcher "has time again", the CompleteApplicationStart() is called, starts the longer runing model level and finally sets the new MainWindow, shows it and closes the splash.

Let me know what you think...

[cok666n]

Hi, I went a similar but simpler (to me) approach here. However Im also having issues (more on this will follow).
My OnFrameworkInit looks like this

public override void OnFrameworkInitializationCompleted()
        {
            bool fullScreen = Configuration["FullScreen"]?.ToLower() == "true";

            if (ApplicationLifetime is IClassicDesktopStyleApplicationLifetime desktop)
            {
                var mwvm = new MainWindowViewModel();
                desktop.MainWindow = new MainWindow
                {
                    DataContext = mwvm,
                    WindowState = fullScreen ? WindowState.FullScreen : WindowState.Normal,
                };

                mwvm.InitTask();
            }

            base.OnFrameworkInitializationCompleted();
        }

The MainWindow/ViewModel acts as a content presenter, so the constructor displays a loading screen as its content

 public MainWindowViewModel(string devicesFilePath, string photoFilePath)
        {
            loadingViewModel = new LoadingViewModel();
            Content = loadingViewModel;
        }

Then the Async Init() function who does the heavy lifting is called

 public async Task InitTask()
        {
            try
            {
                //await longish stuff here

                Content = monitoring; //set the content to my main view model
            }
            catch (Exception ex)
            {
                loadingViewModel.Status = $"{ex}";
            }
        }

This works fine on windows desktop.

However, for some reason, this does not work on Linux desktop (Debian), nor does it work in WSL, the "Loading" view is never shown and the app just hangs for a bit and jumps straight to the mainwindowviewmodel.

So I tried your way of doing this, but I get the same results, works fine on Windows but somehow not on WSL or a full Debian install.

Am I doing something wrong that would cause this ?

[llfab]

So just to understand. - the window is shown immediately- but no loading content- hangs- final content is shown???To be honest I have not tried it on Linux. I have experienced diffs in Windowing behavior in the past but not with view content. I will try that some time on Linux...

[cok666n]

I have no idea if this is what you had in mind, and it feels a bit "hackish" to me if Im honest, but you obviously know a lot more about Avalonia than I do.

Anyway, this works in Windows, WSL, and Debian Linux

 public override void OnFrameworkInitializationCompleted()
        {
            bool fullScreen = Configuration["FullScreen"]?.ToLower() == "true";

            if (ApplicationLifetime is IClassicDesktopStyleApplicationLifetime desktop)
            {
                _mwvm = new MainWindowViewModel(); // This constructor does basically nothing else than setting the content to a "loading view"
                desktop.MainWindow = new MainWindow
                {
                    DataContext = _mwvm,
                    WindowState = fullScreen ? WindowState.FullScreen : WindowState.Normal,
                };
                // delegate actual application start to when UI thread has time again
                _timer = new DispatcherTimer(TimeSpan.FromMilliseconds(100), DispatcherPriority.Background, CompleteApplicationStart);
                _timer.Start();
            }

            base.OnFrameworkInitializationCompleted();
        }

        public async void CompleteApplicationStart(object sender, EventArgs e)
        {
            _timer.Stop();
            await _mwvm.InitTask(); //This does the heavy lifting (initialize EF, etc...)
        }

What do you think? And again, thanks for pitching in.

[jp2masa]

Why not use ContinueWith? Sample app here: https://github.com/jp2masa/AvaloniaSplashScreen.

[llfab]

What do you think? And again, thanks for pitching in.

That is what I had in mind but I don't think that the async in CompleteApplicationStart() actually does anything. So, I guess your example should work without async await.

[llfab]

https://devblogs.microsoft.com/dotnet/how-async-await-really-works/

[BreyerW]

@llfab maybe you could use technique described here https://thomaslevesque.com/2015/11/11/explicitly-switch-to-the-ui-thread-in-an-async-method/ to better control your async version where it is executed? With idea in this link you could explicitly await ui (avalonia) context if avalonia has one (if not maybe new context could be integrated since its possible to create one yourself)

[kyuranger]

I always achieve this by a stupid way:

<ContentPresenter></ContentPresenter>		

Make a splash screen with usercontrol and set it as content of a ContentPresenter in MainWindow.

After the splash screen is finished, set the content of ContentPresenter to the main page (also make it as usercontrol) of your program.

All running in the same window without creating a new one.

I am not sure whether it is what you need.

[cok666n]

This is exactly what I did, but for some reason I don't fully grasp, this did not work as intended when targeting linux desktop.
However it did work fine on windows, I did not try other platforms.
#11083 (comment)

Did you manage to make this work on linux?

[timunie]

Does any error occour on Linux that doesn't happen on Windows? Try to add try-catch and write a detailed log file of your startup procedure. Maybe something related to file access.