41–50 of 111 posts
When will building an iOS app be as easy as building a homepage? I really don't understand why it must be such a big difference in complexity.
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…
I am also anti-nibs:
Examples — NIB caching; Managing UI in two places (class & IB); Nightmare managing versioning and diffs (same from @SeoxyS), especially in a team environment; "Having classes that may be instantiated both from code or from NIB deserialization adds a layer of complexity and messiness to your app" (Repost from @SeoxyS); Want a custom UI implementation? Forget about using NIBs
Without NIB's — yes you have to write a lot more code. Concerns of code bloat are overblown. Your viewcontrollers are likely already bloated without inline UI implementations.
It really comes down to personal preference especially on smaller projects/apps, but I'd argue if you have ever worked on a large scale app that you are responsible for maintaining and enhancing long term, your opinion of NIB dependencies will change. This is especially true as your team pushes the limits of the UI and app performance. If I was going to teach you how to write an app, I'd explain what NIBs are (known pros and cons) and let you decide for yourself. Just like explaining to (my) kids about religion.
Fun fact, not all WWDC examples use NIBs. Say what?! Blasphemy!
This is exactly how you should build your first app. Using Interface Builder will make you a permanent novice.
This is exactly how you should build your first app. Using Interface Builder will make you a permanent novice.
The only objectively bad thing about IB is that the generated files are impossible to merge. It would be much nicer if they were more like Android's human readable xmls.
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…
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…
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…
I'd love one of these for Android. I am also anti-nibs: Examples — NIB caching; Managing UI in two places (class & IB); Nightmare managing versioning and diffs (same from @SeoxyS), especially in a team environment; "Having classes that may be instantiated both from code or from NIB deserialization adds a layer of complexity and messiness to your app" (Repost from @SeoxyS); Want a custom UI implementation? Forget abou…
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…
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…
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…
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…
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…
Perhaps the worst, most insidious, damning thing about IB is it keeps novice iOS developers novices. You end up with programmers who don't know what they don't know. I can write UI code faster than any developer I've ever met who uses IB, and that's doubly true for class hierarchies I have subclassed for multiple apps, and triply true when it comes time to change those subclassed hierarchies. You note that IB is for…
I know what you mean. I'm not an iOS/Cocoa dev by any means, but when I write CSS I typically know what the outcome is going to be in my head because I've done it so many times.