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

[Nullability] NSView.Window & SuperView should be allowed to be null #21598

Closed
snechaev opened this issue Nov 8, 2024 · 4 comments · Fixed by #21619 or #21621
Closed

[Nullability] NSView.Window & SuperView should be allowed to be null #21598

snechaev opened this issue Nov 8, 2024 · 4 comments · Fixed by #21619 or #21621
Milestone

Comments

@snechaev
Copy link
Contributor

snechaev commented Nov 8, 2024

xamarin-macios/src/appkit.cs

Lines 16088 to 16097 in 9ea3cff

partial interface NSView : NSDraggingDestination, NSAnimatablePropertyContainer, NSUserInterfaceItemIdentification, NSAppearanceCustomization, NSAccessibilityElementProtocol, NSAccessibility, NSObjectAccessibilityExtensions {
[DesignatedInitializer]
[Export ("initWithFrame:")]
NativeHandle Constructor (CGRect frameRect);
[Export ("window")]
NSWindow Window { get; }
[Export ("superview")]
NSView Superview { get; }

The current implementation of the NSView.Window marked as non-nullable. But the Apple docs states that:

The value of this property is nil if the view is not currently installed in a window.

The same thing with a NSView.SuperView - the docs:

The value of this property is nil when the view is not installed in a view hierarchy.

@snechaev snechaev changed the title [Nullability] NSView.Window should be allowed to be null [Nullability] NSView.Window & SuperView should be allowed to be null Nov 8, 2024
snechaev added a commit to snechaev/xamarin-macios that referenced this issue Nov 8, 2024
@tipa
Copy link

tipa commented Nov 11, 2024

This change would finally resolve the false-positive warnings I get in Rider (at least partly): https://youtrack.jetbrains.com/issue/RSRP-494672

I believe the launchOptions parameter for application:didFinishLaunchingWithOptions: should also be annotated as nullable. Plus there's a whole lot more here or here. If it's just a missing annotation that could resolve it, like in the linked PR, it shouldn't be too difficult to resolve all these. Would have certainly prevented some crashes in my case :)

@snechaev
Copy link
Contributor Author

I believe the launchOptions parameter for application:didFinishLaunchingWithOptions: should also be annotated as nullable.

I don't see this declaration anywhere except in the templates

[Export ("application:didFinishLaunchingWithOptions:")]
public bool FinishedLaunching (UIApplication application, NSDictionary launchOptions)

So it looks like this can be manually annotated when creating the project (the template should be fixed to avoid manual fixes in the future). @tipa, am I missing some use case (I have no experience with iOS)?

@snechaev
Copy link
Contributor Author

snechaev commented Nov 11, 2024

by the way, the #21599 will only fix this for macos, not ios. I can add commits in the existing PR or create the new one.

https://github.com/xamarin/xamarin-macios/blob/9ea3cff36c86b1c3c46fb0872543165046b507a8/src/uikit.cs#L16921-L16929

@rolfbjarne
Copy link
Member

by the way, the #21599 will only fix this for macos, not ios. I can add commits in the existing PR or create the new one.

9ea3cff/src/uikit.cs#L16921-L16929

I've created a PR for iOS as well.

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