Dealing with fragmentation

No, this isn't about defragging your hard drive. Nor about what happens when you send your iPhone sailing across the room. Recently our good friend Carmen Hughes of Ignite PR pointed us at an article by Tricia Duryee of mocoNews.net entitled Why The iPhone May Be More Difficult To Develop For After The New One Arrives. Tricia's thesis can be summed up in a couple of sentences:

Engadget has dug up some technical specs on the upcoming iPhone 3G S that suggests the fragmentation within the App Store may begin soon. That means that going forward all of the apps may not work on all of the devices.

The Engadget article being referenced talks about how the new iPhone 3GS has hardware acceleration that supports OpenGL ES 2.0, but the hardware on the older iPhone and iPod touch models only support OpenGL ES 1.1.

Well, fragmentation is already a problem with the existing models -- no mobile phone in iPod touch, no GPS in iPod touch and first generation iPhone, etc. Most of the Cocoa Touch APIs will fail gracefully if the device doesn't support a requested feature, so unless your app is built around a particular hardware feature like GPS or video, your app can run on all models but hide or disable unsupported features.

And unlike Windows Mobile or Android (if Google gets the acceptance they're looking for), there's still only five major hardware revisions to test on: 3 iPhones and two iPod touch versions. The hardware capabilities are really very similar so far. The faster processor in iPhone 3GS might catch up a few inexperienced game developers, but I think the good ones will know to do primary testing on the lowest common denominator device and not build their event loop in a way that relies on processor speed (like some very old PC games did).

In the personal computer world, developers usually use the same computer to write and test their software simply because it's convenient. In the iPhone world it's not a problem to do your primary testing on an older device. I don't anticipate the common problem in the PC world where developers test their app on their shiny new high-end development machines, then release software that's dog slow on old low-end consumer machines. I think it'll actually be more common for iPhone developers to test mostly on iPod touch or older iPhone models (that's what we do at Able Pear).

Customers will need to pay closer attention to the compatibility info in the App Store, but I'm pretty sure iTunes won't let you buy something that won't run on your device. In addition, the typical lifespan of phones is several years shorter than for PCs, so I anticipate that the percentage of users on a particular model will drop off sharply after two years, compared to three to five for PCs.

So yeah, some customers will feel disappointed when that cool new game only runs on iPhone 3GS and they're still trapped in their AT&T contract and don't qualify for that sweet upgrade pricing. And others will feel gypped when that other cool new game looks really sweet on iPhone 3GS but kinda jaggy on their iPod touch. Is anyone really suprised by this? That's just the nature of the technology rat race.

original link

iPhone Friday - June 19, 2009

Hello, hello... Happy Friday!  Are you ready for the weekend?  Of course you are.  And to help you start your weekend right here is a fresh batch of iPhone and iPod touch wallpapers. (And Palm Pre. Shhhh.)

NSMutableArray and removeObjectAtIndex:

I'm working on some iPhone code that removes objects at random from an NSMutableArray and started to wonder about the lifecycle of items in a collection. I know that the collections in the Foundation library retain objects when they're added and release them when the collection deallocs itself, so it makes sense that calling removeObjectAtIndex: or any of the other "remove" methods would also release the object in question.

The removeObjectAtIndex: method doesn't return the removed object to you -- if you want to hold on to it, you need to call objectAtIndex: first. It also makes sense that you need to retain the object you're holding on to. A quick inspection of my code showed that I wasn't doing that in at least one place, but my app wasn't crashing. This made me wonder if objectAtIndex: was autoreleaseing the object it returned.

A quick Google search turned up an entry in William Woody's Development Chaos Theory blog entitled The lifespan of an object owned by NSMutableArray, or why Objective-C annoys me and Java makes me happy.

The punchline?

MyObject *obj = [myMutableArray objectAtIndex:0];
[[obj retain] autorelease];  // before removeObjectAtIndex
[myMutableArray removeObjectAtIndex:0];
UseMyObject(obj);

You need to retain the item before you remove it from the NSMutableArray (and eventually release or autorelease it).

The moral of the story: NSString literals are long lived and don't become invalid when a collection releases them. If you build your NSMutableArray by doing something like this:

NSMutableArray *myMutableArray = [[NSMutableArray alloc] initWithObjects:@"one", @"two", @"three", nil];

You will mask a lot of memory management problems.

original link

iPhone Friday - June 12, 2009

Hello and happy Friday! Today's iPhone wallpapers are from a set titled Spring Burst. Enjoy!

iPhone Friday - June 5, 2009 - Bonus

After talking to a few people about the floral set of wallpapers released earlier I wanted to provide you with a bonus set based on the colors and pattern of the wallpaper.  So I have 16 new wallpapers for you! That's 24 total released on this iPhone Friday.
The thumbnails bellow are smaller than usual, and like their larger counterparts, you need to click on the thumbnail for the full sized 320 x 480 pixel iPhone / iPod touch wallpaper to download  and use it.  Enjoy!

iPhone Friday - June 5, 2009

Happy Friday.  Are you ready for the weekend?  I am.  Spring is in the air - and spring is what this iPhone Friday's theme is... or rather an abstract of spring.  Because it's a little overcast out, a muted pallet.  Enjoy the floral inspired wallpapers.  Cheers!

Exploring the Mobile Apps Opportunity – How to Get to Ca-Ching!

Kevin and I have been involved with the MIT/Stanford Venture Lab (VLAB) for many years now. VLAB is the Silicon Valley chapter of the MIT Enterprise Forum, a non-profit organization that promotes high tech entrepreneurship by connecting ideas, technology and people. They run monthly events over at the Stanford Business School that cover interesting and emerging technologies, trends and industries including software, semiconductors, green tech and biotech. Kevin and I have attended many of their excellent events (and Kevin served as VLAB's Web and Operation Chair for many years).

This month's event is entitled "Exploring the Mobile Apps Opportunity – How to Get to Ca-Ching!" and is featuring Steve Demeter, the author of the popular iPhone game Trism along with a panel of industry experts. They plan to address the following questions:

• What are the challenges that application developers face as they set out to build a viable business?
• What should developers be focusing on in this highly fragmented eco-system?
• Which comes first, the application or the platform?
• Should developers first develop a killer mobile app and then try to figure out which platform to run it on, or should they first pick a device/platform and then optimize their app for that specific platform?

There's always lively discussion at VLAB events -- this is sure to be a good one. It's happening on Tuesday 16 June at 6:00 PM. Tickets are available online at vlab.org. Events like this one tend to sell out fast, so if you're interested, don't wait to register.

original link