It looks like this pull request may not have tests. Please make sure to add tests before merging. If you need an exemption to this rule, contact Hixie on the #hackers channel in Chat (don't just cc him here, he won't see it! He's on Discord!).

If you are not sure if you need tests, consider this rule of thumb: the purpose of a test is to make sure someone doesn't accidentally revert the fix. Ask yourself, is there anything in your PR that you feel it is important we not accidentally revert back to how it was before your fix?

Reviewers: Read the Tree Hygiene page and make sure this patch meets those guidelines before LGTMing.

You'll need to request a test exemption from @Hixie.

This code is integration-tested by the devicelab testing. You'll want to sync to tip-of tree and apply this change to the hello_world and platform_view samples that @yaakovschectman recently added Windows devicelab testing for in #109618.

I migrated the new Windows app entry points!

Can you elaborate on how this is tested?

@loic-sharma @cbracken in iOS, Android, and Web, my package flutter_native_splash allows devs to display a splash screen before the first frame has been drawn. This is preferable to hiding the app because it gives the user immediate feedback that the app is launching and gives a better impression of device responsiveness.

In your development of the Windows Flutter app architecture, can you include the ability for adding a native splash screen that can be displayed before the first frame is drawn?

@jonbhanson thanks for your comment.

In your development of the Windows Flutter app architecture, can you include the ability for adding a native splash screen that can be displayed before the first frame is drawn?

In the default app template, we use this to hide the main window for a few additional (and almost certainly unnoticeable) milliseconds until the first frame is ready in order to prevent the user seeing a very short flash of an unrendered view. A splash screen implementor would be able to use this callback to determine when the app is ready to display, which they can use as one input when determining when they'd like to take down the splash screen.

A splash screen isn't particularly useful for covering up delays measured in milliseconds, hence why it's not default, but:

• The frame callback is something that is potentially useful for splashscreen implementors (e.g. for apps that have long load times for one reason or another).
• Users of splash screens typically want the main window hidden while the splash screen is up, regardless
• For add-to-app scenarios, or other scenarios where Flutter owns the view, but doesn't own the window, the callback gives the app author a handy way to know when to add the flutter view to their app (or display some other useful signal to the user).

Please shout if any of these patches causes problems for your package. There's a separate bug (#41980) open for splash screen support.

I rebased this off of #110114 and added an integration test to verify the app starts with a hidden window that becomes visible after the first frame.

@cbracken and @yaakovschectman, I've dismissed your previous approvals given the changes were substantial. Please take another look when available! 😄