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.
20 Amazing iPhone Apps Developed by College Kids
January 19th, 2010 by eddie
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!
iPhone Bootcamp SF
December 6th, 2009 by eddie
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.
Song Sift Released!
October 21st, 2009 by eddie
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.
Information Week quotes both James and me
October 20th, 2009 by eddie
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
Al Roker loves POW!
October 13th, 2009 by eddie
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/
Inedible featured in Fortune article
October 12th, 2009 by eddie
Fortune recently had an online article that centered around Shotgun Free and it’s advertising revenue. Check it out: Shake. Load. Kaboom
Integrating the iPod in OS 3.0 (2)
September 10th, 2009 by eddie
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.
Integrating the iPod in OS 3.0
September 1st, 2009 by eddie
One of the OS 3.0 upgrades we were psyched about was iPod integration. I’ve been playing around with it a lot for several of our upcoming projects, and I have some comments that might help people doing the same.
When you use the iPod app, every tab looks amazing and scrolls smoothly. When you first setup your own music browser, however, you’ll see serious lagging and bad scrolling speeds in your UITableView.
The reason for this is that, even though you might have an MPMediaItemCollection, you don’t actually have the MPMediaItems in memory. So when you query a bunch for MPMediaItemPropertyArtist, for example, you’re going to see serious lagging and it loads that data into memory.
Apple, I’m guessing, prefetches and caches everything, so if you want to see smooth scrolling you should probably do the same. Once you load an MPMediaItem into memory once it stays there and every subsequent request to it is lightening fast.
I today came up with an easy prefetch that rests somewhere between hacky and elegant. I put something like this off the main thread after launch.
MPMediaItem *rItem;
NSString *pID, *title, *artist;
for(int i = 0; i < [query.collections count]; i++) {
rItem = [[query.collections objectAtIndex:i] representativeItem];
pID = [rItem valueForProperty:MPMediaItemPropertyPersistentID];
title = [rItem valueForProperty:MPMediaItemPropertyAlbumTitle];
artist = [rItem valueForProperty:MPMediaItemPropertyArtist];
}
Note that you're not actually storing anything, just calling the item up into memory to query it. What's nice about this solution is that, if your prefetch gets to an item first, your table's request for that information will go lightening fast and thus provide smooth scrolling. If, however, your user gets there first, then the table will lag a little (which is unavoidable) but when the prefetch gets there it won't waste time pulling it into memory again.
Overzealous iTunes Censorship
July 25th, 2009 by eddie
In our description of Shotgun Free / Pro we wrote that you need to “pump your iPhone or iPod touch back and forth to cock”. This is perfectly legitimate and non-vulgar use of the word “cock”, but unfortunately iTunes displays it as needing to “pump your iPhone or iPod touch back and forth to c**k”. Thanks iTunes, thanks.
We’re also not the only ones to be hit — see below
20 Amazing iPhone Apps Developed by College Kids
January 19th, 2010 by eddieThis 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!
iPhone Bootcamp SF
December 6th, 2009 by eddieIt’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.
Song Sift Released!
October 21st, 2009 by eddieInedible 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.
Information Week quotes both James and me
October 20th, 2009 by eddieJames 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
Al Roker loves POW!
October 13th, 2009 by eddieWe 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/
Inedible featured in Fortune article
October 12th, 2009 by eddieFortune recently had an online article that centered around Shotgun Free and it’s advertising revenue. Check it out: Shake. Load. Kaboom
Integrating the iPod in OS 3.0 (2)
September 10th, 2009 by eddieI 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.
Integrating the iPod in OS 3.0
September 1st, 2009 by eddieOne of the OS 3.0 upgrades we were psyched about was iPod integration. I’ve been playing around with it a lot for several of our upcoming projects, and I have some comments that might help people doing the same.
When you use the iPod app, every tab looks amazing and scrolls smoothly. When you first setup your own music browser, however, you’ll see serious lagging and bad scrolling speeds in your UITableView.
The reason for this is that, even though you might have an MPMediaItemCollection, you don’t actually have the MPMediaItems in memory. So when you query a bunch for MPMediaItemPropertyArtist, for example, you’re going to see serious lagging and it loads that data into memory.
Apple, I’m guessing, prefetches and caches everything, so if you want to see smooth scrolling you should probably do the same. Once you load an MPMediaItem into memory once it stays there and every subsequent request to it is lightening fast.
I today came up with an easy prefetch that rests somewhere between hacky and elegant. I put something like this off the main thread after launch.
MPMediaItem *rItem;
NSString *pID, *title, *artist;
for(int i = 0; i < [query.collections count]; i++) {
rItem = [[query.collections objectAtIndex:i] representativeItem];
pID = [rItem valueForProperty:MPMediaItemPropertyPersistentID];
title = [rItem valueForProperty:MPMediaItemPropertyAlbumTitle];
artist = [rItem valueForProperty:MPMediaItemPropertyArtist];
}
Note that you're not actually storing anything, just calling the item up into memory to query it. What's nice about this solution is that, if your prefetch gets to an item first, your table's request for that information will go lightening fast and thus provide smooth scrolling. If, however, your user gets there first, then the table will lag a little (which is unavoidable) but when the prefetch gets there it won't waste time pulling it into memory again.
Overzealous iTunes Censorship
July 25th, 2009 by eddieIn our description of Shotgun Free / Pro we wrote that you need to “pump your iPhone or iPod touch back and forth to cock”. This is perfectly legitimate and non-vulgar use of the word “cock”, but unfortunately iTunes displays it as needing to “pump your iPhone or iPod touch back and forth to c**k”. Thanks iTunes, thanks.
We’re also not the only ones to be hit — see below