Posts Tagged ‘iphonesdk’

Trust, hostility, and the human side of Apple

Monday, June 15th, 2009

Trust, hostility, and the human side of Apple:

It was a giant middle finger to iPhone developers. And that’s the closing impression that Apple gave us for WWDC. Clearly, they had absolutely no interest in fielding even a single question from the topic that we have the most questions about.

imageNamed is evil

Thursday, April 16th, 2009

Another iPhone programming gotcha, this one involving UIImage’s imageNamed: method. Worth noting for later.

Coding tips for new iPhone developers from a new iPhone developer

Monday, February 2nd, 2009

If any of these seem wrong, please comment!

  • The Objective-C syntax is strange. It’s really not that hard, though, especially once you realize that part of the reason for the design was to make Objective-C a strict superset of C. That means that the C code you throw at it will compile and means the same thing under C as Objective-C.
  • Use NULL for pointers (void*) and nil for instances (NSObject*). They’re defined the same, this is just convention.
  • Use properties and stay sane. You can leave the dot syntax alone if you like (though I like it), but it’s worth using properties anyway because it forces you to document the assignment mechanism you’re using.
  • Method names that return an object where the name does not contain init must not require the object be released.
    • If you’re writing the object, this means you’re probably calling retain and autorelease.
    • If you’re using the object, this means it is probably already calling autorelease. If you release the instance yourself, you’ll crash later.
  • Use allocinit on the same line.
  • If you’re going to autorelease an object, do it at immediately on creation rather than later: [[[Object alloc] init] autorelease].
  • Sure, you can avoid using autorelease. Sure, it would perform “better”. But can you quantify “better”? Is it significant to you? If it isn’t, stick with using autorelease. When you follow the rules, you idiotproof yourself. See the probably in the previous group of points? Stick with the rules and it’s basically an “always.”
  • Remember that debugging is harder than writing code. While you can write something like textView.text = [NSString stringWithFormat:@"%@: %d", [b field:@"test"], [a precision]]; you are going to have to debug it later. In most cases, you’ll benefit from assigning results to temporary variables before passing them through to Cocoa.

I’m going to write about the major device vs. simulator differences I’ve noticed another time, but there’s one worth mentioning now: CGSize size = [string sizeWithFont:font] with a nil string will return a zero point on the desktop, but will return a random value (stack, maybe?) on the device itself. Check for nil first, as in CGSize size = string ? [string sizeWithFont:font] : CGSizeZero.

Fast iPhone scrolling with UITableView

Monday, December 15th, 2008

Fast Scrolling in Tweetie with UITableView by Loren Brichter, author of Tweetie:

Cutting to the chase, here’s the secret: One custom view per table cell, and do your own drawing. Sounds simple? That’s because it is. It’s actually simpler than dealing with a ton of subviews of labels and images, and it’s about a bzillion times faster (according to my informal tests).

This is not exactly relovuationary, but it is a nice summary and includes example code. This was perfect timing for me, as a custom table cell is one of the next steps in a project I’m working on. (Via Daring Fireball.)

Wil Shipley on the iPhone App Store: Let the Market Decide

Tuesday, September 23rd, 2008

Wil Shipley on the iPhone App Store. This is mostly the same thing I’ve been thinking, with the exception that I’d have removed the $999 I am Rich/I’ve been scammed! application without apology or even reason, even if the App Store offered some sort of price warning.