You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Apr 11, 2024. It is now read-only.
Sharing some thoughts here. There are two issues that I'm considering.
Is it really necessary to bridge classes that does not call super.traitCollectionDidChange(_:)
It is in the plan because if we don't bridge that, dmTraitCollectionDidChange(_:) won't be called when theme changes but now I'm kind of skeptical whether it is necessary.
I disassembled the UIKitCore (Went for the Catalyst one inside Mac (10.15.5) for convenience but there should not be a difference) and were able to find all these classes.
dmTraitCollectionDidChange(_:) is offered to users who wish to listen to and respond to theme changes in its subclasses on their own. So there are some classes we definitely don't need to bridge like private classes inside UIKit since you cannot subclass it easily. This already shortened the list of classes by 2/3. And there are classes which are not subclasses of UIView/UIViewController, apparently they can also be excluded (for now). The remaining ones are:
My personal experience with UIKit's traitCollectionDidChange(_:) is that I usually use it in a UIViewController or UIView subclass that manages other view(s), so I can just modify its subviews' properties inside this method when trait collection changes. The four UIView subclasses don't fall into my category as they either don't usually have subviews or they manage subviews inside themselves. I can think of a use case for UIImageView subclass though
class MyImageView: UIImageView {
override func dmTraitCollectionDidChange(_ previousTraitCollection: DMTraitCollection?) {
super.dmTraitCollectionDidChange(previousTraitCollection)
layer.borderColor = /* some code to retrieve a UIColor */.cgColor
}
}
As for UISplitViewController, I'm not really familiar with it, but I think of it as a wrapper of multiple UIViewControllers and does not have any visual element of its own, so maybe not calling .dmTraitCollectionDidChange(_:) is ok?
also the list subjects to changes since these calls to super.traitCollectionDidChange(_:) are within Apple.
We should add dmTraitCollection property requirement to DMTraitEnvironment just like UITraitEnvironment
I reflected on how I integrated IOS13's dark mode inside my own app when using traitCollectionDidChange(_:)
override func traitCollectionDidChange(_ previousTraitCollection: UITraitCollection?) {
super.traitCollectionDidChange(previousTraitCollection)
if self.traitCollection.userInterfaceStyle == .dark {
/* configure the dark appearance */
}
else {
/* configure the light appearance */
}
}
Currently we don't have a self.dmTraitCollection on DMTraitEnvironment. Which means in order to find the current UIView(Controller)'s theme, one should:
If on iOS 13+, use the one in UITraitEnvironment (since there might be overrideUserInterfaceStyle in these)
else, use the one in DMTraitCollection.override
Since we are back porting it, we should just provide a self.dmTraitCollection that automatically does it for users.
traitCollectionDidChange(_:)
traitCollectionDidChange(_:)
dm_updateDynamicColors
&dm_updateDynamicImages
, existing code should be moved todmTraitCollectionDidChange:
traitCollectionDidChange(_:)
Maybe should not implemented
super.traitCollectionDidChange(_:)
The first 6 is fixed in #78
The text was updated successfully, but these errors were encountered: