Since Song Sift was released it received three high-profile reviews.
The second was Gizmodo in their Top 10 Apps of the Week
We’re super pumped about all three reviews, as they come from some of the bigger and more important blogs / review sites. Whoo!
I’ve been working recently on a table with section headers that had really slow scrolling speeds (around 30 FPS). After a lot of digging, I found the problem in a strange place, so I thought I would share in hopes that someone else can save some time.
The gist of the problem is that when you override tableView:viewForHeaderInSection: it ends up being called constantly when you scroll. This in turn calls tableView:titleForHeaderInSection, and if that’s slow, you’re going to see serious lag.
What can unexpectedly make that call slow, however, is the standard:
[[[UILocalizedIndexedCollation currentCollation] sectionTitles] objectAtIndex:section];
What dramatically speeds it up, however, is declaring your own NSArray *sectionHeaders and setting it in your init as so:
sectionTitles = [[[UILocalizedIndexedCollation currentCollation] sectionTitles] copy];
I found that referencing this instead of the indexed collation dramatically sped up my scrolling speed, and now I’m whisking along at an acceptable speed (60 FPS).
On January 27th James and I will help chair an iPhone Event at PariSoMa. We’ve gotten to know (and like) the PariSoMa people from teaching the iPhone Bootcamps there, and they’ve started hosting what will hopefully be monthly iPhone meetups. This particular one will be about raising VC for an iPhone company, and we’re excited to announce that the creators of Cabulous, Tapulous and Smule will be there. We’ll also be discussing whatever Apple is announcing, be it the new tablet and/or iPhones and/or iPhone OS 4.0.
This comes from a sort of sketchy site, but it looks like an original blog post, so we’re still really pumped to be on the list. Check it out. On another note, our friend Jahanzeb’s app Jaadu VNC is on the list too. Nice job dude!
It’s been a while since I’ve made a post, so I figured I’d update you on at least one thing James and I are up to.
This weekend (Fri-Sat-Sun) we’re teaching the iPhone Bootcamp SF, which is a 3-day, 8-hour-a-day intensive iPhone course. We have about 380 slides and 10 exercises prepared for the Bootcamp. This is, however, the second one we’ve taught (the first was in September), so we didn’t have to create all of these materials from scratch; we did that last time.
Inedible Software, LLC is pleased to announce the launch of their fifth iPhone application, Song Sift. Song Sift is designed to help users find music from their iPod library by hiding all of the scattered entries introduced by playlists, compilations, and random downloads. Most user libraries contain artists or albums with only a single song, making it difficult to browse for long chunks of music to listen to in the car or gym.
“A friend was complaining about the frustration of navigating into artists with only one song, and I knew exactly what he was talking about,” recounts co-founder Eddie Marks. “We started working on a solution right away.” In the course of development, Marks found that over 50% of the artists on his phone had only a single song, confirming that there was a real problem in using the built-in music library directly. “Now I go straight to Song Sift every time I’m looking for something to listen to.”
Song Sift features a simple and convenient interface, keeping the familiar paradigm of the standard library and adding a simple slider to instantly filter the results. Once a user selects a song, the built-in music player takes over so all the standard features are available, like double-tapping the home button for quick control.
Song Sift is currently available on the iTunes App Store for $0.99 and is compatible with all iPhone and iPod touch models.
James and I, in different articles, each got a quote in Information Week in the last two weeks. Awesome!
James quoted about Flash CS5 making native iPhone apps
We just got word that Al Roker loves POW and actually used it on the TODAY show! We’ve yet to find the clip, but we’ve confirmed with an article from New York Magazine: http://nymag.com/shopping/features/59879/
Fortune recently had an online article that centered around Shotgun Free and it’s advertising revenue. Check it out: Shake. Load. Kaboom
I have a few more tidbits that might help anyone else trying to integrate the iPod in OS 3.0.
After a lot of experimentation, I’ve determined that there are vastly different times that certain data takes to load into memory. You can use this to your advantage. One example, building off my last post, is that a MPMediaItem’s persistent ID (pID) loads much more quickly than it’s other properties. What this means is that, if you’re forced to load other properties from memory, you can cache the information about each item in a NSMutableDictionary with the keys being pIDs. You can then save this out to disk on applicationWillTerminate, load it in on the next run, grab an item’s pID, check the dictionary, and get a huge load-time decrease if you’ve already seen it.
Another trick that has helped me out a lot is creating an MPMediaItemCollectionWrapper class. I init one of these classes with an MPMediaItemCollection and then, in a thread-safe way, lazy-load absolutely everything. This is made easy by having every necessary property be a read only property with an overridden getter. Here’s an example:
/* Album Title */
- (NSString *) albumTitle {
@synchronized(self) {
if(albumTitle == nil) {
[self.lock lock];
NSDictionary *appInfo = [self.cache objectForKey:self.pID];
[self.lock unlock];
}
if(appInfo == nil) {
loadedFromDisk = YES;
albumTitle = [[self.representativeItem valueForProperty: MPMediaItemPropertyAlbumTitle] retain];
artist = [[self.representativeItem valueForProperty: MPMediaItemPropertyArtist] retain];
[self.lock lock];
[self.cache setObject:[NSDictionary dictionaryWithObjectsAndKeys: albumTitle, @"Title", artist, @"Artist", nil] forKey:self.persistentID];
[self.lock unlock];
} else
albumTitle = [appInfo objectForKey:@"Title"];
}
return albumTitle;
}
}
All of the wrappers share the same lock and cache, so nothing has to unnecessarily access disk. Additionally, I’ve discovered that once you access one of the non-pID properties the others come for free, so I cache both the artists and the album title at the same time. The getter for the artist looks very much the same, so the cache gets created from whichever loads first.
The other huge benefit to having a wrapper is the ability to have that albumTitle selector for sorting purposes. Apple now gives us a UILocalizedIndexCollation class to help us create a table index, but the only way to use it is if the object being sorted has a single selector from which it can be sorted.
I don’t, however, use albumTitle. I instead use this:
/* Sortable Album Title */
- (NSString *) sortableAlbumTitle {
@synchronized(self) {
if(sortableAlbumTitle == nil)
sortableAlbumTitle = [[self stringByRemovingLeadingTheFromString:self.albumTitle] retain];
return sortableAlbumTitle;
}
}
Pass that along to your collation and you can easily index all of your MPMediaItemCollections in your table in the same way Apple does (without the leading “The”).
That’s all for now. I hope this ends up helping someone else who ends up trying to recreate swaths of the iPod app in their own application.
