A really nice review of the Chicago Tribune Sports Reader from iPhone, Therefore I blog.
I love it when I download something in the app store that makes me say “COOL or WOW!”
I also like it when someone creates something that’s not a carbon copy of something already in the store.
The Chicago Tribune Sports Reader is a perfect example of both.
I was part of the team that built this app for the Tribune.
Craig Hockenberry’s battles with improving the scrolling performance of UITableView.
Cocoa for Scientists (Part XXVIII): Bonjour and How Do You Do?
A great article on low level networking: How do you find and talk to another iPhone or Mac?
iPhone Developer’s Cookbook, The: Building Applications with the iPhone SDK, Adobe Reader
Erica Sadun’s book is now published. It’s a very good read. My only complaint is that there’s more emphasis on private APIs then I’m comfortable with.
Sample code for the book is available here.
Update: The sample code contains a description on how to use the coverflow API hidden in the bowels of the iPhone. Apple has since rejected apps that use this private API.
The How and Why of Cocoa Initializers
While not specifically an iPhone topic, there has been a long ongoing controversy among Cocoa developers on how to properly write init methods. Bottom line is to follow Apple’s example. This article explains why.
Creating objects can be very expensive in terms of performance. This is especially true for UIControls that are also added to a UIView. Instead create a number of objects once and reuse them when needed.
Here’s a code snippet from a book reader application that lays out each text paragraph as it’s own UILabel. Since each page has a varying number of paragraphs each with varying number of lines of text I initially created the necessary UILabels each time a page was rendered. Bad idea!
Now I have an array (often called an object pool) of UILabels that have been created and added to the page UIView. Initially the hidden property is set to YES for all these labels. When a page is rendered a UILabel is picked from the pool, initialized with the appropriate text, location and size. And the hidden property is set to NO to display the label.
// Add new text to existing labels
for (int i = 0; i < MAX_LABELS; i++) {
UILabel *textLabel = [textLabels objectAtIndex:i];
if (i < [currentPage.paragraphs count]) {
NSString *paragraph = [currentPage.paragraphs objectAtIndex:i];
CGSize textSize = [paragraph sizeWithFont:textFont
constrainedToSize:CGSizeMake(PARAGRAPH_WIDTH, 1000)
lineBreakMode:UILineBreakModeWordWrap];
textLabel.font = textFont;
textLabel.frame = CGRectMake(PARAGRAPH_LEFT_MARGIN, yOffset, PARAGRAPH_WIDTH, textSize.height);
textLabel.hidden = NO;
textLabel.text = paragraph;
yOffset = yOffset + textSize.height + PARAGRAPH_SPACING;
} else {
textLabel.hidden = YES;
textLabel.text = @"";
}
}
In addition to speed performance improvements this solution also has the significant benefit of managing memory much better.
The first rule of performance tuning is to measure your performance. If you don’t measure it, you don’t know if you’ve made any progress or if you’ve made it worse.
Here’s some very basic sample code you can use around the code you want to measure:
NSLog(@"Begin <your method name>"); NSDate *startTime = [NSDate date]; // Do something useful here NSTimeInterval elapsedTime = [startTime timeIntervalSinceNow]; NSLog(@"End <your method name>"); NSLog([NSString stringWithFormat:@"Elapsed time: %f", -elapsedTime]);
Note that NSTimeInterval is specified in seconds and it has a sub-millisecond resolution. If your code segment executes in less than a millisecond then you should run your code in a loop and measure the elapsed time across 100 or 1,000 iterations to get meaningful measurements.
Important: Make sure that you do your performance testing on the actual device and not in the simulator. Some operations are 10x slower on a device than in the simulator, while others are actually faster on the device.
The NSLog statements will show up in the Xcode Console window if you launch the app on the device from Xcode. You can also view log statements as warnings in the Organizer window in the Console tab.
Now that the NDA has been lifted it’s going to be a lot easier to find interesting links to other blogs discussing iPhone Development.
Erica Sadun has posted sample videos accompanying her upcoming iPhone Programmer’s Cookbook.
Some great advice on improving the performance of table views.
Managing the keyboard and ensuring that text fields are visible when you enter text is painful. Matt Gallagher presents a generic solution to this problem.
A very nice tutorial from Matt Long on creating your first iPhone application using Interface Builder.
A series of articles describing the software internals of the iPhone.
One of the great advantages of the iPhone platform is that it’s a single target to develop for. It doesn’t suffer from the “write once, test everywhere” syndrome of J2ME. But with 2.0, 2.1 and future firmware releases, not to mention rumored tablets and other new touch products, this will change.
The other day I managed to write an application that worked on 2.0 but not 2.1 devices. After some investigation I found that the root cause was a subtle change Apple made in 2.1 without any notification in release notes or in the SDK documentation.
Consider this very common snippet of code:
NSData *webData = [NSData dataWithContentsOfURL:url];
If the url in the above example refers to a file that is gzipped, e.g. www.myserver.com/file.gz, NSData will now (in 2.1) unzip the data automagically. So if your code was expecting to receive a representation of the compressed file, it will now break.
Most browsers will to the gzip/gunzip automagically when a web server sends compressed content. This is done to save bandwidth, improve download speed, and is generally a Good Thing. When the same “feature” is implemented in the SDK and you are not given any control over the behavior, that’s a Bad Thing.
The moral of this story is that you need to test all your code on both 2.0 and 2.1 devices.
This has been all over the iPhone developer community today. I just wanted to add my two cheers. Expect much more frequent posts here on this blog.
The App Store has finally launched. It’s available in iTunes 7.7 and from 2.0 iPhones and iPod Touch devices. Out of the 552 applications that are available today, I managed to get 4 applications listed. That’s almost 1% mindshare; not bad. And I have 5 more apps waiting for Apple’s review.
These are all applications that I have developed for clients:
Many of the built-in applications on the iPhone have this nice blue pattern background.
It’s easy to get the same effect in your applications. Just set the background to the built-in color called groupTableViewBackgroundColor. (Note that the documentation erroneously refers to this color as groupTableBackgroundColor.)
UIView *view = [[UIView alloc] initWithFrame:[UIScreen mainScreen].applicationFrame]; view.backgroundColor = [UIColor groupTableViewBackgroundColor];
There is an iPhoneDevCamp in NYC this weekend. Looks like a good un-conference event, so if you’re in the area, check it out. Sponsored by Socialight who are doing interesting things on mobile phones, and are apparently busy working on an iPhone version.