UWP Prelaunch lifecycle support in WinUi3 based app?

[techyrajeev]

Hi Team,
Is there any Prelaunch kind of application lifecycle in WinUi3 based apps?
Please let me know if it is called something else with WinUi3?

Also what are the ways to perform app specific background activities before app is launched or closed to have better performance?

[DarranRowe]

Well, since nobody has provided an answer, I'll try.

First, pre-launch is essentially Windows supported trickery. For code to run in a process, a process must exist.
IIRC, what happens when you register a UWP application for pre-launch is that Windows will launch the application as soon as you log on to windows, it will initialise itself and then suspend. When you "launch" the application, Windows will resume the process and then activate it.
Second, the behaviour exposed in CoreApplication was never made available to desktop applications. Since the Windows App SDK/WinUI3 is desktop only, this means that you only have access to the desktop process model.

But that doesn't mean there is nothing, it just means that things work differently, and Windows doesn't support you as much.

The documented migration path for the process lifecycle is to the Power/State notification API. The events exposed in the PowerManager class allows your application to decide for itself when to a few of the things that CoreApplication would be used for.

For things like going into the background and resuming from background, remember that desktop applications don't have to immediately exit when the main window is closed. The process will only exit when the main message pump has exited by receiving the WM_QUIT message. So, again, it is possible to get that aspect of the lifecycle in regular desktop applications. If you think about applications that show an icon in the notification area, this is essentially what they are doing.

If anything, the suspend/resume is the most problematic part. This is also why pre-launch is more difficult. It is possible to suspend an application using the Windows API, at the very least, enumerating all of the threads in a process and suspending them will result in a suspended process. You can then remove all of the memory it is currently using by emptying the working set. But a process cannot do this to itself. A process is also unable to resume itself. This means that if you want to take advantage of suspending and resuming a process, you need to write extra code to do the suspension, you also then need to get the application to look for any existing suspended instances and resume those. So, finally, there is the pre-launch. The only way you could do that is to register to start at logon and then suspend itself. But this is very dependent on the user allowing this kind of thing to happen.

In general, there is no easy replacement. In order to get anything like this in a desktop application, you have to code it yourself. Beyond this, the only real ways you can deal with the perceived performance is to push as much off onto other threads as possible. You can also use a splash screen to indicate that the application has started.