

On Making Socialcam's User Interface (Or, The #%$&ing Red Line)  - mjdipietro
http://blog.socialcam.com/on-making-socialcams-user-interface-or-the-in

======
kulkarnic
>> There is no doubt that Socialcam looks much better with the red line in
place than without. So we needed to keep it.

Let me just say that if it's that subtle a detail, you'd rather spend
engineering effort on something that gives you a greater return on investment.

Is the red line going to make the program functionally better? Will it
increase reliability? (It'll probably reduce it if not coded properly) Will it
add significantly to user-delight?

While it is useful to know _how_ to do what you did, this is, in my mind, a
case of not knowing _what_ to do.

~~~
Skroob
Details are important, even if they're as minor as this one.

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

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

~~~
danilocampos
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...](http://iphonedevelopment.blogspot.com/2009/10/dont-fear-interface-
builder.html)

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 multiple states? A few clicks
save you several lines of code per UI object. As as mentioned in the above
link, every line of code you don't have to write is a line of code you don't
have to maintain/debug. The converse is a _huge_ volume of code across an app
to do tedious layout stuff, which doesn't sound fun.

You also cut down on compile/debug cycles, thanks to skipping things like "Oh,
fuck, I forgot to set that label's background to clearColor."

Perhaps best of all, IB will help you set up autoresizing masks for your
views. This process is extremely counterintuitive to me and it's nice to be
able to immediately test out my changes without having to build and run for
each tweak.

~~~
fleitz
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.

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

~~~
zbowling
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>

