Skip to content

iOS plugin registry - #9818

Merged
mravn-google merged 6 commits into
flutter:masterfrom
mravn-google:ios_plugin_reg
May 9, 2017
Merged

mravn-google merged 6 commits into
flutter:masterfrom
mravn-google:ios_plugin_reg

Conversation

@mravn-google

@mravn-google mravn-google commented May 4, 2017 •

Copy link
Copy Markdown
Contributor

Add gearing between plugins and the application context defined by custom AppDelegate class supplied by the app author. Design constraints/goals:

  • Avoid forcing apps to use FlutterAppDelegate just to integrate plugins.
  • Avoid being in the way of advanced plugin/app interaction (use of gearing should not be mandatory).
  • Allow consuming simple/common plugins without forcing app author to write iOS-specific code.
  • Provide convenience for simple and common cases, including plugin-defined callbacks for common UIApplication lifecycle methods.
  • Make the "simple/common cases" an extensible notion without incurring breaking changes when extended.

iOS only in this PR. Accompanying flutter/engine PR: flutter-team-archive/engine#3645.
Android side: #9715

Partially addresses #9682 and #9161

@xster

xster commented May 5, 2017

Copy link
Copy Markdown
Member

Last minute out-of-nowhere no-context ambush ninja PR comment :)
Feel free to dismiss / discuss later / reassign.

We were looking at the contents of the user's source tree in #9826. Is it possible to have generated files be transient intermediaries in the build outputs (and consequently for iOS, perhaps let them be linked frameworks instead of user space source files)?

@mravn-google

Copy link
Copy Markdown
Contributor Author

@xster Sounds reasonable to me (SRTM?). I'll check with @jakobr-google if this is a small enough change that we can do it as part of this PR.

@xster

xster commented May 5, 2017

Copy link
Copy Markdown
Member

Cool, awesome!

@jakobr-google

Copy link
Copy Markdown
Contributor

I don't think moving the generated files is a small change, especially on iOS, and especially not if you're planning to have them in a separate framework. I would not mix it in with this change.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This instance will now be leaked :(

@chinmaygarde chinmaygarde May 5, 2017 •

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: I have tried to avoid new as much as possible and write the more verbose alloc - init incantation to be more explicit. If you don't mind, can we stick to using it here and elsewhere? If you have in any way a strong opinion for new however, then go ahead and stick to it. At this point, it is more of a personal preference really.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should use [[{{pluginClass}} alloc] init] here, as you say. Or make this an instance method (initWithRegistrar:?), and have the generated registry alloc - initWithRegistrar:.

We used [[{{pluginClass}} alloc] initWithController:] before.

@mravn-google mravn-google May 5, 2017 •

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't see a good reason to insist that instances can be created of all plugins? At least, we don't need that on the Java side.

The instance in question was supposed to have a life-span identical to the block that is given (via the MethodChannel) to the underlying BinaryMessenger---which means it should be kept alive until someone calls setMethodHandler(nil) on an identically named channel. As this doesn't happen, it will be alive for as long as the process runs. Which is as I intended. Am I holding it wrong?

Please note that this auto-generated code is part of the user plugin and is compiled with ARC. I cannot use autorelease or the like.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Has this file been through the formatter?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Has now. Thanks.

@mravn-google

Copy link
Copy Markdown
Contributor Author

@chinmaygarde PTAL

@mravn-google
mravn-google merged commit c1feee9 into flutter:master May 9, 2017
@mravn-google
mravn-google deleted the ios_plugin_reg branch December 18, 2017 21:27
@github-actions github-actions Bot locked as resolved and limited conversation to collaborators Aug 12, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants