)]}'
{
  "commit": "e3ed63ceaed0c75d50844de8f7be8b9b543d72e1",
  "tree": "0d4e1b748e3cd0c673e35dffcdf03a3c3deedd29",
  "parents": [
    "43be3c52e673d780b76ad6fcd1c5f450a25e71fd"
  ],
  "author": {
    "name": "LongCatIsLooong",
    "email": "31859944+LongCatIsLooong@users.noreply.github.com",
    "time": "Wed Sep 03 18:32:32 2025 -0700"
  },
  "committer": {
    "name": "dart-internal-monorepo",
    "email": "dart-internal-monorepo@dart-ci-internal.iam.gserviceaccount.com",
    "time": "Wed Sep 03 19:23:40 2025 -0700"
  },
  "message": "Add a `viewController` property to the ios/macOS `FlutterPluginRegistrar` protocol  (#174168)\n\n#104117\n\nAdds a `viewController` (per\nhttps://github.com/flutter/flutter/issues/104117#issuecomment-3114772381,\npresumably because iOS plugins want to presenting new view controllers)\ngetter that makes the single-view assumption. ~This is a method instead\nof a weak + readonly property like the macOS registrar protocol because\nexisting getters are also methods, e.g.,~\n```objc\n- (NSObject\u003cFlutterBinaryMessenger\u003e*)messenger;\n- (NSObject\u003cFlutterTextureRegistry\u003e*)textures;\n```\n\n~Unfortunately swift callers will have to use a preprocess macro and add\ndifferent code paths for macOS and iOS.~\n\n#### Single view assumption\n\nI\u0027ve considered adding a `- (nullable\nUIViewController*)viewControllerForViewID: ViewIDType;` method but that\nwill force plugins to make breaking changes in order to migrate off of\nthe deprecated `keyWindow` property. Take the text input plugin as an\nexample, it has to add a `viewID` argument to the `setTextInputClient`\ncall when establishing a new text input connection, so the text input\nplugin knows which view hierarchy to add the text input view to. It is\nunclear to me whether more `FlutterPluginRegistrar` changes are needed\nto completely get rid of the single-view assumption in the protocol (the\nviews `FlutterPlatformViewFactory` creates are always added as subviews\nto `flutterView` so I guess that interface may have to change in the\nfuture? According to according to [Flutter’s multi-window\nstatus](https://docs.google.com/document/d/13E27tD8_9f6lDgwg3MpGNTV8XIRCZH3ByI-t9kI9IUM/edit?tab\u003dt.0#heading\u003dh.8lxwn1tiky70),\nonly a `viewForIdentifier` method will be added to registrar), so IMO it\nwould be a better experience to not introduce the `viewID` concept right\nnow and force plugins to make break changes, since they may have to make\nmore breaking changes in the future.\n\nAlternatively, we could also ignore the `viewID` args for now and always\nreturn the view controller of the implicit view in the implementation,\nso that plugin authors can use made-up view IDs to get the implicit view\ncontroller. But that\u0027s going to make future multiview migrations\ndifficult since the compiler won\u0027t be able to catch unmigrated code if\nthe plugin is using a bogus view ID.\n\n##  Pre-launch Checklist\n\n- [ ] I read the [Contributor Guide] and followed the process outlined\nthere for submitting PRs.\n- [ ] I read the [Tree Hygiene] wiki page, which explains my\nresponsibilities.\n- [ ] I read and followed the [Flutter Style Guide], including [Features\nwe expect every widget to implement].\n- [ ] I signed the [CLA].\n- [ ] I listed at least one issue that this PR fixes in the description\nabove.\n- [ ] I updated/added relevant documentation (doc comments with `///`).\n- [ ] I added new tests to check the change I am making, or this PR is\n[test-exempt].\n- [ ] I followed the [breaking change policy] and added [Data Driven\nFixes] where supported.\n- [ ] All existing and new tests are passing.\n\nIf you need help, consider asking for advice on the #hackers-new channel\non [Discord].\n\n**Note**: The Flutter team is currently trialing the use of [Gemini Code\nAssist for\nGitHub](https://developers.google.com/gemini-code-assist/docs/review-github-code).\nComments from the `gemini-code-assist` bot should not be taken as\nauthoritative feedback from the Flutter team. If you find its comments\nuseful you can update your code accordingly, but if you are unsure or\ndisagree with the feedback, please feel free to wait for a Flutter team\nmember\u0027s review for guidance on which automated comments should be\naddressed.\n\n\u003c!-- Links --\u003e\n[Contributor Guide]:\nhttps://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md#overview\n[Tree Hygiene]:\nhttps://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md\n[test-exempt]:\nhttps://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md#tests\n[Flutter Style Guide]:\nhttps://github.com/flutter/flutter/blob/main/docs/contributing/Style-guide-for-Flutter-repo.md\n[Features we expect every widget to implement]:\nhttps://github.com/flutter/flutter/blob/main/docs/contributing/Style-guide-for-Flutter-repo.md#features-we-expect-every-widget-to-implement\n[CLA]: https://cla.developers.google.com/\n[flutter/tests]: https://github.com/flutter/tests\n[breaking change policy]:\nhttps://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md#handling-breaking-changes\n[Discord]:\nhttps://github.com/flutter/flutter/blob/main/docs/contributing/Chat.md\n[Data Driven Fixes]:\nhttps://github.com/flutter/flutter/blob/main/docs/contributing/Data-driven-Fixes.md\nhttps://dart.googlesource.com/external/github.com/flutter/flutter/+/251f4a8d5b9f2577212b94379c1711dbdf4b7a7a\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "478c314137794e814bfe563eaf960c101851fd7c",
      "old_mode": 33188,
      "old_path": "DEPS",
      "new_id": "67dcbc16dcd6988d6a65003f7b5039e35b10c0a8",
      "new_mode": 33188,
      "new_path": "DEPS"
    },
    {
      "type": "modify",
      "old_id": "b0b878a165252b1b6eb0486ccaf6f8a3e4bf2465",
      "old_mode": 33188,
      "old_path": "commits.json",
      "new_id": "b9e536b994e3026f7eb6b80417202419bd1e5444",
      "new_mode": 33188,
      "new_path": "commits.json"
    }
  ]
}