Repository navigation
Export a base class for Objective C method channel plugins #9161
Description
Basically every plugin we've written thus far (internally in Google) looks like the following:
Seems like there's an opportunity to remove a lot of boilerplate by providing a base class to do this basic wiring.
@interface FLTExamplePlugin : NSObject
@property(strong, nonatomic, readonly) FlutterViewController *controller;
- (instancetype)init NS_UNAVAILABLE;
- (instancetype)initWithController:(FlutterViewController *)controller NS_DESIGNATED_INITIALIZER;
@end
@implementation FLTExamplePlugin {
FlutterMethodChannel *_channel;
}
- (instancetype)initWithController:(FlutterViewController *)controller {
if (self = [super init]) {
_controller = controller;
_channel =
[FlutterMethodChannel methodChannelNamed:CHANNEL_NAME
binaryMessenger:controller
codec:[FlutterStandardMethodCodec sharedInstance]];
__unsafe_unretained typeof(self) weakSelf = self;
[_channel setMethodCallHandler:^(FlutterMethodCall *call, FlutterResultReceiver result) {
[weakSelf handleMethod:call sendResultTo:result];
}];
}
return self;
}
- (void)dealloc {
[_channel setMethodCallHandler:nil];
_channel = nil;
}
@end
Activity
tvolkert commentedon Apr 3, 2017
Actually, it's better to have the method be:
And the base class implementation can just respond with a method not found error.
mravn-google commentedon Apr 4, 2017
Things to consider:
FlutterMethodCallHandlerprotocol rather than atypedefd callback?_Nullableand_Nonnullannotations.pubspec.yamlfile without any need to touch ObjC/Swift or Android code at all. That requires plugin initialization to be done consistently across the board, making it amenable to code generation duringflutter build.tvolkert commentedon Apr 5, 2017
Yeah, maybe introducing a
FlutterMethodCallHandlerDelegateprotocol and having the interface be something the following would make sense:mravn-google commentedon Apr 5, 2017
The delegate could be a property of
FlutterMethodChannel, I guess, as an alternative to having theFlutterPluginbase class at all. That would mean we have at least three options:delegateproperty onFlutterMethodChannel.I have way too little experience with ObjC to know what developers would expect or prefer. Same goes for Swift by the way. @chinmaygarde, do you have an opinion?
tvolkert commentedon Apr 5, 2017
/cc @gavindoughtie as an affluent iOS developer for his thoughts. Gavin, the discussion is about the best plugin API on the ObjC (and Swift when we add that) side of things.
gavindoughtie commentedon Apr 5, 2017
Oh, I wish I were an affluent iOS developer... :-P
I'd definitely lean towards defining a couple of delegate protocols (one for the plugin, one for whatever Flutter hands the plugin) as the actual binding contract.
Then I'd do a BasePlugin that implements the protocol, and then most plugins would just extend that by overriding a couple of methods (like "createViewController" or "handleMethod").
This way you keep the requirements minimal while still making it easy for more trivial plugins.
tvolkert commentedon Apr 5, 2017
+1 to a base class that implements one or more protocols.
mravn-google commentedon May 9, 2017
Fixed by #3645.
tvolkert commentedon May 9, 2017
flutter-team-archive/engine#3645 rather?
mravn-google commentedon May 9, 2017
Yes, thanks.
github-actions commentedon Sep 5, 2021
This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of
flutter doctor -vand a minimal reproduction of the issue.