4 ms·

Couldn't you just draw the red line in drawRect of a UINavigationBar category? Then it'd appear in every navigation bar of your app, in the UINavigationBar, and

Couldn't you just draw the red line in drawRect of a UINavigationBar category? Then it'd appear in every navigation bar of your app, in the UINavigationBar, and not lost in some other hierarchy anywhere else.

sahillavingia 15y ago
My thoughts exactly. One reason against this is that it changes every single one of your bars. However, the way around it is to tag each navigation bar with a different number and use that conditional in the UINavigationBar category. Though, there's probably a reason they didn't go with this. Any ideas?
- flyosity 15y ago
  Besides your point, the only other downside is that the red line is in the navigation bar, not directly below it. If it's a pixel or two tall it's probably fine but if it's 4+ pixels tall it'd probably make the vertical spacing of elements in the nav bar (titles, buttons) appear slightly misaligned.
Zev 15y ago
Unless I'm creating a completely custom view, I generally see overriding drawRect: as a dangerous idea; you're messing with Apple's implementation details and there's no way to know how it will work in the future. Also, not every navigation bar needed to have a red line. // edit: "overriding drawRect:" should have read "overriding drawRect: in a category".
- flyosity 15y ago
  Overriding drawRect to do your own drawing is probably the most common thing that iOS developers do when working on custom interfaces. I'm not sure why you think it's dangerous, it's a public API call. I think almost every app developer I know who has designed a custom navigation bar has done his own drawing in drawRect for it instead of swizzling or some other more hacky method. Re: not every navigation bar needing to have it, you could have a different UINavigationBar category in those VCs to not draw the red line, no?
  - 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 ago
      It'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 ago
        Calling 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.

sahillavingia 15y ago

My thoughts exactly. One reason against this is that it changes every single one of your bars. However, the way around it is to tag each navigation bar with a different number and use that conditional in the UINavigationBar category. Though, there's probably a reason they didn't go with this. Any ideas?

flyosity 15y ago
Besides your point, the only other downside is that the red line is in the navigation bar, not directly below it. If it's a pixel or two tall it's probably fine but if it's 4+ pixels tall it'd probably make the vertical spacing of elements in the nav bar (titles, buttons) appear slightly misaligned.

Zev 15y ago

Unless I'm creating a completely custom view, I generally see overriding drawRect: as a dangerous idea; you're messing with Apple's implementation details and there's no way to know how it will work in the future. Also, not every navigation bar needed to have a red line. // edit: "overriding drawRect:" should have read "overriding drawRect: in a category".

flyosity 15y ago
Overriding drawRect to do your own drawing is probably the most common thing that iOS developers do when working on custom interfaces. I'm not sure why you think it's dangerous, it's a public API call. I think almost every app developer I know who has designed a custom navigation bar has done his own drawing in drawRect for it instead of swizzling or some other more hacky method. Re: not every navigation bar needing to have it, you could have a different UINavigationBar category in those VCs to not draw the red line, no?
- 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 ago
    It'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 ago
      Calling 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.