3 ms·
I misspoke, sorry about that. Overriding drawRect: itself isn't dangerous. Overriding drawRect: in a category is. The order in which the runtime determines whic
by Zev 15y ago
I misspoke, sorry about that. Overriding drawRect: itself isn't dangerous. Overriding drawRect: in a category is. The order in which the runtime determines which method to use isn't documented and should be considered unreliable. Relying on a runtime implementation detail is just as icky as method swizzling is - and just as good of a to wake up and find out that something randomly broke one day.
And what happens if there is a second category somewhere in UIKit or elsewhere to override drawRect: on UINavigationBar?
- flyosity 15y agoIt's only dangerous if you forget to call super's drawRect. Call that at the top of your function (to get the default graphics that UINavigationBar draws, and whatever else Apple does in there, probably nothing) and then do your own drawing after.
- Zev 15y agoCalling super in a category will not call the original implementation of the overridden method; it will call the superclass's implementation. While it is possible to call the original implementation of something overridden in a category, it involves a lot of ugly code that I wouldn't want to use in production. And if you don't call the original implementation, who knows what will happen to your navbar's drawing in the future? Relying on undefined behavior and implementation details is bad. To me, subclassing UINavigationBar (like I did in the blog post) and overriding layoutSubviews is a cleaner fix and doesn't rely on implementation details and runtime behavior.