mirror of
https://github.com/flutter/flutter.git
synced 2026-02-20 02:29:02 +08:00
26037dff87
fixes https://github.com/flutter/flutter/issues/158399 old pr https://github.com/flutter/engine/pull/56691 previously the only correct way to enable semantics is that ios embedding receive signal from native OS, it call SetSemanticsEnabled to shell and then to dart to enable semantics tree generation. If for some reason framework decide to enable semantics first, e.g. through SemanticsBinding.instance.ensureSemantics(typically due to integration test or ci that wants to test semantics), the update will be dropped in shell. Even if it later on receive signal from native OS to turn on semantics, it can't construct the complete accessibility tree in embedding because the updatesemantics sends diff update and previous updates are gone forever. It will end up in a broken state. This pr changes so that the only source of truth will be in the framework side. When framework starts generating the the semantics tree, it will call SetSemanticsTreeEnabled through dart:ui, and the embedding needs to prepare itself to accept semantics update after receiving the message. This however require some refactoring on iOS embedding because it will only create a11y bridge when receiving OS notification when assitive technologies turns on. This requires three phase transition add an empty dart:ui API setSemanticsTreeEnabled makes framework calls the empty API. merge this pr with actual implementation of setSemanticsTreeEnabled I will do the android part in a separate pr ## 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]. <!-- 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
iOS host app
Used by the module_test_ios.dart device lab test.
iOS host app for a Flutter module created using
$ flutter create -t module hello
and placed in a sibling folder to (a clone of) the host app.
flutterapp/lib/marquee.dart and flutterapp/lib/main.dart
must be copied into the new module lib for platform unit tests
to pass.
This application demonstrates some basic functionality for Add2App, along with a native iOS ViewController as a baseline and to demonstrate interaction.
- A regular iOS view controller (UIViewController), similar to the default
flutter createtemplate (NativeViewController.m). - A FlutterViewController subclass that takes over the full screen. Demos showing this both from a cold/fresh engine state and a warm engine state (FullScreenViewController.m).
- A demo of pushing a FlutterViewController on as a child view.
- A demo of showing both the native and the Flutter views using a platform channel to interact with each other (HybridViewController.m).
- A demo of showing two FlutterViewControllers simultaneously (DualViewController.m).
A few key things are tested here (FlutterUITests.m):
- The ability to pre-warm the engine and attach/detach a ViewController from it.
- The ability to use platform channels to communicate between views.
- The ability to simultaneously run two instances of the engine.