Need a way to pass messages back to the native app code

[mehmetf]

This is meant to be a discussion thread, we are already implementing a solution for this. We wanted to document the problem and potential solutions before we finalize it.

Leafy is writing a Flutter plugin to do logging specific to Google infrastructure. This plugin, unfortunately, needs authentication to work on iOS. The problem is that authentication token/object comes from a different plugin.

Normally, in native apps, this is solved by having the app code manage the flow between these two services (auth and log) once authentication is done. This can be done in Flutter too if it is managed entirely in native code. However, the proper way to do authentication is via plugins. Dart app code orchestrates the auth flow. That means I need to be able to somehow signal the native app code that the auth is done. So far, we thought of several solutions; none of which is perfect:

• Create a dependency between the log and the auth plugin. Once auth is done, auth notifies the log plugin. This does not work because log plugin is Google specific while auth can be OSS.

• Make auth plugin publish an event such as "authComplete" and have main app code subscribe to it. This would work but does not reflect the reality where authentication is actually orchestrated on Dart side; not native. It also feels like a one-off. What about errors? Do we also publish "authError"?

• Pass a message from Dart to native app code directly. This mechanism does not exist currently and could be tricky to implement (e.g. we need this to work on any Android activity, which is the direction Flutter wants to go). This solution is interesting because we do have communication of lifecycle events from native -> dart at the moment. So it would be good to have a symmetry where dart can define its own lifecycle messages and deliver to native side.

• Implement a callback plugin that can be configured by the native app code to run a function when a signal is received from Dart side. However, Flutter is moving towards a easy-to-use plugin model where main app code does not even get an instance of the plugin. Registration is done automatically.

We are currently leaning toward implementing the last solution. The idea is to do something like this:

Native app code:

onCreate() {
  AuthPlugin auth = new AuthPlugin();
  LogPlugin log = new LogPlugin();
  CallbackPlugin.setupCallback("authComplete", () -> {
     log.configureLog(auth);
  });
}

Dart code:

// When auth is complete
callbackPlugin.runCallback('authComplete');

Please comment on whether this is a workable solution. Also, please let me know if it is possible to get a hold of automatically registered plugin instances in native app code. If not, callback plugin approach would not work.

[eseidelGoogle]

FYI @mravn-google @collinjackson

[mehmetf]

Also @tvolkert

[mravn-google]

FlutterActivity implements the PluginRegistry interface and FlutterAppDelegate implements the FlutterPluginRegistry protocol. When plugins auto-register with this registry concept, they may publish arbitrary values into the registry -- including, but not limited to, an instance of the plugin's main class.

Native app code can thus easily access auto-registered plugins as needed for your last solution above, by lookup of published value by plugin ID.

However, I did not take into account the desire for plugins to lookup values published by other plugins, because we currently do not control the order of plugin registration. In your case, presumably the lookup can wait until all registration is done and an auth complete message is sent from Dart. At that point your LogPlugin would want to look up the AuthPlugin from the registry, right?

But plugins are never directly given a reference to the PluginRegistry during registration. On Android, they have access to the FlutterActivity as an Activity-typed reference which can be cast to PluginRegistry. On iOS, you should be able to cast [[UIApplication sharedApplication] delegate] to UIApplicationDelegate<FlutterPluginRegistry>*.

[mravn-google]

Just checking: the log.configureLog method really needs the full AuthPlugin, including behavior? It is not just extracting passive data from it that it could instead receive via a platform message sent by Dart to a channel known to LogPlugin upon auth completion?

[mehmetf]

Just checking: the log.configureLog method really needs the full AuthPlugin, including behavior? It is not just extracting passive data from it that it could instead receive via a platform message sent by Dart to a channel known to LogPlugin upon auth completion?

Correct. It is actually more complicated than that. Auth plugins are glue code that hide the underlying complexity of authentication objects (such as GIDSignIn). These objects are what the log plugin needs (not the auth plugin itself) and they cannot be passed back and forth via a platform message. I tried to write an adapter by using a serialized form of auth token but it proved to be too complex (have to deal with token expiration issues for instance).

In your case, presumably the lookup can wait until all registration is done and an auth complete message is sent from Dart. At that point your LogPlugin would want to look up the AuthPlugin from the registry, right?

Nearly correct. As I mentioned above, LogPlugin does not actually need the AuthPlugin itself. So I would not want the plugin to deal with the registry directly but rather expect the auth object. So the callback on the app side is likely this:

CallbackPlugin.setupCallback("authComplete", () -> {
  LogPlugin logPlugin = lookupLogPlugin();
  AuthPlugin authPlugin = lookupAuthPlugin();
  logPlugin.configureLog(authPlugin.someObject());
});

[mehmetf]

@mravn-google I got this to work for Android. A couple of questions though:

This is what I had to do to grab the plugin:

CallbackPlugin plugin = valuePublishedByPlugin("io.flutter.plugins.callback.CallbackPlugin");

I had to lookup the id used here in the generated registrar. That's not ideal since generated code might change, which in turn will break app code. Could we add a lookup by type rather than id? That's much less likely to break. What do you think?

I also had to publish the plugin explicit in register with:

public static void registerWith(Registrar registrar) {
    CallbackPlugin plugin = new CallbackPlugin();
    final MethodChannel channel = new MethodChannel(registrar.messenger(), "callback");
    channel.setMethodCallHandler(plugin);
    registrar.publish(plugin);
  }

Is this expected? I figured the generated code would publish plugins automatically. I am not sure what the publish methodology is for. Could you please clarify?

[mravn-google]

Lookup by type requires caller to be compiled against that type, giving a client/plugin build dependency that can be problematic (perhaps especially so if the client is another plugin). Some plugins may wish to register only a callback like a java.util.Callable, with low coupling between plugin and client code. The string key is defined by concatenating IDs from the plugin's pubspec which are used also to autogenerate the plugin type name as it appears in GeneratedPluginRegistrant. So they must always match exactly.

Plugins are not required to publish an instance of themselves. In fact, many plugins may not even require an instance to be created at all (an example is the iOS part of url_launcher). So the plugin registry does not insist on receiving such an instance during registration.

[mehmetf]

That's fair. I had all kinds of concerns running through my head but at the end of the day, this use case is highly specific and I would imagine relatively rare. So I am OK modifying the log and auth plugins to publish themselves.

[mehmetf]

@mravn-google proposed a better alternative to a Callback plugin. Using MethodChannel directly within the app:

const MethodChannel('callback').invokeMethod('hello_world');

new MethodChannel("callback", getFlutterView()).setMethodCallHandler(new MethodCallHandler() {
  @Override
  public void onMethodCall(MethodCall call, Result result) {
    Log.w("CallbackSampleApp", "Hello World!");
  }
});

FlutterMethodChannel* callbackChannel =
  [FlutterMethodChannel
    methodChannelWithName:@"callback"
          binaryMessenger:(FlutterViewController*) window.rootViewController];

[callbackChannel setMethodCallHandler:^(FlutterMethodCall* call, FlutterResult result) {
  NSLog(@"Hello world!");
  result(nil);
}];

[adam-hurwitz]

@mehmetf - Regarding your last post with the better alternative solution using the MethodChannel. How is that method received on the native Android side?

[mehmetf]

@AdamSHurwitz see: https://flutter.io/platform-channels/

[adam-hurwitz]

Thanks for sharing the documentation @mehmetf Mehmet! This is a great sample for passing information from native Android/iOS to Flutter with the battery status in the *onMethodCall()* that is called from the Handler. However, if you wanted to receive information from Flutter to the native side, would you pass that info through the *MethodCall* object in *onMethodCall()*? A use case would be if you make a service request in Flutter and need to share the response on the native side to do something custom.