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

Obsolete setting mainpage via application #23692

Merged
merged 16 commits into from
Jul 23, 2024
Merged

Obsolete setting mainpage via application #23692

merged 16 commits into from
Jul 23, 2024

Conversation

PureWeen
Copy link
Member

@PureWeen PureWeen commented Jul 18, 2024

Description of Change

  • Obsolete Application.Current.MainPage (set/get)
  • change all templates to use the override CreateWindow vs setting the MainPage on Application
  • Provide guidance (docs and obsolete message) indicating how users can achieve the same thing
    • Application.Current.MainPage can become Application.Current.Windows[0].Page
    • If you're on an element that's attached to the window you can do "this.Window"
  • Make the following extension method public so developers can easily get to the IWindow from the platform UIWindow. Android and WinUI already have public APIs for this
    public static IWindow? GetWindow(this UIWindow? platformWindow)
    .
  • Create Item Template for a Window

Issues Fixed

Fixes #23518

@PureWeen PureWeen marked this pull request as ready for review July 18, 2024 20:22
@PureWeen PureWeen requested review from a team as code owners July 18, 2024 20:22
@PureWeen PureWeen marked this pull request as draft July 18, 2024 20:22
get
{
if (Windows.Count == 0)
return _singleWindowMainPage;

return Windows[0].Page;
}
[Obsolete("This property is deprecated. Initialize your application by overriding Application.CreateWindow rather than setting MainPage. To modify the root page in an active application, use Windows[0].Page for applications with a single window. For applications with multiple windows, use Application.Windows to identify and update the root page on the correct window. Additionally, each element features a Window property, accessible when it's part of the current window.")]
Copy link
Member

Choose a reason for hiding this comment

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

Thinking out loud - this will cause a warning (or possibly error) in 100% of MAUI applications ever written, no? Is it that bad to keep this? Maybe an analyzer could be used to flag it and rewrite the code for those interested? (And ignored by those who don't.)

Copy link
Member Author

Choose a reason for hiding this comment

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

Yea, I just worry about also dragging the past along with us and not overall widening the pit of success

From a library author perspective using these APIs is really bad. For example, none of this code from our toolkit will work for multi-window https://github.com/CommunityToolkit/Maui/blob/cc1fb686815587076bbad45a1903f3ec3039315d/src/CommunityToolkit.Maui/PopupService.cs#L17

We probably see an issue a month for android where users need to override CreateWindow

#23645
#23493

I also worry about new users using MainPage and ignoring the analyzer suggestions.

The fix here is basically to do a solution search for
MainPage and replace it with Windows[0].Page

I get it because how widespread it is that users will all see warnings, but, it just seems to put MAUI in general on a path to longer term refinement/success.

I could see us maybe Obsoleting the set and just using an analyzer on the get perhaps?

Copy link
Contributor

Choose a reason for hiding this comment

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

Existing non-trivial apps already have various workarounds. There are still various gotchas in APIs. It's been getting better but it's not like there are no sharp edges.

Given that MAUI is relatively young, personally, I would be more radical, especially if it can lead to people not hitting bugs in the future (which translates to not losing more resources).

Analyzer might be nice in the sense: fix it for me fast.

@PureWeen PureWeen marked this pull request as ready for review July 20, 2024 22:48
@mattleibow mattleibow merged commit 6f2e1f2 into net9.0 Jul 23, 2024
112 checks passed
@mattleibow mattleibow deleted the fix_23518 branch July 23, 2024 13:53
@samhouts samhouts added the fixed-in-net9.0-nightly This may be available in a nightly release! label Aug 2, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
fixed-in-net8.0-nightly This may be available in a nightly release! fixed-in-net9.0-nightly This may be available in a nightly release!
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants