-
-
Notifications
You must be signed in to change notification settings - Fork 2.3k
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
Make Classic ApplicationLifetime API a bit more reliable #14267
Conversation
38c9e96
to
e32fdb1
Compare
You can test this PR using the following package version. |
You can test this PR using the following package version. |
* Add StartWithClassicDesktopLifetime overload with a lifetime builder * Disallow changing Application.ApplicationLifetime after setup was completed * Avoid static dependency on a singleton lifetime * Introduce SetupWithClassicDesktopLifetime method * Move more logic from Start method to Setup * Add docs * Avoid public API changes * Fix tests * Repalce locator usage with `.UseLifetimeOverride` --------- Co-authored-by: Benedikt Stebner <[email protected]>
@maxkatz6 regarding this:
How can I get the (obsolete) |
@danipen added this documentation page: https://docs.avaloniaui.net/docs/concepts/services/activatable-lifetime#handling-uri-activation |
Got it! Thank you so much. |
What does the pull request do?
I recommend reviewing this PR commit by commit, as there are multiple independent changes.
s_activeLifetime
. Instead lifetime should subscribe on window events after it was set-up, and not when it was constructed. And also - unsubscribe from these events.Breaking changes
Application.ApplicationLifetime cannot be set after application was started. It will throw a runtime error.
Since this never was supported nor properly handled, I wouldn't consider it a blocker for backporting.
Obsoletions / Deprecations
Application.UrlsOpened is obsolete - use IActivatableApplicationLifetime.