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

[watchkit] Add nullability to (generated and manual) bindings #14972

Merged
merged 4 commits into from
May 16, 2022

Conversation

tj-devel709
Copy link
Member

This PR aims to bring nullability changes to WatchKit.
Following the steps here:

  1. I am adding nullable enable to all manual files that are not "API_SOURCES" in src/frameworks.sources and making the required nullability changes
  2. Changing all throw new ArgumentNullException ("object")); to ObjCRuntime.ThrowHelper.ThrowArgumentNullException (nameof (object)); for size saving optimization as well to mark that this framework contains nullability changes
  3. Changing any == null or != null to is null and is not null

@tj-devel709 tj-devel709 added the not-notes-worthy Ignore for release notes label May 10, 2022
@tj-devel709 tj-devel709 added this to the Future milestone May 10, 2022
@tj-devel709 tj-devel709 requested a review from rolfbjarne as a code owner May 10, 2022 19:41
@@ -45,7 +47,7 @@ public virtual void DidReceiveRemoteNotification (NSDictionary remoteNotificatio
throw new PlatformNotSupportedException (Constants.WatchKitRemoved);
}

public virtual void DismissController ()
public new virtual void DismissController ()
Copy link
Contributor

Choose a reason for hiding this comment

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

This is surprising. What's the story here?

Copy link
Member Author

Choose a reason for hiding this comment

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

@chamons Good question, the compiler told me that I should and I kind of understood so I did, but because you asked, I read more on it and understand it a little better now!
The WKUserNotificationInterfaceController class inherits from WKInterfaceController and both classes contain a method definition for DismissController. The WKUserNotificationInterfaceController version above does not contain an 'override' keyword so implicitly, the compiler is hiding the base class version of DismissController inside WKInterfaceController. The compiler gives us a warning saying that it is already doing this, but we should mark it with the new keyword to be explicit. In this case however, both classes have the same definition for DismissController so I think adding a new or an override would give us the same results and perhaps we could even remove this method altogether?

That last part I am not 100% sure though and would like to know if others know if there would be any effects if we remove this method. If we have BaseClass, Derived1Class : BaseClass, and Derived2Class : Derived1Class and BaseClass and Derived1Class both contain different method implementations for Method1 (), if we call base.Method1 () from Derived2Class, will it call BaseClass.Method1 () or Derived1Class.Method1 ()?

Copy link
Member Author

Choose a reason for hiding this comment

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

Perhaps this would be good for me to bring to office hours ^

Copy link
Member Author

Choose a reason for hiding this comment

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

Wait testing it out and we can't add a virtual and override on a method so that was actually not an option in my top answer :)

Copy link
Member

Choose a reason for hiding this comment

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

You can't remove the method, because that's a breaking change.

In this case adding the new keyword is the correct thing to do, because it preserves the old behavior (the only change with the new keyword is that it silences the warning).

Changing to override would change the method to override the base method, which while it would probably be the correct thing to do from a design stand point, the fact is that this is deprecated API that doesn't even exist in the OS anymore, so our only concern is to not break backwards compatibility.

Copy link
Member Author

Choose a reason for hiding this comment

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

Long thread.. so I tested it out and found out that in my new scenario, the Derived2Class's base will refer to Derived1Class!

@vs-mobiletools-engineering-service2

This comment has been minimized.

@vs-mobiletools-engineering-service2

This comment has been minimized.

@vs-mobiletools-engineering-service2

This comment has been minimized.

@vs-mobiletools-engineering-service2

This comment has been minimized.

@vs-mobiletools-engineering-service2

This comment has been minimized.

@vs-mobiletools-engineering-service2
Copy link
Collaborator

📚 [PR Build] Artifacts 📚

Packages generated

View packages

Pipeline on Agent XAMBOT-1165.Monterey'
Hash: e9fb9f7611d5a51bed1c99f48805efad215f39f6

@vs-mobiletools-engineering-service2
Copy link
Collaborator

💻 [PR Build] Tests on macOS Mac Catalina (10.15) passed 💻

All tests on macOS Mac Catalina (10.15) passed.

Pipeline on Agent
Hash: e9fb9f7611d5a51bed1c99f48805efad215f39f6

@vs-mobiletools-engineering-service2
Copy link
Collaborator

❌ [PR Build] Tests on macOS M1 - Mac Big Sur (11.5) failed ❌

Failed tests are:

  • xammac_tests
  • monotouch-test

Pipeline on Agent
Hash: e9fb9f7611d5a51bed1c99f48805efad215f39f6

@vs-mobiletools-engineering-service2
Copy link
Collaborator

📋 [PR Build] API Diff 📋

API Current PR diff

ℹ️ API Diff (from PR only) (please review changes)

View API diff
View dotnet API diff
View dotnet legacy API diff
View dotnet iOS-MacCatalayst API diff

API diff

✅ API Diff from stable

View API diff
View dotnet API diff
View dotnet legacy API diff
View dotnet iOS-MacCatalayst API diff

Generator diff

Generator Diff (no change)

Pipeline on Agent XAMBOT-1170.Monterey'
Hash: e9fb9f7611d5a51bed1c99f48805efad215f39f6

@vs-mobiletools-engineering-service2
Copy link
Collaborator

✅ [CI Build] Tests passed on VSTS: simulator tests iOS. ✅

Tests passed on VSTS: simulator tests iOS.

🎉 All 148 tests passed 🎉

Pipeline on Agent XAMBOT-1162.Monterey'
Merge e9fb9f7 into 82482ed

@tj-devel709 tj-devel709 merged commit e9f0d7d into dotnet:main May 16, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
not-notes-worthy Ignore for release notes
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants