Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[macOS] Formalize FlutterViewController's initialization flow, and prohibit replacing #38981

Merged
merged 12 commits into from Jan 25, 2023

Conversation

dkwingsmt
Copy link
Contributor

@dkwingsmt dkwingsmt commented Jan 18, 2023

  1. This PR adds FlutterViewController.id, and formalizes how FlutterViewController is initialized by FlutterEngine:
  • When FlutterViewController is set to the engine, the engine calls FlutterViewController#attachToEngine:withId:.
  • When FlutterViewController is unset from the engine, the engine calls FlutterViewController#detachFromEngine.

This allows the ID to be generated by the engine.

  1. The default View ID is now 1 instead of 0. In this way, we can use 0 as an empty value, the value for FlutterViewController.id when the FVC is not attached to an engine. (IDs are meant to be opaque, and views should be a map, not an array anyway.)

  2. This PR moves almost all initialization code into FVC's CommonInit to ensure that all init path produces the expected result.

  3. With this PR, FlutterEngine no long supports replacing viewController (from non-null to a different non-null). Setting the view controller (from null to non-null) is intended to allow pre-warming an engine before displaying it in add-to-app, but replacing the view controller does not make much sense.

  • If the developer wants to persist the state of the view between different windows, they could just attach the view controller to different windows.
  • In fact, Flutter doesn't even have a way to create a FlutterViewController that is unattached to an engine. All initializers either require an engine or create an engine.

As a result, unit tests that used to create FVC with the wrong initializer are fixed.

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 and the C++, Objective-C, Java style guides.
  • I listed at least one issue that this PR fixes in the description above.
  • I added new tests to check the change I am making or feature I am adding, or Hixie said the PR is test-exempt. See testing the engine for instructions on writing and running engine tests.
  • I updated/added relevant documentation (doc comments with ///).
  • I signed the CLA.
  • All existing and new tests are passing.

If you need help, consider asking for advice on the #hackers-new channel on Discord.

@@ -18,7 +18,7 @@
* backward compatibility, single-view APIs will always operate the view with
* this ID. Also, the first view assigned to the engine will also have this ID.
*/
constexpr uint64_t kFlutterDefaultViewId = 0;
constexpr uint64_t kFlutterDefaultViewId = 1;
Copy link
Member

Choose a reason for hiding this comment

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

Just so this comment isn't lost: #38855 (comment)

Consider double-checking with @goderbauer that the framework does not have any expectations that the default view has an ID of 0.

Copy link
Member

Choose a reason for hiding this comment

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

The framework makes no assumption about the value of the id. Why does this have to change from 0 to 1, though?

Copy link
Member

@loic-sharma loic-sharma left a comment

Choose a reason for hiding this comment

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

LGTM, but please get sign-off from folks that are more familiar with the macOS embedder

Copy link
Contributor

@a-wallen a-wallen left a comment

Choose a reason for hiding this comment

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

LGTM

@dkwingsmt dkwingsmt self-assigned this Jan 19, 2023
@@ -18,7 +18,7 @@
* backward compatibility, single-view APIs will always operate the view with
* this ID. Also, the first view assigned to the engine will also have this ID.
*/
constexpr uint64_t kFlutterDefaultViewId = 0;
constexpr uint64_t kFlutterDefaultViewId = 1;
Copy link
Member

Choose a reason for hiding this comment

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

The framework makes no assumption about the value of the id. Why does this have to change from 0 to 1, though?

/**
* The identifier for this view controller.
*
* The ID is assigned when the view controller is added to FlutterEngine.
Copy link
Member

Choose a reason for hiding this comment

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

Maybe expand on this, like:

Suggested change
* The ID is assigned when the view controller is added to FlutterEngine.
* The ID is assigned when the view controller is assigned to the
* FlutterEngine.viewController property.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The mechanism is a little more complicated than this, so I decided to explain everything in FlutterViewController's doc. Can you take a look?

@dkwingsmt
Copy link
Contributor Author

@cbracken @goderbauer I should have addressed all your comments. Can you take another look?

Copy link
Member

@goderbauer goderbauer left a comment

Choose a reason for hiding this comment

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

LGTM

* Some single-view APIs will eventually be replaced by their multi-view
* variant. During the deprecation period, the single-view APIs will coexist with
* and work with the multi-view APIs as if the other views don't exist. For
* backward compatibility, single-view APIs will always operate the view with
Copy link
Member

Choose a reason for hiding this comment

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

nit: operate on (or something like that)?

@dkwingsmt dkwingsmt merged commit e3b2782 into flutter:main Jan 25, 2023
dkwingsmt added a commit that referenced this pull request Jan 25, 2023
dkwingsmt added a commit that referenced this pull request Jan 25, 2023
dkwingsmt added a commit to dkwingsmt/engine that referenced this pull request Jan 25, 2023
auto-submit bot pushed a commit that referenced this pull request Jan 26, 2023
…, and prohibit replacing" (#39145)

* Revert "Revert "[macOS] Formalize FlutterViewController's initialization flow, and prohibit replacing (#38981)" (#39144)"

This reverts commit 36db005.

* Fix?
engine-flutter-autoroll added a commit to engine-flutter-autoroll/flutter that referenced this pull request Jan 26, 2023
auto-submit bot pushed a commit to flutter/flutter that referenced this pull request Jan 26, 2023
…119208)

* e3b278239 [macOS] Formalize FlutterViewController's initialization flow, and prohibit replacing (flutter/engine#38981)

* 36db005dd Revert "[macOS] Formalize FlutterViewController's initialization flow, and prohibit replacing (#38981)" (flutter/engine#39144)

* a20609120 Roll buildroot (flutter/engine#39141)

* 8f1e5dc1b Reland "[macOS] Formalize FlutterViewController's initialization flow, and prohibit replacing" (flutter/engine#39145)
@dkwingsmt dkwingsmt deleted the add-fvc-id branch June 30, 2023 09:17
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Done
5 participants