<!-- start_original_pr_link -->
Reverts: flutter/flutter#169276
<!-- end_original_pr_link -->
<!-- start_initiating_author -->
Initiated by: vashworth
<!-- end_initiating_author -->
<!-- start_revert_reason -->
Reason for reverting: Causing google testing failures
<!-- end_revert_reason -->
<!-- start_original_pr_author -->
Original PR Author: gaaclarke
<!-- end_original_pr_author -->
<!-- start_reviewers -->
Reviewed By: {vashworth}
<!-- end_reviewers -->
<!-- start_revert_body -->
This change reverts the following previous change:
## **BREAKING CHANGE**
Adopting Apple's UISceneDelegate protocol shifts the initialization
order of apps. For the common cases we've made sure they will work
without change. The one case that will require a change is any app that
in `-[UIApplicateDelegate didFinishLaunchingWithOptions:]` assumes that
`UIApplicationDelegate.window.rootViewController` is a
`FlutterViewController` instance. This is sometimes done to register
platform channels directly on the `FlutterViewController`. Instead users
should use the `FlutterPluginRegistry` API's to create platform channels
in `-[UIApplicateDelegate didFinishLaunchingWithOptions:]`, like
`FlutterPlugin`s do.
An example can be seen here:
https://github.com/flutter/flutter/pull/168914/files#diff-9f59c5248b58124beca7e290a57646023cda3ca024607092c6c6932606ce16ee
In extreme cases, like bespoke test harnesses, the startup logic can be
moved to `-[FlutterViewController awakeFromNib]` in a
FlutterViewController subclass.
An example can be seen here:
https://github.com/flutter/flutter/pull/169276/files#diff-dbe39c23a0a380447b90b7559a878dae8564616e0875c4ef0d9e99e02b91adac
## Changes since revert
I changed the init in `//dev/integration_tests/external_textures` from
the UIApplicationDelegate to the FlutterViewController's awakeFromNib.
This is a more appropriate place for initialization post-UISceneDelegate
since it avoids the launch engine altogether. I tried avoiding to make
the big change to prove we could do a small change to migrate that
project. I don't think this big refactor is indicative of what users
will experience. There was a timing assumption in the integration test
that required not using the launch engine at all.
## Description
fixes: https://github.com/flutter/flutter/issues/167267
design doc:
https://docs.google.com/document/d/1ZfcQOs-UKRa9jsFG84-MTFeibZTLKCvPQLxF2eskx44/edit?tab=t.0
relands https://github.com/flutter/flutter/pull/168396
relands https://github.com/flutter/flutter/pull/168914
## Pre-launch Checklist
- [x] I read the [Contributor Guide] and followed the process outlined
there for submitting PRs.
- [x] I read the [Tree Hygiene] wiki page, which explains my
responsibilities.
- [x] I read and followed the [Flutter Style Guide], including [Features
we expect every widget to implement].
- [x] I signed the [CLA].
- [x] I listed at least one issue that this PR fixes in the description
above.
- [x] I updated/added relevant documentation (doc comments with `///`).
- [x] I added new tests to check the change I am making, or this PR is
[test-exempt].
- [x] I followed the [breaking change policy] and added [Data Driven
Fixes] where supported.
- [x] All existing and new tests are passing.
<!-- end_revert_body -->
Co-authored-by: auto-submit[bot] <flutter-engprod-team@google.com>
## **BREAKING CHANGE**
Adopting Apple's UISceneDelegate protocol shifts the initialization
order of apps. For the common cases we've made sure they will work
without change. The one case that will require a change is any app that
in `-[UIApplicateDelegate didFinishLaunchingWithOptions:]` assumes that
`UIApplicationDelegate.window.rootViewController` is a
`FlutterViewController` instance. This is sometimes done to register
platform channels directly on the `FlutterViewController`. Instead users
should use the `FlutterPluginRegistry` API's to create platform channels
in `-[UIApplicateDelegate didFinishLaunchingWithOptions:]`, like
`FlutterPlugin`s do.
An example can be seen here:
https://github.com/flutter/flutter/pull/168914/files#diff-9f59c5248b58124beca7e290a57646023cda3ca024607092c6c6932606ce16ee
In extreme cases, like bespoke test harnesses, the startup logic can be
moved to `-[FlutterViewController awakeFromNib]` in a
FlutterViewController subclass.
An example can be seen here:
https://github.com/flutter/flutter/pull/169276/files#diff-dbe39c23a0a380447b90b7559a878dae8564616e0875c4ef0d9e99e02b91adac
## Changes since revert
I changed the init in `//dev/integration_tests/external_textures` from
the UIApplicationDelegate to the FlutterViewController's awakeFromNib.
This is a more appropriate place for initialization post-UISceneDelegate
since it avoids the launch engine altogether. I tried avoiding to make
the big change to prove we could do a small change to migrate that
project. I don't think this big refactor is indicative of what users
will experience. There was a timing assumption in the integration test
that required not using the launch engine at all.
## Description
fixes: https://github.com/flutter/flutter/issues/167267
design doc:
https://docs.google.com/document/d/1ZfcQOs-UKRa9jsFG84-MTFeibZTLKCvPQLxF2eskx44/edit?tab=t.0
relands https://github.com/flutter/flutter/pull/168396
relands https://github.com/flutter/flutter/pull/168914
## Pre-launch Checklist
- [x] I read the [Contributor Guide] and followed the process outlined
there for submitting PRs.
- [x] I read the [Tree Hygiene] wiki page, which explains my
responsibilities.
- [x] I read and followed the [Flutter Style Guide], including [Features
we expect every widget to implement].
- [x] I signed the [CLA].
- [x] I listed at least one issue that this PR fixes in the description
above.
- [x] I updated/added relevant documentation (doc comments with `///`).
- [x] I added new tests to check the change I am making, or this PR is
[test-exempt].
- [x] I followed the [breaking change policy] and added [Data Driven
Fixes] where supported.
- [x] All existing and new tests are passing.
<!-- start_original_pr_link -->
Reverts: flutter/flutter#168914
<!-- end_original_pr_link -->
<!-- start_initiating_author -->
Initiated by: gaaclarke
<!-- end_initiating_author -->
<!-- start_revert_reason -->
Reason for reverting:
https://ci.chromium.org/ui/p/flutter/builders/prod/Mac_ios%20external_ui_integration_test_ios/16792/overview
The external texture integration test is failing. Running the host app
appeared to work but one of the driver asserts isn't working.
<!-- end_revert_reason -->
<!-- start_original_pr_author -->
Original PR Author: gaaclarke
<!-- end_original_pr_author -->
<!-- start_reviewers -->
Reviewed By: {vashworth}
<!-- end_reviewers -->
<!-- start_revert_body -->
This change reverts the following previous change:
## **BREAKING CHANGE**
Adopting Apple's UISceneDelegate protocol shifts the initialization
order of apps. For the common cases we've made sure they will work
without change. The one case that will require a change is any app that
in `-[UIApplicateDelegate didFinishLaunchingWithOptions:]` assumes that
`UIApplicationDelegate.window.rootViewController` is a
`FlutterViewController` instance. This is sometimes done to register
platform channels directly on the `FlutterViewController`. Instead users
should use the `FlutterPluginRegistry` API's to create platform channels
in `-[UIApplicateDelegate didFinishLaunchingWithOptions:]`, like
`FlutterPlugin`s do.
An example can be seen here:
https://github.com/flutter/flutter/pull/168914/files#diff-9f59c5248b58124beca7e290a57646023cda3ca024607092c6c6932606ce16ee
## Changes since revert
Device lab tests have been migrated to using the FlutterPlugin API for
creating platform channels at process launch.
## Description
fixes: https://github.com/flutter/flutter/issues/167267
design doc:
https://docs.google.com/document/d/1ZfcQOs-UKRa9jsFG84-MTFeibZTLKCvPQLxF2eskx44/edit?tab=t.0
relands https://github.com/flutter/flutter/pull/168396
## Pre-launch Checklist
- [x] I read the [Contributor Guide] and followed the process outlined
there for submitting PRs.
- [x] I read the [Tree Hygiene] wiki page, which explains my
responsibilities.
- [x] I read and followed the [Flutter Style Guide], including [Features
we expect every widget to implement].
- [x] I signed the [CLA].
- [x] I listed at least one issue that this PR fixes in the description
above.
- [x] I updated/added relevant documentation (doc comments with `///`).
- [x] I added new tests to check the change I am making, or this PR is
[test-exempt].
- [x] I followed the [breaking change policy] and added [Data Driven
Fixes] where supported.
- [x] All existing and new tests are passing.
<!-- end_revert_body -->
Co-authored-by: auto-submit[bot] <flutter-engprod-team@google.com>
## **BREAKING CHANGE**
Adopting Apple's UISceneDelegate protocol shifts the initialization
order of apps. For the common cases we've made sure they will work
without change. The one case that will require a change is any app that
in `-[UIApplicateDelegate didFinishLaunchingWithOptions:]` assumes that
`UIApplicationDelegate.window.rootViewController` is a
`FlutterViewController` instance. This is sometimes done to register
platform channels directly on the `FlutterViewController`. Instead users
should use the `FlutterPluginRegistry` API's to create platform channels
in `-[UIApplicateDelegate didFinishLaunchingWithOptions:]`, like
`FlutterPlugin`s do.
An example can be seen here:
https://github.com/flutter/flutter/pull/168914/files#diff-9f59c5248b58124beca7e290a57646023cda3ca024607092c6c6932606ce16ee
## Changes since revert
Device lab tests have been migrated to using the FlutterPlugin API for
creating platform channels at process launch.
## Description
fixes: https://github.com/flutter/flutter/issues/167267
design doc:
https://docs.google.com/document/d/1ZfcQOs-UKRa9jsFG84-MTFeibZTLKCvPQLxF2eskx44/edit?tab=t.0
relands https://github.com/flutter/flutter/pull/168396
## Pre-launch Checklist
- [x] I read the [Contributor Guide] and followed the process outlined
there for submitting PRs.
- [x] I read the [Tree Hygiene] wiki page, which explains my
responsibilities.
- [x] I read and followed the [Flutter Style Guide], including [Features
we expect every widget to implement].
- [x] I signed the [CLA].
- [x] I listed at least one issue that this PR fixes in the description
above.
- [x] I updated/added relevant documentation (doc comments with `///`).
- [x] I added new tests to check the change I am making, or this PR is
[test-exempt].
- [x] I followed the [breaking change policy] and added [Data Driven
Fixes] where supported.
- [x] All existing and new tests are passing.
Reverts flutter/flutter#142062
Initiated by: eliasyishak
This change reverts the following previous change:
Original Description:
This PR makes no _behavioral_ changes to executed code, and instead focuses on organization and naming:
1. Almost[^1] anything named `external_ui` is renamed `external_textures`
1. Extended the README to explain the intent of the test, as well as how to run it
1. Renamed `main.dart` and `main_test.dart` to `frame_rate_main.dart` and `frame_rate_test.dart` (we'll add more)
1. Did some refactoring of the test to make it more obvious what is being asserted (i.e. `widgetBuilds` and friends)
Given how complex (and in-flux) this directory is, I'm also requesting either John, Jonah or I review any changes.
[^1]: Except the name of the `.ci.yaml` task, i.e. `name: Linux_pixel_7pro external_ui_integration_test` because I'm apparently not able to change that without creating a new task as `bringup: true` and playing a bit of a dance. Maybe that's worth doing though (in future PRs)?
This PR makes no _behavioral_ changes to executed code, and instead
focuses on organization and naming:
1. Almost[^1] anything named `external_ui` is renamed
`external_textures`
1. Extended the README to explain the intent of the test, as well as how
to run it
1. Renamed `main.dart` and `main_test.dart` to `frame_rate_main.dart`
and `frame_rate_test.dart` (we'll add more)
1. Did some refactoring of the test to make it more obvious what is
being asserted (i.e. `widgetBuilds` and friends)
Given how complex (and in-flux) this directory is, I'm also requesting
either John, Jonah or I review any changes.
[^1]: Except the name of the `.ci.yaml` task, i.e. `name:
Linux_pixel_7pro external_ui_integration_test` because I'm apparently
not able to change that without creating a new task as `bringup: true`
and playing a bit of a dance. Maybe that's worth doing though (in future
PRs)?
