Matt Gallagher (Cocoa with Love): Control and configuration of applications through Info.plist. I hadn't heard of UIRequiresPersistentWiFi before, so this will be helpful to me.

James Thomson (PCalc): How to make your iPhone application start faster

Three20

I downloaded the latest version of Three20 today by Joe Hewitt. I read through some of the code and ran through the included "catalog" demo. If you've used the Facebook application, you've seen early versions of a lot of these controls.

I haven't written any code against it yet and I'm not up to reviewing it, but I will say this: The controls seem to fully work. They're pretty, and the code is clean.

Possibly the piece that will save me the most time going forward is the photo browser. I'm not sure yet when I'll need this, but doing it myself would be a lot of effort at my current knowledge of Cocoa Touch:

Three20photosLess visually impressive, maybe, are the buttons:

Three20buttonsBut it's worth pointing out that in addition to having more varied styling, these are built on UIView not UIBarItem. These are going to be very useful. I'm not exaggerating when I say they'll make it possible to write better applications.

Three20 also has some tab controls. The top one in particular has a great sideways scroll to it, and I think look and behavior adds up to great UI device, which I can use immediately:

Three20tabsNext, some styled views:

Three20viewsNot pictured:

  • Three20 includes "disk" based caching for network images.
  • Three20 provides easy tools for building a text representation of the application state. This will make restoring state between runs much easier.

Some of what's in the library has been rendered unnecessary by iPhone OS 3.0, but there is enough added to make it very compelling. I plan on putting it to use soon.

Justin Williams: Die you damn, dirty tab bar.

John Casasanta (Tap tap tap) on the impact of the iPhone 3GS RAM increase. Pretty memory usage graphs.

NSURL synchronous requests

Can't verify this yet, but something I want to investigate later:

Chris Parker (who "works for a fruit company in Cupertino") via Twitter:

Hey iPhone devs: sending synchronous requests via NSURL on the main thread is a good way to have SpringBoard kill you. Don't do that.

iPhone OS 3.0 Adoption Rate

Tapbots on iPhone OS 3 adoptions among their active users:

We’re currently running at an overall 75% upgrade rate which is pretty insane considering the number of devices and the fact that its only been 5 days.

Trust, hostility, and the human side of Apple

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.

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

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 alloc, init 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.

Older Entries »