3 ms·
It's hardly a 'drop-in' solution if you have to change all your UI views to inherit from the NUI equivalents. I could never use this based on that requirement.
by supercoder 14y ago
It's hardly a 'drop-in' solution if you have to change all your UI views to inherit from the NUI equivalents.
I could never use this based on that requirement.
- RandallBrown 14y agoI wonder if something could be done with the appearance proxy, or even something as simple as a #define from UIView to NUIView in the pch, that would make this even more drop in.
- eclipxe 14y ago[NUIRenderer renderButton:myButton];
- supercoder 14y agoYeah that doesn't really make it drop-in either though does it. The fact you have to litter you code with NUI references is a non-starter for me. They should have leveraged the UIApperance proxy. I know they have some reason about gradients or something for not using it, but that shouldnt force a compromise in the design.
- shawn-butler 14y agoCan't speak for the author but UIAppearanceProxy is iOS 5.0+, also only a subset of the UI classes respond to the UIAppearance protocol.
- supercoder 14y agoYeah, though targeting iOS 5 and up is really a non issue these days. UIAppearance actually supports any property on any UIView, including your own custom classes. The UI_APPEARANCE_SELECTOR declaration on the UIKit properties is little more than for the purpose of documentation to make it clear what is officially supported and tested for.
- shawn-butler 14y agoThanks for this info. So that means that UIAppearance is just some implementation hack on KVC? That is very useful and very ugly at the same time.
- shawn-butler 14y agoCould use categories rather than subclassing at first glance. Of course, usually my first glances are wrong.