WIP - [Windows] Expose channel buffers 'resize' and 'overflow' control commands

[bleroux]

Description

This PR is a WIP PR to add two helper functions to invoke the 'resize' and 'overflow' commands exposed by the control channel.
See:

engine/lib/ui/channel_buffers.dart

Lines 302 to 309 in 93e8901

	/// ## The control channel
	///
	/// A plugin can configure its channel's buffers by sending messages to the
	/// control channel, `dev.flutter/channel-buffers` (see [kControlChannelName]).
	///
	/// There are two messages that can be sent to this control channel, to adjust
	/// the buffer size and to disable the overflow warnings. See [handleMessage]
	/// for details on these messages.

Related Issue

Windows implementation for flutter/flutter#132386

Tests

To do

[bleroux]

@stuartmorgan
While working on the Windows implementation for flutter/flutter#132386, I tried to figure out where to add the helpers functions.

On the other platforms there were somewhat obvious place to add this:

• iOS/macOS: [macOS,iOS] Expose channel buffers 'resize' and 'overflow' control co… #44848
• Linux: [Linux] Expose channel buffers 'resize' and 'overflow' control commands #44636
• Android: [Android] Expose channel buffer resize and overflow calls #44434

In this WIP PR (to be completed), I choose to add them to the core BinaryMessenger implementation, I'm not sure it is the best place.
I'm very interested in your view on this.

[stuartmorgan-g]

We try to keep the channel API as consistent as possible across the platforms, so I would expect these to be exposed on the same conceptual object(s) as on the other platforms.

[bleroux]

We try to keep the channel API as consistent as possible across the platforms, so I would expect these to be exposed on the same conceptual object(s) as on the other platforms.

I agree and i tried to find such a layer but it seems that for the Windows implementation it does not exist (probably because it was not required as the underlaying C++ API can be called directly).

For instance, when generating a plugin project for Windows, the channel and embedder implementations are directly exposed:

#include <flutter/method_channel.h>
#include <flutter/plugin_registrar_windows.h>
#include <flutter/standard_method_codec.h>

...

void WindowsPlugin::RegisterWithRegistrar(
    flutter::PluginRegistrarWindows *registrar) {
  auto channel =
      std::make_unique<flutter::MethodChannel<flutter::EncodableValue>>(
          registrar->messenger(), "windows_plugin",
          &flutter::StandardMethodCodec::GetInstance());
...

On the other platforms, the conceptual object(s) where I exposed those helper functions were:

• Android: BasicMessageChannel and MethodChannel, Java implementation of the channel API.
• iOS/macOS: FlutterBasicMessageChannel, ObjectiveC++ implementation of the channel API.
• Linux: FlBinaryMessenger, GObject implementation of the binary messenger.

[stuartmorgan-g]

For instance, when generating a plugin project for Windows, the channel and embedder implementations are directly exposed

What do you mean by "directly exposed"?

On the other platforms, the conceptual object(s) where I exposed those helper functions were:

• Android: BasicMessageChannel and MethodChannel, Java implementation of the channel API.
• iOS/macOS: FlutterBasicMessageChannel, ObjectiveC++ implementation of the channel API.

How are these conceptually different from flutter::MethodChannel?

[bleroux]

What do you mean by "directly exposed"?

The way I understand the Android implementation is that it uses JNI to call the C++ implementation of the binary messenger (i have not look closely at the JNI calls so I might be wrong).

How are these conceptually different from flutter::MethodChannel?

I saw flutter::MethodChannel as a lower level implementation, but you are right that, conceptually, there are the same.

Great, if I understand well, instead of implementing Resizeand SetWarnsOnOverflowin flutter::BinaryMessenger, the path for this PR is to implement them in flutter::MethodChannel (and probably flutter::BasicMessageChannel). Is it the right path?

[stuartmorgan-g]

What do you mean by "directly exposed"?

The way I understand the Android implementation is that it uses JNI to call the C++ implementation of the binary messenger (i have not look closely at the JNI calls so I might be wrong).

The C++ code here was written for Windows; it's not used by Android.

Great, if I understand well, instead of implementing Resizeand SetWarnsOnOverflowin flutter::BinaryMessenger, the path for this PR is to implement them in flutter::MethodChannel (and probably flutter::BasicMessageChannel). Is it the right path?

That matches my high-level expectation of what we would want. Without having looked closely at the details I don't know if there are other considerations that need to lead to a different outcome (as we unfortunately have with Linux).

[bleroux]

Closing this WIP PR and I will file a new PR based on #46998 (comment)