On Making Socialcam's User Interface (Or, The #%$&ing Red Line) • Hacker News Board

Re: On Making Socialcam's User Interface (Or, The #%$&ing Red Line)

#11

Post by Zev » Tue, Apr 26, 2011, 6:31 PM UTC

flyosity wrote: post #10

Zev wrote: post #7

Earlier quoted context omitted.

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".

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…

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?

Re: On Making Socialcam's User Interface (Or, The #%$&ing Red Line)

#12

Post by fleitz » Tue, Apr 26, 2011, 6:33 PM UTC

danilocampos wrote: post #6

dominostars wrote: post #5

Great writeup! Why didn't you guys just use interface builder? Not only does it speed up view building in general, but, as you claimed, it would have fixed this issue in particular.

My favorite quote on this: "...there's no more reason to abandon IB than there is to forego compilers and write all your code with a hex editor" http://iphonedevelopment.blogspot.com/2009/10/dont-fear-inte... Maintaining programmatically-generated views is miserable . But with IB, it's pretty simple. Wanna nudge that button up a couple pixels? Click. Drag. Done. Want to set up label and button appearances for multipl…

IMHO IB is the equivalent of writing HTML in Frontpage. No one is saying we should abandon tools like compilers that make us more productive, people are saying we should abandon needless crutches like writing HTML with Frontpage. IB is annoying because it doesn't work all the time and there are a lot of limitations to it, I'd rather just not use it.

Re: On Making Socialcam's User Interface (Or, The #%$&ing Red Line)

#13

Post by danilocampos » Tue, Apr 26, 2011, 7:05 PM UTC

fleitz wrote: post #12

danilocampos wrote: post #6

Earlier quoted context omitted.

My favorite quote on this: "...there's no more reason to abandon IB than there is to forego compilers and write all your code with a hex editor" http://iphonedevelopment.blogspot.com/2009/10/dont-fear-inte... Maintaining programmatically-generated views is miserable . But with IB, it's pretty simple. Wanna nudge that button up a couple pixels? Click. Drag. Done. Want to set up label and button appearances for multipl…

IMHO IB is the equivalent of writing HTML in Frontpage. No one is saying we should abandon tools like compilers that make us more productive, people are saying we should abandon needless crutches like writing HTML with Frontpage. IB is annoying because it doesn't work all the time and there are a lot of limitations to it, I'd rather just not use it.

> IMHO IB is the equivalent of writing HTML in Frontpage

If that's true, why does Apple, easily the most experienced Cocoa developer of all, use nib files in its shipping products? What have you discovered about Interface Builder that the creator of the tools and frameworks doesn't know?

This isn't generated code. It's not even remotely like Frontpage. Again, from the above link:

"Interface Builder does not generate code. It doesn’t create a forms file of any sort. What it does, is actually instantiate and configure the same objects that you use in your application to show your user interface. If you add a button to your application in Interface Builder, you’re actually creating an instance of UIButton or NSButton. When you configure it, you’re actually setting state on that button instance. Then, when the nib file gets saved, that button gets serialized into the nib file using NSCoding, exactly the way we persisted objects the archiving section of the persistence chapter in Beginning iPhone 3 Development. Basically, the nib loader is doing exactly what the code you would write to create and configure the interface object would do, down to the actual method calls used."

Except instead of a couple dozen lines of code, you have no lines of code – which strikes me as an excellent deal.

"If you’re writing tons of code to implement your user interface, that’s lots of code you have to write, maintain, and debug. The nib loading code is solid. It’s been around darn near 20 years and is used in literally thousands of production applications, including most of Apple’s applications. Apple very much "eats their own dogfood" when it comes to their development tools. If you look inside the bundles of an Apple application, the chances are very high that you will find some nib files in there."

Re: On Making Socialcam's User Interface (Or, The #%$&ing Red Line)

#14

Post by flyosity » Tue, Apr 26, 2011, 7:23 PM UTC

Zev wrote: post #11

flyosity wrote: post #10

Earlier quoted context omitted.

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…

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 t…

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.

Re: On Making Socialcam's User Interface (Or, The #%$&ing Red Line)

#15

Post by zbowling » Tue, Apr 26, 2011, 7:43 PM UTC

fleitz wrote: post #12

danilocampos wrote: post #6

Earlier quoted context omitted.

My favorite quote on this: "...there's no more reason to abandon IB than there is to forego compilers and write all your code with a hex editor" http://iphonedevelopment.blogspot.com/2009/10/dont-fear-inte... Maintaining programmatically-generated views is miserable . But with IB, it's pretty simple. Wanna nudge that button up a couple pixels? Click. Drag. Done. Want to set up label and button appearances for multipl…

IMHO IB is the equivalent of writing HTML in Frontpage. No one is saying we should abandon tools like compilers that make us more productive, people are saying we should abandon needless crutches like writing HTML with Frontpage. IB is annoying because it doesn't work all the time and there are a lot of limitations to it, I'd rather just not use it.

For main views, I feel the same way. For some subviews, I don't. I hate having my MainWindow as a xib (like the default project does which is why I created my own default project). For those simple views, I'll use IB. For my UITableViews (and all the form input version of those), it's straight code. It's easier then pulling teeth with IB.

Re: On Making Socialcam's User Interface (Or, The #%$&ing Red Line)

#16

Post by zbowling » Tue, Apr 26, 2011, 7:52 PM UTC

danilocampos wrote: post #13

fleitz wrote: post #12

Earlier quoted context omitted.

IMHO IB is the equivalent of writing HTML in Frontpage. No one is saying we should abandon tools like compilers that make us more productive, people are saying we should abandon needless crutches like writing HTML with Frontpage. IB is annoying because it doesn't work all the time and there are a lot of limitations to it, I'd rather just not use it.

> IMHO IB is the equivalent of writing HTML in Frontpage If that's true, why does Apple, easily the most experienced Cocoa developer of all, use nib files in its shipping products? What have you discovered about Interface Builder that the creator of the tools and frameworks doesn't know? This isn't generated code. It's not even remotely like Frontpage. Again, from the above link: "Interface Builder does not generate…

A good majority of my interfaces are based on UITableViews of some form. Used them for forms, navigation, etc. IB doesn't help me model up some of the fairly static data sources I return. I end up getting 90% of my apps done without touching IB for that reason.

I'll use IB occasionally for some custom views but since I'm using dinking around with the CALayer level adding shadows effects, and handling rotation animations and resizes in custom ways it usually gets in the way. I honestly never feel like touching for a lot my stuff.

I also do a lot of custom views and the designer doesn't help me manage those as well. Before XCode 4, I could write IB plugins but those were removed in 4, so more and more I'm finding less use for it.

One neat trick though is that I'll create NIBs and run Nib2Objc to generate code that I'll fix up as needed: https://github.com/akosma/nib2objc

Re: On Making Socialcam's User Interface (Or, The #%$&ing Red Line)

#17

Post by Zev » Tue, Apr 26, 2011, 7:59 PM UTC

flyosity wrote: post #14

Zev wrote: post #11

Earlier quoted context omitted.

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 t…

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.

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.

Re: On Making Socialcam's User Interface (Or, The #%$&ing Red Line)

#18

Post by fleitz » Tue, Apr 26, 2011, 8:20 PM UTC

danilocampos wrote: post #13

fleitz wrote: post #12

Earlier quoted context omitted.

IMHO IB is the equivalent of writing HTML in Frontpage. No one is saying we should abandon tools like compilers that make us more productive, people are saying we should abandon needless crutches like writing HTML with Frontpage. IB is annoying because it doesn't work all the time and there are a lot of limitations to it, I'd rather just not use it.

> IMHO IB is the equivalent of writing HTML in Frontpage If that's true, why does Apple, easily the most experienced Cocoa developer of all, use nib files in its shipping products? What have you discovered about Interface Builder that the creator of the tools and frameworks doesn't know? This isn't generated code. It's not even remotely like Frontpage. Again, from the above link: "Interface Builder does not generate…

I know for a fact that Apple does not use XIB for every interface, some stuff just requires custom code. I'd rather just code it in Obj-C than find out whether or not XIB works for this particular case.

XIB files certainly do contain code, it's just interpreted by an NSCoding object instead of compiled into machine code, that's like saying a PHP file doesn't have code in it because there is something written in C that interprets it.

Re: On Making Socialcam's User Interface (Or, The #%$&ing Red Line)

#19

Post by dominostars » Tue, Apr 26, 2011, 9:07 PM UTC

zbowling wrote: post #15

fleitz wrote: post #12

Earlier quoted context omitted.

IMHO IB is the equivalent of writing HTML in Frontpage. No one is saying we should abandon tools like compilers that make us more productive, people are saying we should abandon needless crutches like writing HTML with Frontpage. IB is annoying because it doesn't work all the time and there are a lot of limitations to it, I'd rather just not use it.

For main views, I feel the same way. For some subviews, I don't. I hate having my MainWindow as a xib (like the default project does which is why I created my own default project). For those simple views, I'll use IB. For my UITableViews (and all the form input version of those), it's straight code. It's easier then pulling teeth with IB.

Why not for some subviews?