Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Your First iOS App – 100% Programmatically

blog.austinlouden.com

Post reply on HN
Print view View original

101–110 of 111 posts

Re: Your First iOS App – 100% Programmatically

#101

Post by cmeranda »

coldtea wrote: post #77
coherentpony wrote: post #57

Earlier quoted context omitted.

Try merging a .nib. You'll see first-hand how hard it is.

Why merge it? Merging isn't even funny with regular code. How about having a process for who works on what or when? Either than or let a single person be responsible for the UI.

We're a two person development team who sits in the same 5 foot radius and we've had to merge xibs semi-frequently. It's not overly viable to ask the person next to you what files they plan to work on in the hour, because that can be difficult to determine in advance. Additionally once I upgraded Xcode before my partner, and suddenly our xibs were out of sync. In terms of one person working on the UI, even if that's the case, the other person might change an outlet, or create a non-UI object in the xib. It's complicated to coordinate changes because the breadth of features (as they appear in the codebase) is unpredictable.

Re: Your First iOS App – 100% Programmatically

#102

Post by abbott »

argonaut wrote: post #90
abbott wrote: post #51

Earlier quoted context omitted.

There is a huge difference between academia and real world products shipped by teams w/real world experience w/academic backgrounds. Stanford academic guidelines endorsed and supported by Apple, Inc. I wonder what approach Evan Doll uses at Flipboard...hmmm?

While I have no idea why M4v3R made that comment, as it's utterly irrelevant what Stanford teaches in their iPhone app class, it's also evident that you don't even know what M4v3R is referencing. He's referring to a class Stanford teaches on making iPhone apps, which has nothing to do with any sort of academic guidelines. The professor chose to use Storyboards, and that's that.

Research would serve you well in the history of CS193P.

Re: Your First iOS App – 100% Programmatically

#103

Post by koko775 »

danilocampos wrote: post #2

So, a word of advice to new folks trying out iOS land: Interface Builder is most emphatically your friend. The compile/debug cycle in iOS is sufficiently lengthy that laying out views programmatically gets very tedious very fast. Besides realtime previewing of exactly how your view is going to look , IB also helps you understand how your layout is affected by rotations to landscape and differences in view height betw…

Hey, long-time iOS dev here. Interface Builder is emphatically a beginner's friend. For "major league" stuff it is wholeheartedly the enemy. Avoid Storyboards like the plague. It's merge nightmare city when in teams, and a big enough app will suffer under the complexity required. It's simply not worth the pain.

With DCIntrospect (https://github.com/domesticcatsoftware/DCIntrospect), positioning in code actually becomes easier than nibs. You can print out the view properties, tweak positioning, then once it looks right you can get the values you need to tweak your code.

Additionally, getting to know UIAppearance and adding categories to UIColor and UIFont that return your app's standard fonts let you create a styleable application with consistent typography and color palette.

Re: Your First iOS App – 100% Programmatically

#104

Post by micampe »

seivan wrote: post #83
cageface wrote: post #81

Earlier quoted context omitted.

It's hard for me to believe that Storyboards or AutoLayout were designed by someone that actually builds non-trivial apps for a living. They're the kind of technologies that look good in a one-hour conference demo but quickly fall apart in real world use. After nearly throwing my laptop across the room on my latest project I ripped AutoLayout out of my project entirely and went back to springs & struts + frame math.…

You need to learn AutoLayout putting the blame on it won't help you.

Just let it be, cageface is on a mission.

Re: Your First iOS App – 100% Programmatically

#105

Post by goyalpulkit »

rbritton wrote: post #45
SeoxyS wrote: post #27

Earlier quoted context omitted.

I've been a Cocoa developer for close to a decade now, and I've gone back and forth on this many times, but by now I've settled 100% in the nibs-are-evil camps. There are several reasons for that: - Nibs are a nightmare when working with version control and merge tools. Now, at least, they are XML instead of a proprietary binary format, but it's still a joke… - Auto-layout in IB is provably the worst GUI I have ever…

I tried using Auto-layout on an app when it was first released, but for anything beyond simple cases it's incredibly buggy and unpredictable. It's now the first thing I turn off in any nib.

I don't think that Auto-layout is buggy at all. It is, however, not very intuitive and requires using it the right way for it to work!

Re: Your First iOS App – 100% Programmatically

#106

Post by conradev »

cageface wrote: post #84
seivan wrote: post #83

Earlier quoted context omitted.

You need to learn AutoLayout putting the blame on it won't help you.

I understand it. The problem is that not only is it a fundamentally flawed concept but the tools are inadequate. Moving a control by as much as one pixel in IB can completely scramble your constraints, including deleting user constraints attached to properties. The API is ridiculously verbose and the visual language is underpowered and cryptic. It's sad but going back to manual frame calculations actually saved me a…

I agree that the IB implementation is crap.

The API, on the other hand, is very nice. Although constraints can be slightly verbose, they are ages better than having to manually re-layout views after every single change of the superview's bounds. Spring and struts are nice, but cannot replace all of the CGGeometry math which is equally as, if not more, verbose than adding constraints. Autolayout is add-and-forget. The only downside is that it is iOS6+ only.

Re: Your First iOS App – 100% Programmatically

#107

Post by bennyg »

jgrall wrote: post #99
bennyg wrote: post #98

Earlier quoted context omitted.

I think the perfect thing to do is use a tool when it's necessary to use that tool, and no more/no less. Sometimes it's unnecessary and a pain in the ass to use .xibs or storyboards and other times it makes iterating through designs magnitudes faster (why not select all objects in a .xib and press up twice for a 2 pixel shift instead of editing 20+ cgrect calls).

I can definitely see how .xibs and storyboards might be useful for prototyping or quickly mocking up and iterating on a design that is changing rapidly. Whether or not you ship the app with the .xibs intact I think depends on whether you can tolerate the problems I mentioned, or whether your app is simple enough that it's NBD. Btw, for rapidly prototyping iOS apps I highly recommend Balsamiq - it's amazing what you c…

The things is, I've just never had those problems you mention in the 7 apps I've shipped, and I always use .xibs. Some apps of mine are simple, and some are fairly complex.

As a side note, I also hate, hate, hate using things like Balsamiq and other wireframing/mockup tools that you use a computer for. I'm a designer first and foremost (Art degree), and if I have to see something before beginning any coding/visual design work I'll draw it out on paper first. Most of the time though, I can keep the whole visual design process of which screens go to where and how they should look in my head. I think you're also underestimating how much visual design work has to happen, including after iterating a few times on the design, after doing your mockups. A few pixel shift here and there or bumping up/down a font-size, or even changing a gray from 65% black to 63% is fairly common. So, I just skip that mockup phase and start making the thing - iterating the design all the way through.

Re: Your First iOS App – 100% Programmatically

#108

Post by ianstallings »

coldtea wrote: post #76
ianstallings wrote: post #52

Earlier quoted context omitted.

It's called an opinion. This isn't a peer reviewed paper we're talking about. And his opinion is that merging Nibs is a nightmare. Does he need to document how he did it, when, where, and what the room temp was at the time to "justify" an opinion? Hardly.

> It's called an opinion. Which are like noses. Everybody has one. > And his opinion is that merging Nibs is a nightmare. Does he need to document how he did it, when, where, and what the room temp was at the time to "justify" an opinion? Does he needs to elaborate more in order to justify it? Of course.

Well allow me to elaborate - have you ever merged two nib files? With today's variant you merge XML. With yesterday's variant you simply don't do it because it's not possible. So you're merging an obtuse XML file at best. In my mind that's painful versus merging clean .h and .m files where we know what's going on. So he's using colorful language to describe such situations - A "nightmare".

Re: Your First iOS App – 100% Programmatically

#109

Post by jgrall »

bennyg wrote: post #107
jgrall wrote: post #99

Earlier quoted context omitted.

I can definitely see how .xibs and storyboards might be useful for prototyping or quickly mocking up and iterating on a design that is changing rapidly. Whether or not you ship the app with the .xibs intact I think depends on whether you can tolerate the problems I mentioned, or whether your app is simple enough that it's NBD. Btw, for rapidly prototyping iOS apps I highly recommend Balsamiq - it's amazing what you c…

The things is, I've just never had those problems you mention in the 7 apps I've shipped, and I always use .xibs. Some apps of mine are simple, and some are fairly complex. As a side note, I also hate, hate, hate using things like Balsamiq and other wireframing/mockup tools that you use a computer for. I'm a designer first and foremost (Art degree), and if I have to see something before beginning any coding/visual de…

I think you misunderstand what I mean by "prototyping or quickly mocking up a design that is changing rapidly". It has nothing to do with achieving a pixel-perfect design, finding the perfect shade of gray, or the right font size. It has a lot more to do with quickly testing ideas and iterating, rather than committing to a design and trying to get a finished look.

Paper does work well for this, and you're free to not like Balsamiq.

Re: Your First iOS App – 100% Programmatically

#110

Post by cageface »

conradev wrote: post #106
cageface wrote: post #84

Earlier quoted context omitted.

I understand it. The problem is that not only is it a fundamentally flawed concept but the tools are inadequate. Moving a control by as much as one pixel in IB can completely scramble your constraints, including deleting user constraints attached to properties. The API is ridiculously verbose and the visual language is underpowered and cryptic. It's sad but going back to manual frame calculations actually saved me a…

I agree that the IB implementation is crap. The API, on the other hand, is very nice. Although constraints can be slightly verbose, they are ages better than having to manually re-layout views after every single change of the superview's bounds. Spring and struts are nice, but cannot replace all of the CGGeometry math which is equally as, if not more, verbose than adding constraints. Autolayout is add-and-forget. The…

Have you done any Android dev? I find the various layout containers there far, far more intuitive and explicit and semantically clear. Let's face it, 95% of UI is nested grid layouts. Plus, having instant visual feedback for layout tweaks is a big time saver.
Post reply on HN