This blocks the window from closing, and assumes that closing the window is meant to close the app. What happens when we eventually have multiple windows, won't we have to check to make sure this is the last window before asking? Also, is there a case where the developer might want the window to actually close, but then keep running the app until they are ready to exit?

It would require a check if it is the last window, but I do not think that check is possible to write yet.

Could you use a Windows API to find how many open windows an app has? I think that even when we can enumerate Flutter-controlled windows in an app, we won't want to actually exit the app unless this is the last window, including windows that aren't Flutter controlled.

Instead of using the plugin API, could we instead use WindowProcDelegateManager::RegisterTopLevelWindowProcDelegate directly?

Plugins should be able to override the Windows embedder's behavior. In other words, plugins' top-level window handlers should run before the Windows embedder's top-level window handlers. Please add a test to cover this behavior.

How would we go about testing that within the engine? What would we actually be trying to confirm?

An example test could be:

1. Launch engine
2. Use plugin API to register a top-level window message handler for testing purposes:
3. Send a WM_CLOSE message. Verify that your plugin's handler was called instead of the Windows embedder's default WM_CLOSE handler

What would we actually be trying to confirm?

We want to confirm that plugins' top-level window handlers run before the Windows embedder's top-level window handlers. For example, imagine I have a database plugin that buffers updates in memory for performance reasons. This database plugin may want to listen to WM_CLOSE messages so that it can persist its data to disk when the app shuts down. For example, I could have a plugin that creates "Are you sure you really want to close the app?" popups.

That makes sense. Though do we have a way of sending a window message to a top level window for our tests? I'm not aware of anywhere we already do something like this.

It doesn't change your valid point, and I realize that's just an example, but saving data on shutdown is an anti-pattern: there are plenty of ways for an app to close without sending a WM_CLOSE that can be handled, so we don't really want to encourage people to do that (it's the reason we eliminated the exiting state from the app state design doc).

I think a better example would be so that a plugin could abort the close if it wanted to.

@gspencergoog I am here attempting to use the win32 API's functions to enumerate the windows of each thread of the current process, and only translate a WM_CLOSE message to a request to exit if only 1 window is found. However, when testing with 1-window apps, it reports there being 3 windows. I suspect one of these is the embedder window, one the top level window, and I am unsure about the third. One possibility may be to write a bool FlutterWindowsEngine::IsOwnedWindow(HWND) that returns true when the provided handle is present in a set of one HWND per view of the engine (which would currently only be one).

Oh, I see. Yeah, we'd have to only count top level windows.

Could you call GetParent on the window here and only count the ones that return NULL?

Could this accept a PlatformHandler instead of the engine? That would allow us to remove the RequestApplicationQuit from the engine

Alternatively, I would consider making this class agnostic to Flutter. You could introduce a WindowsLifecycleDelegate with methods like OnExitRequested. The FlutterWindowsEngine could implement this lifecycle delegate and call the PlatformHandler::RequestAppExit.

The former can be done so long as we expose the engine's platform handler, basically replacing RequestApplicationQuit with a getter for it. In the case of the latter, what is the advantage of making it agnostic to Flutter?

Please document type and methods

Could we move this string out of this class? Ideally all strings for Flutter framework messages are contained in the PlatformHandler.

Optional: rather than hand-writing JSON, consider doing something like:

final String jsonString = json.encode(<String, dynamic>{"response": "exit"});

Mostly because that allows the compiler to catch Dart syntax errors and json.encode to catch JSON syntax errors.

Similarly here, using json.encode to encode a map would allow the map to be laid out the way it's structured:

final String jsonString = json.encode(<String, dynamic>{
    "method": "System.exitApplication",
    "args": <String, dynamic>{
      "type": "required",
      "exitCode": 0,
    }
  };

Since we've got a reference cycle between FlutterWindowsEngine and WindowsLifecycleManager this should be a weak pointer (just a raw FlutterWindowsEngine* pointer) to indicate that to the reader.

See notes here: https://google.github.io/styleguide/cppguide.html#Inputs_and_Outputs

Just reinterpret_cast<int64_t*>(user_data) directly.