Skip to content

Adopt the UIScene life cycle#25639

Draft
crazytonyli wants to merge 10 commits into
task/scene-api-handler-extractionfrom
task/scene-api-adoption
Draft

Adopt the UIScene life cycle#25639
crazytonyli wants to merge 10 commits into
task/scene-api-handler-extractionfrom
task/scene-api-adoption

Conversation

@crazytonyli

Copy link
Copy Markdown
Contributor

Note

This PR will be merged after #25638

AppAppearance.overrideAppearance() and the Home Screen quick action creation
both reach the app's window indirectly (the override style target and the 3D
Touch trait check). Under the scene life cycle the window does not exist until
the scene connects, so these no-opped when left in willFinishLaunching and
runStartupSequence. Move them into showInitialUI alongside the other
window-dependent launch steps.
The app Info.plist now declares a UIApplicationSceneManifest, so the unit
test host (WordPress.app running TestingAppDelegate) adopts the scene life
cycle but never connects a window scene, leaving the scene key window nil.
The mainWindow helper falls back to the app delegate's window in that case;
expose TestingAppDelegate.window via @objc so the Objective-C category can
read it.
Under the scene life cycle the window phase runs after both launch delegate
methods, so parsing UI-test flags there meant the launch sequence read empty
flags and -ui-test-reset-everything wiped the store after launch code had
already used it. Split the configurator into a process part that runs first in
willFinishLaunching and a window part applied when the window is created.
Under the scene life cycle, background launches (silent push, background URL
session wake) run without a window. The support-notification handler and the
logout branch of the account-changed handler both built UI through the window
manager, which cannot exist yet in that state. Both now skip the UI work; the
window phase builds the correct UI once a scene connects.
…nnect

The system can disconnect the app's scene in the background and reconnect it
later in the same process. showInitialUI previously re-ran the full UI
bootstrap on every connect: it created a fresh window while the window manager
stayed bound to the old one (leaving the new key window empty), re-registered
the Apple ID revocation observer, and replaced the authenticator and notice
presenter. The bootstrap now runs exactly once; later connects reattach the
existing window to the new scene. The window manager's missing-window
fatalError is also downgraded to an assertion with a recovery path, since
background launches make it reachable for any unguarded UI path.
sceneWillEnterForeground also fires right after the initial scene connect
during a cold launch, unlike the legacy applicationWillEnterForeground. That
extra call re-ran the feature flag refresh and the Jetpack migration
eligibility check (emitting its analytics event twice per launch). The handler
now skips the call that follows the initial connect; scene reconnects still
fall through since they are a real return from the background.
Use the canonical WordPressAppDelegate.shared accessor (which asserts main
thread access), route launch-time URL and user-activity entry points through
the same scene delegate methods that handle them at runtime, and drop the
launchOptions parameter from the startup sequence: under the scene life cycle
its only remaining consumer was a debug log line, since URL, shortcut, and
user-activity payloads arrive through UIScene.ConnectionOptions instead.
@dangermattic

Copy link
Copy Markdown
Collaborator
1 Message
📖 This PR is still a Draft: some checks will be skipped.

Generated by 🚫 Danger

@wpmobilebot

Copy link
Copy Markdown
Contributor
App Icon📲 You can test the changes from this Pull Request in WordPress by scanning the QR code below to install the corresponding build.
App NameWordPress
ConfigurationRelease-Alpha
Build Number32520
VersionPR #25639
Bundle IDorg.wordpress.alpha
Commit4a31f02
Installation URL2bfc8m4b8tt80
Automatticians: You can use our internal self-serve MC tool to give yourself access to those builds if needed.

@wpmobilebot

Copy link
Copy Markdown
Contributor
App Icon📲 You can test the changes from this Pull Request in Jetpack by scanning the QR code below to install the corresponding build.
App NameJetpack
ConfigurationRelease-Alpha
Build Number32520
VersionPR #25639
Bundle IDcom.jetpack.alpha
Commit4a31f02
Installation URL335sqaqbo9r9o
Automatticians: You can use our internal self-serve MC tool to give yourself access to those builds if needed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants