mirror of
https://github.com/flutter/flutter.git
synced 2026-02-20 02:29:02 +08:00
251f4a8d5b
#104117 Adds a `viewController` (per https://github.com/flutter/flutter/issues/104117#issuecomment-3114772381, presumably because iOS plugins want to presenting new view controllers) getter that makes the single-view assumption. ~This is a method instead of a weak + readonly property like the macOS registrar protocol because existing getters are also methods, e.g.,~ ```objc - (NSObject<FlutterBinaryMessenger>*)messenger; - (NSObject<FlutterTextureRegistry>*)textures; ``` ~Unfortunately swift callers will have to use a preprocess macro and add different code paths for macOS and iOS.~ #### Single view assumption I've considered adding a `- (nullable UIViewController*)viewControllerForViewID: ViewIDType;` method but that will force plugins to make breaking changes in order to migrate off of the deprecated `keyWindow` property. Take the text input plugin as an example, it has to add a `viewID` argument to the `setTextInputClient` call when establishing a new text input connection, so the text input plugin knows which view hierarchy to add the text input view to. It is unclear to me whether more `FlutterPluginRegistrar` changes are needed to completely get rid of the single-view assumption in the protocol (the views `FlutterPlatformViewFactory` creates are always added as subviews to `flutterView` so I guess that interface may have to change in the future? According to according to [Flutter’s multi-window status](https://docs.google.com/document/d/13E27tD8_9f6lDgwg3MpGNTV8XIRCZH3ByI-t9kI9IUM/edit?tab=t.0#heading=h.8lxwn1tiky70), only a `viewForIdentifier` method will be added to registrar), so IMO it would be a better experience to not introduce the `viewID` concept right now and force plugins to make break changes, since they may have to make more breaking changes in the future. Alternatively, we could also ignore the `viewID` args for now and always return the view controller of the implicit view in the implementation, so that plugin authors can use made-up view IDs to get the implicit view controller. But that's going to make future multiview migrations difficult since the compiler won't be able to catch unmigrated code if the plugin is using a bogus view ID. ## Pre-launch Checklist - [ ] I read the [Contributor Guide] and followed the process outlined there for submitting PRs. - [ ] I read the [Tree Hygiene] wiki page, which explains my responsibilities. - [ ] I read and followed the [Flutter Style Guide], including [Features we expect every widget to implement]. - [ ] I signed the [CLA]. - [ ] I listed at least one issue that this PR fixes in the description above. - [ ] I updated/added relevant documentation (doc comments with `///`). - [ ] I added new tests to check the change I am making, or this PR is [test-exempt]. - [ ] I followed the [breaking change policy] and added [Data Driven Fixes] where supported. - [ ] All existing and new tests are passing. If you need help, consider asking for advice on the #hackers-new channel on [Discord]. **Note**: The Flutter team is currently trialing the use of [Gemini Code Assist for GitHub](https://developers.google.com/gemini-code-assist/docs/review-github-code). Comments from the `gemini-code-assist` bot should not be taken as authoritative feedback from the Flutter team. If you find its comments useful you can update your code accordingly, but if you are unsure or disagree with the feedback, please feel free to wait for a Flutter team member's review for guidance on which automated comments should be addressed. <!-- Links --> [Contributor Guide]: https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md#overview [Tree Hygiene]: https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md [test-exempt]: https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md#tests [Flutter Style Guide]: https://github.com/flutter/flutter/blob/main/docs/contributing/Style-guide-for-Flutter-repo.md [Features we expect every widget to implement]: https://github.com/flutter/flutter/blob/main/docs/contributing/Style-guide-for-Flutter-repo.md#features-we-expect-every-widget-to-implement [CLA]: https://cla.developers.google.com/ [flutter/tests]: https://github.com/flutter/tests [breaking change policy]: https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md#handling-breaking-changes [Discord]: https://github.com/flutter/flutter/blob/main/docs/contributing/Chat.md [Data Driven Fixes]: https://github.com/flutter/flutter/blob/main/docs/contributing/Data-driven-Fixes.md
Flutter Engine
Setting up the Engine development environment
See here
gclient bootstrap
Flutter engine uses gclient to manage dependencies.
If you've already cloned the flutter repository: