Four things I wish I knew about Objective-C six months ago (and three things I'm sure in six months I will wish I knew now) »
Jan-Yves RuzickaGosh, I really haven't kept this as up-to-date as I'd hoped. Nonetheless, slow and constant improvement is better than five entries and then silence for a year, right?
My project since, well, before the beginning of this year, has been to learn Cocoa/Objective-C. Partly, I like making things I can use, but it could also be helpful for the whole CV thing, if I decide to take that avenue. I hear diversification is good and all.
It's been a relatively steep learning curve. I'm not primarily a programmer, so I don't have quite the inclination to learn one language a year or whatever the recommended dosage is. There's been a few techniques that I haven't had to worry about programming in ruby. But overall it's been a mind-stretching experience, and those are always good.
There are a few things that I glossed over originally, thinking "I'll learn that later, when the project is up and running as it stands". It turns out that a lot of those things would have saved me time and effort if I'd learned them back in January or whenever. I thought I might document them for posterity's sake, perhaps.
Git
When I first learned git, it was so I could grab stuff from the internet. (Isn't that the case for all of us?) It took several projects before I worked out that -- hold on, version control could be really handy! Of course, there's a few commands in git, and while it's easy enough to remember git add and git commit, I tend to forget some of the more advanced/complex ones. Plus, I just haven't found a GUI for git that I particularly love.
So I printed out a cheat sheet:
This sits next to my computer and has every git command on it (well, every git command I need -- no conflicts so far). It's pretty handy knowing I can screw with my source as much as I want and, if I break it, I can just revert to my last commit. It effectively gives me permission to try weird crazy things without having to worry too much. Additionally, it forces me to solve issues one-at-a-time, rather than trying to give one class a big re-haul in the middle of another project. All good things.
Bindings
I briefly discussed bindings with a friend of mine who actually knows Objective-C, and while they sounded interesting I decided that I'd wait for a bit before learning them. I planned to get everything working and then replace what code I could with said bindings.
Turns out, bindings are awesome.
I ended up learning how to implement bindings from CocoaDevCentre: I found that their tutorial on actually getting them working was a bit more concise than Apple's documentation. Still, I think I'm better off for knowing how they work as opposed to just draging objects around on a canvas. The amount of glue code they eliminate, however, and the amount of time they save, is excellent. Not having to deal with a whole heap of new methods for changing text boxes and clicking buttons in my controller is bliss.
Which handily leads us to...
Code organisation
Classes get out of hand very quickly, and for a while I just had a file full of methods with no rhyme or reason to them. Which is fine when what you want to do of an evening is get method x completed: you don't want to spend half an hour refactoring your code. However, halfway through my project I started refactoring as I went, dividing the class into segments, alphabetically ordering methods within said segments, and liberally sprinling pragma marks throughout. Now it looks a lot cleaner - especially from the dropdown:
There's one other big advantage: peace of mind. Being somewhat of a clean freak, having my code organised nicely, so nothing will get lost, has something of a calming effect. Which lets me focus on what I'm doing now, even if it bears no relation to the nice clean code sitting on either side.
XCode 4
For a while I was running Snow Leopard with XCode 3. My coding friend looked at the interface and immediately told me to upgrade. I resisted.
Eventually I gave in and installed Lion. Some of the "features" I'm not incredibly pleased about, but XCode 4 is such an improvement. While it has trouble fitting on my 11" screen, the additional features offered (assistant editor, integration with source control, what seems to be improved error spotting, etc. etc.) are well worth the upgrade. I'm pretty sure it's sped up code production by a significant factor.
There's still a lot of things I need to learn. Eventually I plan on having some software up on here, but in the meantime, I'm learning. Here's some things I imagine in six months I wished I had learned right now, instead of waiting for a lull in coding:
Unit tests
I'm aware they exist for Objective-C, I just haven't got around to them yet. I'm interested as to how they'll work regarding UI (button clicks, etc.), but at least for the code it'll be handy to have automated tests so I know when things break.
Core Data
I ended up skimming a tutorial for this, and it looks amazing. I imagine that once I get to grips with it, I'll be shaving as much glue code off my application as I did with bindings, and it'll make everything incredibly maintainable. I just have to put in the time and either find a good article or bribe a friend.
???
Half the problem I have is that there's not really anything I can check out for a list of topics to learn. I have some books (but Objective-C books seem to fall out-of-date pretty fast), and I have a friend or two I can call on, but there is no well-established community here for asking "what should I do now?"
I'm getting better at this - browsing websites and checking out lists of tutorials - but for someone who's moved from hobbyist programming in ruby to learning Objective-C/Cocoa, it's a relatively big step. If I re-write this in six months, I imagine there'll be another few things on this list, things I don't even know I don't know, that I'm glad I picked up.
Reader Comments (3)
A few thoughts:
Git
- Try GitHub for Mac if you haven't already. http://mac.github.com I love Git because it has a brilliantly simple yet powerful architecture, but the command-line interface is horrible. (I consider myself an expert in Git CLI, but that doesn't mean I have to like it.) Most GUIs only try to add buttons that map directly to CLI concepts, which is a terrible idea. GitHub for Mac greatly simplifies things like push/pull and branching. Unfortunately it's still a bit buggy and sometimes throws out weird errors, but I've been using it professionally for a few months and haven't seen it actually break anything. More about its design: http://warpspire.com/posts/designing-github-mac/
- If you use branches, you'll eventually have conflicts. These magic commands will enable Git's FileMerge integration (FileMerge is Apple's diff/merge GUI that comes with Xcode, and it's quite good):
git config --global diff.tool opendiff
git config --global merge.tool opendiff
Then when you have a conflict, type:
git mergetool
...and FileMerge launches. By far the easiest way to resolve conflicts I've found.
- Everyone knows about GitHub, and it's great, but bitbucket.org has unlimited free *private* hosting of your projects. Very handy if you use more than one computer, or otherwise don't have offsite backups of your code. Only caveat is that their whole site is basically a half-baked ripoff of GitHub, which makes me kind of sad when I use it.
Code organisation
In case you weren't aware, you can also do:
#pragma mark -
or:
#pragma mark - Title
To do a horizontal rule in the code navigator. I like how this looks, but it's personal preference.
Core Data
I sometimes find it amusing how amazed Obj-C/Cocoa developers are when they get new patterns that other languages have had for some time already (e.g. blocks). You're a Ruby guy, right? I find Core Data not hugely different from Active Record, but maybe it's just because I've used so many similar ORMs.
Do yourself a favour and use mogenerator: http://rentzsch.github.com/mogenerator/
In Rails, say you have a User class. You'd make a migration with the column names, the migration creates the table in the database, and then Rails generates a User class file for you. You can put whatever methods you want in the class, and if you make any more changes to the database, Rails magically knows about them and makes them available as properties on the class. (Like many things in Rails, this 'magic' may be a hindrance to understanding what's going on, but at least it makes things super fast and easy.)
In Xcode, to do the same thing you'd make a User entity in the Core Data GUI editor, and you'd have Xcode generate the class file for you. But unlike Active Record, the class contains a complete mirroring of all of the properties in the database; your Obj-C classes don't know about anything that's in the database unless you have corresponding @properties in the class. So every time you make a change to the database, you have to do it twice: once in the database, once in the class. This is unnecessary and redundant. Plus, if you add any custom methods to the User class, they get mixed up with the boilerplate code, so you can never have Xcode regenerate that file again without losing your custom changes. Long story short: mogenerator solves both of these problems simply and easily, and I don't know why Apple hasn't adopted it into the Xcode core yet.
Blah blah blah. I could ramble about this stuff for hours. Have fun. And hopefully this comment shows up in some kind of readable form, because the preview seems to be broken.
Hey David,
Thanks for the advice! I had a look at GUI git clients a while back, but I didn't know as much about git then as I did now, which hindered my knowing what to do with all the buttons. I think I assumed that GitHub.app would work well if your project was hosted on GitHub but terribly otherwise - however, looking at the interface, it looks like it'll be fine. I'm not much for hosting stuff online right now anyway: I'm still a Poor Student, so my MacBook is my primary computer (and with >1 computer I'd probably end up syncing via dropbox anyway).
I've just been learning up about KVO and related technology, so I think I'll probably do a bit of hands-on coding before I pick up Core Data. When I do, however, I'll make sure to check out Mogenerator for model creation.
At the stage I'm at, more information on Objective-C is great. The sheer amount of framework around applications (and the various ways to manipulate it) means that there seems to be a whole lot to learn. The first app I made, I hand-coded the open- and save-file dialogue boxes because I wasn't aware that NSApp already had that code.
I'm getting better. Slowly.
Dropbox is great, but I'd recommend against using Git with it - it doesn't sync Git's internal data structures atomically[1], which can get Git into a really confused state. If you search Stack Overflow for both terms, you'll find a trail of tears from people who have tried this.
And yes, GitHub.app does work with any/all Git hosting, including their competitors or even self-hosting. It does have a few niceties that only work with github.com which aren't part of the standard Git protocol, but they aren't required.
P.S.: The preview problem was my issue (bad Safari extension)
[1]: https://en.wikipedia.org/wiki/Atomicity_(database_systems)