Plugin registration has been decoupled from direct use of FlutterXxx application entry points, allowing plugins to be consumed also by apps that for whatever reason cannot extend the provided base classes (FlutterActivity on Android, FlutterAppDelegate on iOS).
You may need to change your code, if you have been using a recent project template for writing plugins or apps that consume plugins.
Three roles have been defined: a plugin registry for collecting plugin registrations, a registrar to provide context for a single plugin's setup and registrations, and a registrant representing the plugins being registered. The registry and registrar are interfaces/protocols implemented by FlutterActivity/FlutterAppDelegate and friends, but app authors can provide their own implementations, if needed. A registrant aggregating declared plugins is auto-generated, as before, but is now called GeneratedPluginRegistrant.
What to change
If your app consumes plugins, your MainActivity/AppDelegate should involve a call to GeneratedPluginRegistrant to accept their registrations:
Android:
public class MainActivity extends FlutterActivity {
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
GeneratedPluginRegistrant.registerWith(this);
}
}
iOS:
@implementation AppDelegate
- (BOOL)application:(UIApplication*)application didFinishLaunchingWithOptions:(NSDictionary*)launchOptions {
[GeneratedPluginRegistrant registerWithRegistry:self];
return [super application:application
didFinishLaunchingWithOptions:launchOptions];
}
In addition, if you overwrite any of the Activity/UIApplicationDelegate lifecycle methods now implemented by FlutterActivity/FlutterAppDelegate, you should invoke the super method to forward such calls to registered plugins.
If you are writing a plugin, it should involve a static method accepting a registrar:
Android example:
public class MyPlugin implements MethodCallHandler, NewIntentListener { public static void registerWith(Registrar registrar) {
// Set up MyPlugin to receive method calls and Intents
// using the registrar
}
@Override
public void onMethodCall(MethodCall call, Result result) {...}
@Override
public bool onNewIntent(Intent intent) {...}
}
iOS example:
@implementation MyPlugin
+ (void)registerWithRegistrar:(NSObject<FlutterPluginRegistrar>*)registrar {
// Set up MyPlugin to receive method calls and app lifecycle
// events using the registrar
}
- (void)handleMethodCall:(FlutterMethodCall*)call result:(FlutterResult)result { ... }
- (void)applicationWillEnterForeground:(UIApplication*)application { ... }@end
Rationale for change
Published plugins need a stable API against which to register themselves. App developers need flexibility in how their app is initialized and how plugins take part in that. The registry/registrar roles provides an interface between the two. Later additions to the registrar interface should be expected, allowing plugins to do more. The implementations provided in FlutterActivity/FlutterAppDelegate will follow suit.
Please do not hesitate to contact me, if you need any help adjusting your code to this change.