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
It is incredibly useful to have UIViewController styling support and I think this should be included. It's fairly easy to add (see this commit) and it even helps alleviate the problem with styling UITabBarItem as mentioned in #1 since you can do that from within the UIViewController style.
Supporting view controllers might be useful, indeed. It's less clear at which moment they should be styled, though.
Yes, viewDidLoad might be appropriate, but it would be quite different from UIView styling where didMoveToWindow is used (to mimic UIAppearance), so it happens rather late. viewDidLoad happens in contrast rather early. It might still be a convenient approach, because with UIKit it's common to do a lot of setup in this method.
I presume you have some experience with your implementation. Does it behave as you (or especially an abstract iOS developer) would expect? Any quirks?
If not, I'd start with integrating view controller support. Please note, that I'd like to support macOS as well (which your current implementation doesn't). Feel free to provide partial implementation, we can collaborate on this.
The reason UIAppearance injects into didMoveToWindow is because there isn't any other reliable setup method in UIView to depend on. You can't be sure that an arbitrary UIView is setup and ready after init(frame:) or init(coder:), this is why UIAppearance is implemented the way it is. If UIView had a viewDidLoad method then I imagine they would have used that.
So far I haven't had any issues with injecting styles at viewDidLoad. I use it on every view controller in my app and also on apple's own view controllers and so far so good.
The reason UIAppearance injects into didMoveToWindow is because there isn't any other reliable setup method in UIView to depend on. You can't be sure that an arbitrary UIView is setup and ready after init(frame:) or init(coder:), this is why UIAppearance is implemented the way it is. If UIView had a viewDidLoad method then I imagine they would have used that.
This reasoning completely ignores the existence of other methods such as willMove(toSuperview:), didMoveToSuperview(). But this topic doesn't require further discussion, as we have no issues with views.
Activity
werediver commentedon Sep 30, 2018
Supporting view controllers might be useful, indeed. It's less clear at which moment they should be styled, though.
Yes,
viewDidLoadmight be appropriate, but it would be quite different fromUIViewstyling wheredidMoveToWindowis used (to mimicUIAppearance), so it happens rather late.viewDidLoadhappens in contrast rather early. It might still be a convenient approach, because with UIKit it's common to do a lot of setup in this method.I presume you have some experience with your implementation. Does it behave as you (or especially an abstract iOS developer) would expect? Any quirks?
If not, I'd start with integrating view controller support. Please note, that I'd like to support macOS as well (which your current implementation doesn't). Feel free to provide partial implementation, we can collaborate on this.
cfilipov commentedon Sep 30, 2018
The reason
UIAppearanceinjects intodidMoveToWindowis because there isn't any other reliable setup method inUIViewto depend on. You can't be sure that an arbitraryUIViewis setup and ready afterinit(frame:)orinit(coder:), this is whyUIAppearanceis implemented the way it is. IfUIViewhad aviewDidLoadmethod then I imagine they would have used that.So far I haven't had any issues with injecting styles at
viewDidLoad. I use it on every view controller in my app and also on apple's own view controllers and so far so good.cfilipov commentedon Sep 30, 2018
I'll work on getting something working on macOS as well then create a PR for this.
werediver commentedon Sep 30, 2018
This reasoning completely ignores the existence of other methods such as
willMove(toSuperview:),didMoveToSuperview(). But this topic doesn't require further discussion, as we have no issues with views.Looking forward for you pull request.
cfilipov commentedon Sep 30, 2018
Good point. I think those methods would also have been good candidates.