Becoming an iOS Developer
joshsmithonwpf.wordpress.com
joshsmithonwpf.wordpress.com
The first mental sticking point for people used to other frameworks is that you really must use Interface Builder as a beginner, even if it seems undesirable or unnecessary. Drag and drop an NSFooView in Interface Builder, and it will be nicely initialized and will act the way you expect. Instantiate an NSFooView in code, and you have a debugging task ahead of you, because the defaults you get when you init an object in code are different from the defaults you get when you create it in Interface Builder. It doesn't look or act the same at all. You end up creating the same object in Interface Builder just so you can inspect its attributes and try to set them to be the same in your code, maybe running your Interface Builder code in the debugger to see how the object behaves. (I assume the same is true of UIFooViews, though their default configuration might be closer to what Interface Builder creates since iOS interface objects are newer, code-wise, than the NextStep-derived objects used in Cocoa on OS X.) It's hard work to do things the wrong way. Someone used to another UI framework can put themselves through a lot of misery trying to figure out how to accomplish things in code without the help of Interface Builder, before they realize Interface Builder is an important part of the framework, not just a minor feature of Xcode that you can easily do without.
Another major cause of disorientation is that the learning curve is shaped very differently because of Interface Builder. In a framework that doesn't have a GUI builder, the beginner documentation holds your hand line by line through the code required to create a window, instantiate UI elements, configure them to behave properly, add them to a container, and specify how they're laid out. Why all that? Because you can't do anything without being able to do that! You can't pop up "Hello World!" with a button below it saying "Hi there" unless you can do all of the above!
With Interface Builder you don't have to do any of that in code. It's just drag, drop, done. No need for a twenty-page tutorial that explains containers and layout managers and the event-handling loop.
But here's the thing. There isn't much more to a typical UI framework than containers, layout managers, elements inside the containers, and events. So the "beginner" tutorial in a typical framework holds your hand across all the territory you need to master, and a decent book will explain the things that the tutorial glossed over. By the time you're able to make the button under "Hello World!" change the text to "Ha ha ha fart face" you've learned all the fundamentals, and you can reason things out for yourself. You're self-sufficient! From that point on, the rest of the learning curve consists of reading documentation for the various framework elements you need to use (individual widgets, menus and menu items, layout managers, framework APIs for background tasks, keyboard shortcuts, persistence of preferences, etc.)
Interface Builder, on the other hand, makes it so easy to get a simple application up and running that programmers are assumed to spend a certain amount of time at the static layout level. If you try to jump ahead and create a more complex app (what I think of as a realistically complex application) then you're already leaving beginner territory. If it's your first app, then you're trying to take the curve too fast. Personally, it's been weeks and I don't feel self-sufficient. I don't grok GUI development in OS X at all; I can't fend for myself at all in Cocoa-land; and it feels like I'm shamefully slow at accomplishing these things. Creating widgets at runtime and laying them out dynamically (because I don't know at compile time how many widgets I'll need and of what type -- I SWEAR IT -- I will kill any man who questions it) is just killing me. All of the documentation seems to assume I know what the hell I'm doing much more than I actually do. The response I get from other beginners when I ask about dynamically creating and laying out views is, "You're braver than me!" which isn't true. I'm not brave! I'm a shivering, sniveling noob! I want this to be beginner stuff! But the Interface Builder learning curve is shaped completely differently. What I'm trying to do follows naturally from noob tutorials in other GUI frameworks, because it's really hard to be a noob in other frameworks. In Interface Builder, it's easy to be a noob. How you get beyond that is still a mystery to me, though.
A nib is a file created by Interface Builder that contains serialized objects that can be reconstituted at runtime. An xib is an XML file that compiles to a nib. An xib is somewhat human-readable and (if you keep the target platform exactly the same) can be somewhat usefully diffed as you modify the interface. I'd like to explain more, but my lack of understanding of the precise nature and use of nibs is part of what makes me a noob.
This is not good advice.
ARC is meant to free the programmer from having to think about memory management and allow us to instead think about what we're trying to express in our object graphs and algorithms. Deciding where to call retain and release is an old, tired dance and is where the vast majority of memory leaks and app crashes come from. With ARC, we can just relax and let the compiler insert all those pesky retains and releases where it knows they should go.
There is no reason for newcomers to learn the old style. If a newcomer is reading old-style code, she can skip over the retain/release calls and pretend they're not even there, because they don't affect the algorithm.
ARC is a step in the right direction, but it doesn't free newcomers from ever learning about memory management.
It doesn't solve retain cycles, thus requiring the judicious use of __weak in cases where a retain cycle may emerge. Determining where such a cycle may occur requires understanding reference counting. This significantly impacts your expression of algorithms where the simplest/best implementation may involve cyclic object graphs.
Additionally, ARC does not handle mixing CoreFoundation and Foundation code directly, requiring one to manually express bridging rules based on an understanding of reference counting.
It may be that ARC gradually smooths out its rough edges, and we find ourselves in a situation similar to GC, where developers need only understand the difference between weak and strong references, and the opportunities that exist there for leaks caused by maintaining strong live references.
However, we're still a bit far from that point, and newcomers should remain well-aware of retain/release and the vagaries of reference counting systems.
Anyway, random crash. My "manage memory manually" training knew it was an object getting released too early: I know I needed to retain it. Think think think... Of yes, my @property declaration was missing a retain declaration. Of course cocoa was releasing that object!
ARC sure helps, and between it and use of the autorelease pool (thanks Brent Simmons!) I hardly have to worry about memory management at all - except when I do, then I need to know what ARC is or is not doing behind the scenes.
However, ARC is not quite there yet. It's a very useful tool but it's still a rather imperfect abstraction. You have to understand the problems with loops in object graphs, strong and weak references and why they're needed, bridging and all the other things ARC can't do for you yet. Maybe in a few years it will be possible to completely forget about memory management but today you simply cannot write a well behaving Objective-C application without understanding what's happening under the hood when it comes to memory management.
If you're a Rubyist, pick up PeepCode's Objetive-C for Rubyists. You're going to watch that multiple times.
Then, go and get yourself a subscription at teamtreehouse.com and subscribe to Stanford's CS193P (a fantastic course taught by Paul Heggarty) on iTunes U.
Treehouse's iOS 4 badges' topics are somewhat aligned with the topics on CS193P. You should watch the topic on treehouse first, and then watch the corresponding Stanford lecture, which will be much more detailed and a bit heavier. Having watched the treehouse videos, though, you'll have a basic understanding of what Paul is talking about, and the progression will seem very natural.
Set aside 1-3 hours a day for this. The basic things I learned in a day, the more complex ones like CoreData took me a bit longer. If you don't fancy the homework assignments on iTunes U (the first one is rather boring, the other ones are ok and practical), do something else that uses what you learned.
Two weeks of 2-3 hours a day and you'll be on your way.
- Much better refactoring support.
- Excellent code generation.
- Better project file management.
- Superior navigation tools.
- Deeper code analysis.
- Better stability.
Re learning: I highly recommend this site: http://cocoadevcentral.com/d/learn_objectivec/
Very helpful for getting your mind around basic concepts.
Re: Interface builder. I think the trick is knowing when to use it and when not to. Certainly it is incredibly useful for getting your layout exactly as you want it. (This was a refreshing change from html) But it can be cumbersome if you're trying to share common interface elements via subclassing or without wanting to load a nib file every time. Occasionally I would use it just to get the layout right and then implement the same interface in code.
1. Build an app in Interface Builder. 2. Learn Cocoa Touch. The breadth of the library is more intimidating than the complexities of Objective-C. 3. Learn C and Objective-C.
Then think about paying apple to develop, releasing products, learning how memory management works, adding core data...
I did spend several months developing (and shipping) two Objective-C apps for the few months that Apple banned Adobe AIR (and everything else along with it), and despite having spent 30 years programming, and a good part of that in C and C++, the full awfulness of ObjC was a surprise. But if all you've ever done is C#/WPF, ObjectiveC is going to be quite a shock. In fact there'll be a lot of cognitive dissonance.
To be fair, iOS does have a garbage collector (NSPool), but you have to free up references for it to reclaim space.
Is there any way around the "buy an Apple computer" requirement? Like installing OS X on a PC?
About Apple's this and that: "WONDERFUL" (new compiler service), "which [...(does miracles)] FOR YOU", "arc is AWESOME"
Long story short - there are a lot of evangelist's marks badly hidden that convey into "acceptance and humility" - requested, and... oh yeah: "pay Apple".