Planet iPhone SDK

In September, at the 360iDev Conference, I’m giving a talk titled Warm, Clothed and Fed: Developer Run iPhone Businesses.

A big part of the talk will be about where your money comes from in an iPhone business. You can categorize iPhone businesses into three segments based on revenue sources:

You can make money from (1) people purchasing your apps, (2) companies purchasing your time to create apps, or (3) developers purchasing your goodies to make making or selling apps easier.

Peter Farago, of the mobile analytics firm Flurry, has released some data for the game segment of the people pay for your apps category of iPhone businesses in a post titled Rise of the New Middle Class: Indie iPhone App Developers.

The piece’s central investigation is whether or not established game companies dominate the store. There are two prongs to its thrust:

First, the article compares the composition of the top-25 games on the App Store as compared to the top-25 games in AT&T’s broader market “Media Mall.” The latter was dominated by EA, accounting for a 36% share of the pie; 9 other companies made up the remainder. The former was more fragmented, with Gameloft commanding the largest share at 12% and 22 other publishers evenly splitting the remainder; notably absent: EA.

Second, the article examines the headway indie developers have made, over time, entering the top-25. Since September of last year, indie developers have had as many as 16 of the top-25 and have never had fewer than 11 of the spots. Peter’s post offerers evidence contrary to the common belief that indies are being squeezed from the App Store.

Peter’s article effectively makes the case that indies can be successful. However, there’s a bit of a Hollywood element to this kind of research. Just as every actor dreams of being a name, every game dev dreams of creating the next big game.

Is there an iPhone version of the not-a-star working actor? My as yet unsubstantiated hunch is that, in the game segment, the downward price pressure and typically long development cycles make this tough.

I’ll be fleshing out the data to test this hypothesis for my talk, but for the moment let’s assume it’s true. If it is, this either reducing game dev time or looking to other/non-game categories that can support a larger ticket. There’s a lot to say on both of those topics; I’ll follow up in future posts and in my talk at 360iDev.

Well, it's not just under 48 hours until I teach my first workshop. I'm a little harried right now. I'm comfortable teaching and speaking in front of groups, but I've never taught anything of this scope before, so I underestimated the prep time involved. I haven't slept much this week, and the situation doesn't look like it'll get much better before Friday.

If you e-mail me, IM, or tweet me in the next few days, please don't be offended if you don't get a response. I will try to catch up after the weekend and will be responding only to urgent e-mails in the meantime. I'm going to be mostly shutting out the world in an effort to get everything done and make sure that I'm satisfied with the workshop materials.

Despite the stress, I'm actually very happy with what I've gotten done so far. I think I'm really starting to understand what makes iPhone programming hard for both new programmers and experienced programmers coming from other languages. I guess we'll find out in a few days if I'm right about that, though.

The iPhone SDK’s AVFoundation framework includes AVAudioPlayer, an easy, feature rich, Objective-C based way of playing audio files.

This tutorial demonstrates how to use AVAudioPlayer. When you’ve finished the tutorial you’ll have created a simple app that plays an MP3 audio file in a loop when the app starts.

Source/Github

The code for this tutorial is available on GitHub. You can either clone the repository or download this zip.

Creating The Project

Launch Xcode and create a new View-Based iPhone application called AudioPlayer:

1. Create a new project using File > New Project… from Xcode’s menu
2. Select View-based Application from the iPhone OS > Application section, click Choose…
3. Name the project as AudioPlayer and click Save

Adding The AVFoundation Framework

In order to use the SDK’s AVAudioPlayer class, we’ll need to add the AVFoundation framework to the project:

1. Expand the Targets branch in the Groups & Files panel of the project
2. Control-click or right-click the AudioPlayer item
3. Choose Add > Existing Frameworks…
4. Click the + button at the bottom left beneath Linked Libraries
5. Choose AVFoundation.framework and click Add
6. AVFoundation.framework will now be listed under Linked Libraries. Close the window

Next, we’ll import the AVFoundation headers in our view controller’s interface file and set up an AVAudioPlayer instance variable:

1. Expand the AudioPlayer project branch in the Groups & Files panel of the project
2. Expand the Classes folder
3. Edit AudioPlayerViewController.h by selecting it
4. Update the file. Changes are bold:

#import <UIKit/UIKit.h>
#import <AVFoundation/AVFoundation.h>

@interface AudioPlayerViewController : UIViewController {
	AVAudioPlayer *audioPlayer;
}

@end

Adding An Audio File

We’ll need an audio file for playback. We’ll, unimaginatively, call the fille audiofile.mp3. Add it to the project:

1. Control-click or right click on the Resources folder in the Groups & Files panel of the project
2. Select Add > Existing Files… from the context menu
3. Locate and select the file for import and click Add
4. Check the Copy items into destination group’s folder (if needed) box and click Add

Starting Audio Playback

We’ll start the audio playback in ViewDidLoad:

1. Uncomment the boilerplate ViewDidLoad method
2. Update it as follows. Changes are bold:

- (void)viewDidLoad {
	[super viewDidLoad];

	NSURL *url = [NSURL fileURLWithPath:[NSString stringWithFormat:@"%@/audiofile.mp3", [[NSBundle mainBundle] resourcePath]]];

	NSError *error;
	audioPlayer = [[AVAudioPlayer alloc] initWithContentsOfURL:url error:&error];
	audioPlayer.numberOfLoops = -1;

	if (audioPlayer == nil)
		NSLog([error description]);
	else
		[audioPlayer play];

}

AVAudioPlayer is initialized with a URL, so we create one whose path points to the audio file in our on-the-phone resources directory. Setting the audio player’s numberOfLoops property to a negative number causes it to loop indefinitely. After configuring the player, we start the playback by sending the play message to the object.

Remember to release the audioPlayer in dealloc. Changes are bold:

- (void)dealloc {
	[audioPlayer release];
	[super dealloc];
}

More Capabilities

You can adjust the volume of the player, check/set the time played so far and pause or stop playback:

audioPlayer.volume = 0.5; // 0.0 - no volume; 1.0 full volume
NSLog(@"%f seconds played so far", audioPlayer.currentTime);
audioPlayer.currentTime = 10; // jump to the 10 second mark
[audioPlayer pause];
[audioPlayer stop]; // Does not reset currentTime; sending play resumes

Finally, you can implement the AVAudioPlayerDelegate protocol to, among other things, be notified when audio finishes playing — perhaps to move onto the next song in a playlist.

I know there's probably one or two people out there who would like to see another entry in the OpenGL ES from the Ground Up series.

The good news is, I started one a while back, right after WWDC. It's a fairly extensive introduction to OpenGL ES 2.0 and shaders.

The bad news is, I have no idea when I'll have time to finish it. I'm behind on writing the next book, plus I'm frantically trying to get ready for the iPhone Boot Camp NYC this weekend (boy, that snuck up on me). I will finish it at some point, though.

There are a lot of reasons to use the iPhone simulator and a few reasons not to.

During development, I like to see my changes in the app ASAP; I use the simulator because waiting while a build is pushed to a device interrupts flow. Later, when it’s time to create an app screencast, it’s a darn sight easier to use the simulator too.

Of course, the simulator isn’t perfect. Testing performance and tracking elusive memory leaks are best done on the device. And the simulator’s support of multi-touch, location and accelerometer is thin to non-existent.

This last set of limitations makes it tough for me to use the simulator precisely when I want to: during development and for screencasts. This is where iSimulate comes in.

iSimulate is an iPhone app and library intended for iPhone app developers. With it, you run your app in the simulator and but take multi-touch, accelerometer and Core Location capabilities from an actual iPhone.

I was skeptical of iSimulate’s PR pitch that it “takes literally 2 minutes to get it running on an application.” Having now used it with Apple’s AccelerometerGraph and Touches sample apps, as well as one of my own apps, I can confirm that it really only does take a couple of minutes to set up:

To use it, you add their library to your project, include Core Location (if it’s not already part of the project), add a linker flag, launch their app on your phone and launch the app in the simulator.

I’d like to see them make a couple of enhancements to the on-phone app:

First, the on-phone app is arranged in a landscape orientation, so my natural tendency is to hold the phone in this orientation. If my app runs in portrait mode — as most do — the touches are rotated by 90-degrees. Of course I should just hold the phone in portrait mode. Nevertheless, I’d like the phone app to have the same orientation as what’s displayed in the similator.

Second, it’s difficult to aim. When I put a finger down it’s never exactly on the target I was aiming for. This lowers the production quality of screencasts. It’d be nice if the on-phone app mirrored the simulator’s display, even at a low frame rate.

That said, it’s a dandy application and works as advertised. Details, documentation and pricing information here.

The dot notation discussion has taken far more of my time lately than it was wise for me to spend. I've said pretty much all that I need to say on the topic at this point. I don't care if you use it, just don't tell me I'm wrong for doing so.

Just for the record, I was horribly opposed to Objective-C's dot notation when it first came on the scene. i had programmed in both C++ and Java over the years, but I much preferred Objective-C, and I saw dot notation as being a step backwards and a really bad idea for a number of reasons.

For the book, Dave and I decided we were going to follow Apple's lead when it came to coding style and coding conventions, so I bit the bullet and started using properties for the book exercises. Now that I've used them regularly for about a year and a half, I have completely changed my opinion, and I'm pretty sure a lot of my original issues with dot notation were just rationalizations of my own resistance to change.

Arguing theory has only so much merit. In practice, with a little thought and understanding, properties and dot notation work well and can be used to make code considerably more readable and faster to write. If you haven't spent some real quality time using them - if you are arguing only from language theory - then you need to spend some time with them before you condemn them further.

Since we're talking so much about dot notation, I though I should link to a fabulously awesome blog post by Chris Hanson that tells how you should use dot notation and properties.

Before I get into this post, let me make a few things absolutely clear. I do not want my intentions misunderstood.

• When coding for yourself, do what feels right to you. If you don't like dot notation, don't use it, and don't feel like you should apologize for not using it.
• When coding for a client or employer who has a coding style guide or other published coding conventions, use those, even if they disagree with your personal opinion of the "right" way to code. In a group programming environment, consistency is extremely valuable.

My goal here is not to tell you that you must or should use dot notation, it is only to refute the idea that dot notation shouldn't have been added to the language and that it inherently makes code harder to read.

My illustrious writing partner, Dave Mark tweeted today about the Google Objective-C Style Guide's argument against using dot notation in Objective-C, which reads as follows:

1. Dot notation is purely syntactic sugar for standard method calls,whose readability gains are debatable. It just gives you another way to make method calls.
   
   
2. It obscures the type that you are dereferencing. When one sees:

   [foo setBar:1]

   it is immediately clear that you are working with an Objective-C object. When one sees

   foo.bar = 1

   it is not clear if foo is an object, or a struct/union/C++ class.
   
3. It allows you to do method calls that look like getters.
   

   NSString *upperCase = @"foo".uppercaseString;

   which is not only confusing, but difficult to spot in a code review.
   
4. It hides method calls.
   

   bar.value += 10;

   is actually two separate method calls (one to set and one to get) and if your properties are not simple you may find a lot of work being done in a hidden manner.

As you read through these, they sound rather logical, and possibly even compelling. But in reality, they are not logical at all. In fact, the whole argument is basically one series of logical fallacies. Let's look at the specific arguments in order and then put the pieces together at the end.

The First Argument: the Non Argument

Dot notation is purely syntactic sugar for standard method calls,whose readability gains are debatable. It just gives you another way to make method calls.

This first "argument" contains no actual argument against the use of dot notation. The first part of the first sentence is taken almost verbatim from The Objective-C 2.0 Programming Language on Apple's site and is just a restatement (out of context) of how dot notation is implemented.

The second half of the first sentence is an attempt to discount one of the benefits of dot notation by simply dismissing it offhand without evidence or support.

The second sentence is simply an attempt to bolster the arguments that follow by trivializing dot notation as "just" something we can already do. It's sort of like saying that jet engines do not add value over propellers because they're "just" another way to create thrust. Every construct in any programming language that's higher-level than assembly is "just" another way to do something we can already do. This sentence has no semantic or logical value, it's simply here to set a negative tone toward the use of dot notation without actually offering any facts or reasons not to use it. This first "argument" is rhetoric, nothing more.

The Second Argument: the Invalid Assumption

It obscures the type that you are dereferencing.

This argument brings to mind the arguments for Hungarian Notation. The argument for Hungarian Notation is that when you look at a variable, you know right away what it is. By prefixing every variable with a jumble of individual letters, each with its own meaning, you know (in theory) all that there is to know about that variable just by glancing at it.

In reality, you don't see much Hungarian Notation these days. Variables with semantic meaning - those that use words that are recognizable by and have meaning to the brain - work much better. We may not know the variable's specific type, but we know what purpose it serves, which is really more important.

Dot notation doesn't "obscure" the type you are dereferencing unless there's some reason why you would know the type from looking just at that line of code. This argument makes the assumption that we already know and that we should know what the type of foo is. Sure, with bracket notation, we know we're dealing with an object, but we don't know what kind of object it is from looking at this one line of code in a vacuum.

But, when do you ever look at a line of code in a vacuum? You don't. Code has no meaning taken out of context. If it was vital that we know everything about a variable from looking at it out of context, then we'd all be using Hungarian Notation. Yet we're not.

Somewhere, probably not more than a few lines above

        foo.bar = 1

is either a declaration of foo or the start of the method. If you're confused about the type, generally scrolling up a few lines can resolve that confusion. If that doesn't work (because it's an instance or global variable, for example), command-double-clicking on it will take you to its declaration and then you'll know its type.

You can't obscure something that you don't have a reason to know. The amount of information that bracket notation gives us over dot notation is trivial and not enough to make an informed decision about what the code is doing anyway, so you have to consider its context. If it's not your code, you have to look at the preceding code to understand it anyway.

The Third Argument: the Red Herring

It allows you to do method calls that look like getters.

Allows? This argument is that it's bad because it "allows" you to do something? And what it allows you to do is create method calls that look like getters? What are getters? They are a kind of method, right? Am I missing something here?

Any programming language, to be useful, has to allow some kinds of bad code. I doubt it's possible to create a programming language that doesn't "allow" an inexperienced programmer to do all sorts of completely horrible things. I could come up with dozens of examples of ways that Objective-C 1.0 "allows" you to do bad things. This isn't an argument, it's a one-line example of bad code that's being passed off as an argument. It's disingenuous because there's nothing to prevent you from creating methods that look like getters but aren't without dot notation. There's no language-level constraint on that in Objective-C, and no compile-time checks for it regardless of whether dot notation is used. Dot notation changes this in no way whatsoever.

I actually find it hard to believe that an experienced Objective-C programmer would even attempt this argument because, frankly, it sounds like an argument you'd get from a C++ programmer. Objective-C is a permissive language. It's in Objective-C's DNA to let you do things. It's weakly typed and handles at runtime many things that are handled at compile-time in C++ (and all other OO languages based on the Simula object model). These are intentional design decisions. This language is designed to give you a lot of flexibility and puts trust in the developer that you'll use its features appropriately. Objective-C's dot notation doesn't run contrary to that in the slightest. In fact, it's a logical extension of that underlying philosophy. They're faulting dot notation for something that's inherent in Objective-C

The Fourth Argument: Missing the Point

It hides method calls.

Why yes, yes it does. The sample line of code supporting this "argument"

        bar.value += 10;

will result in exactly the expected behavior if you're using dot notation to represent object state. If the value and setValue: methods are something other than an accessor/mutator pair, then this it is true that this line of code could cause unexpected results, but the fault for that lies not with dot notation, but rather with a programmer who made extremely poor method naming choices, essentially lying to the world about their methods by not respecting the naming convention for accessors and mutators. Under this scenario, you'd have exactly the same problem with this line of code that doesn't use dot notation:

        [bar setValue:[bar value] + 10];

In other words, this argument is only a problem when somebody does bad things with their code, and it's just as much of a problem when not using dot notation.

Whoops! It was pointed out in the comments that I sorta missed the point on this one, and that the "problem" is that there are two method calls when someone who didn't understand dot notation might reasonably think there was only one. My response to that is: so what? How is it a problem if the result is correct? The code used to illustrate the problem will achieve the results that you should reasonably expect. After the line of code, value will be correct. The fact that there are two messages sent and not one will not matter in the vast, vast majority of situations. What counts is that the result is correct, and in the example, it would be assuming the accessor and mutator are correctly implemented. If you're having performance problems and determine through profiling that it's caused by the extra message, then you optimize by implementing a method that increments the value in just one call. It's still a non-issue.

Illusory Arguments

The law has an interesting concept called an illusory promise (or condition), which is a promise that really isn't a promise at all. It's something that looks like a promise, and is couched in the language of a promise, but which simply isn't a promise.

These arguments against dot notation in Google's Objective-C Style Guide are illusory arguments. The first one, isn't an argument at all. The second rests on assumptions that are provably untrue (that you know what type a variable is from looking at just its line of code). The remaining two are predicated on a programmer doing something wrong and can both be demonstrated just as easily without using dot notation.

Google makes the case that dot notation is bad because it can result in confusing code when a developer pays no attention to established naming conventions or makes really poor design choices. But these problems have nothing to do with dot notation. Poorly written code is poorly written code. The simple fact of the matter is, if you're trying to read code like that, nothing is going to help. With, or without dot notation, the code will be hard to read because it's bad. The correct solution in that situation is to fire or train the developer who wrote the offending code.

How I Use Dot Notation

But, there are ways in which dot notation can be used to make code more readable. The way I use it (picked up from Apple's sample code) is to use properties and dot notation to represent object state, and bracket notation when calling methods that represent behavior or trigger actions. In fact, it could be argued that using bracket notation for both state and behavior has at least as much potential for causing confusion as using dot notation does. Take this line of code, for example

        [foo setIsOn:YES]

Am I setting state or triggering behavior? It could be either. It could be both. To know for sure, I have to check the documentation for the method being called. If, on the other hand, I've used dot notation and properties to separate out state from behavior, it's instantly understood that

        foo.isOn = YES;

is setting state, but

        [foo turnOn];

is triggering behavior (which may, of course, affect state). Yes, this requires consistent design choices, but all good coding does. If you throw that out as a requirement, you can argue that anything is bad.

Arguing against letting people use dot notation because some people will make poor decisions is ignorant. It's basically saying "I don't like it, so you shouldn't use it", and when you state it like that, it sounds kinda silly, doesn't it?

iPhone Application UI Design Patterns Great discussion on how best to design your next iPhone application by following these UI design patterns.

Environment Mapping Demo with OpenGL ES 1.1 Check out Noel’s environment mapping demo which is taken from his upcoming book iPhone SDK 3.0 Projects.

iPhone Dev: The Honeymoon is Over Thoughts of a well known Flash developer after he spent the last 6 months developing for the iPhone.

Apple: Secrecy Does Not Scale A discussion on how Apple should improve in the future with regards to secrecy as its products become more and more prevalent in society.

Apple and Gaming - The New Growth Story An overview of Apple’s history with the game industry and how things have changed.

Apple Bans App Store’s 3rd-most Prolific Developer Details on a recent event where Apple banned a very prolific developer’s applications from the App Store.

Rumor: Netflix Streaming Coming to the iPhone I sure hope this rumor is true. With Apple’s recent HTTP streaming implementation on the iPhone, Netflix seems like a natural fit.

iPhone Dev Camp 3 Weekend Recap Summary of the events at this year’s iPhone Dev Camp at the Yahoo headquarters this past weekend.

The Definitive Guide to iPhone App Market Sizing A good analysis of how to estimate the market for your next iPhone application.

How to Build an Apple Push Notification Provider Server A great tutorial on how to use the new push notification features of iPhone 3.0.

Postmortem: ngmoco/Demiurge Studios’ WordFu A great way to learn about application/game development is to learn from other’s successes and failures.

Apple Balks, Finally Relents, at Possible User Queries of Dictionary App Apple has been getting a lot of flack lately due to its removal of certain applications from the App Store. Read more about what one application went through.

iPhone Background Apps without Jailbreaking or Push Note: this is for educational purposes only. A great read for iPhone developers concerned with the security of App Store applications.

Rejected by Apple, iPhone Developers Go Underground Details on the other side of iPhone application development: jailbreaking and Cydia.

Top 5 Tips for iPhone App Icon Design

Sorry! It was Joe Conway, not Aaron who wrote the post. I've corrected the article below. The salient points are unchanged, but my apologies for mis-attributing

I knew that some developers didn't particularly care for Objective-C 2.0's dot notation, but I didn't realize how strongly some of them felt about it. Joe Conway of the Big Nerd Ranch has a very strongly worded post about the horrors of dot notation.

I have a lot of respect for Joe and the Big Nerd Ranch, and reading his post, I understand his complaints. He has identified some situations where dot notation can lead to confusion. In practice, however, I don't personally find the use of properties confusing in the slightest and think telling people to never, ever, ever use them is misguided imposition of a personal preference rather than sage advice. If there is anything close to a consensus on dot notation in the Objective-C developer community, it is that dot notation is a positive addition to the language.

Although, in terms of how they are implemented, dot notation and properties are orthogonal, I tend to think of them as working hand in hand. I always use dot notation for properties and bracket notation the rest of the time. Instead of making my code harder to read, I personally find that it makes it much easier. The only possible point of confusion I've had with this approach comes when accessing struct or union members owned by properties, but in practice, it just isn't a meaningful problem for me and it's offset by the benefit of separating exposure of state from exposure of behavior, something that has no language-level support in Objective-C prior to 2.0 and no language level support at all in most OO languages (though C# does, so kudos to Microsoft for that).

My only issue with dot notation, if you could call it an issue, is that since it doesn't mean exactly the same thing as it does in many other OO languages like Java or C++, it can be a bit of a stumbling block for experienced programmers who are new to Objective-C (and with the iPhone, there are a lot of those lately). It can be difficult for these people to make the transition because they subconsciously transfer their understanding of dot notation to Objective-C and think they understand something that they don't. The result of that is typically memory management problems that frustrate the hell out of them. But that's not really an issue with the language, it's just a training issue and hardly an insurmountable one. There are many happy, well-adjusted former C++ and Java programmers among the iPhone developer ranks.

So, keep in mind that although there are a few well-respected and knowledgeable developers who strongly dislike dot-notation, there are many more well-respected and knowledgeable developers who do use and like them (and I do too). You should definitely read Joe's post and give his opinion weight. He has been working with and teaching the language for quite some time and he's a really, really smart guy. But keep in mind that what you're reading is just one opinion.

Chris Hanson has a really handy post today. In the localization chapter of Beginning iPhone Development, we mentioned that Apple recommended using the ISO two letter language code for your localizations, but that Xcode used the older style language codes for your development base language. Chris shows how to work around this inconsistency.

I’m greatly pleased with Mobile Orchard’s sponsors. And not just for their money. Our sponsors make me smile because, without exception, they’re the kind of outfits that I want to succeed.

Our sponsors are what folks in my family would call good citizens — upstanding people who participate in our community, not corporate vampires trying to tap a vein. Examples:

Peter Bakhyryev wrote our tutorial on Networking and Bonjour on iPhone — at the moment, it’s our third most popular item, without mentioning his multi-player network gaming platform.

Without upping the price, Eddie Wilson has added 40 icons to his set bringing it up to 160 total. Coldly calculating an ROI for the additional time invested would likely show that he’s doing it because he’s passionate about building attractive UIs.

And the 360|iDev team offers what amounts to a $1000+ conference at half the price. Plus, they’ll knock 20% off the price if you take our iPhone OpenGL Class before the conference.

Here are their pitches:

	The iPhone UI icon set gives app developers an extensive library of icons for use in their Tab Bar and Tool Bar item objects. 160 png icons and a sample app for browsing the set - $69.
	360|iDev is the only iPhone developer conference you should attend. Okay, maybe WWDC too. For less than $500, you get 3 days with 40+ sessions from luminaries like Brent Simmons, Noel Llopis, Jonathan Saggau, Bill Dudney and more.
	ByteClub makes it easy to add online real-time and turn-based multiplayer capabilities to your iPhone games or multiuser apps. In some cases, you won’t even need to invest into hosting your own servers.

The networkpx Project Blog has an interesting post on doing multi-row delete under SDK 3.0. It's a good post, even if they do credit the excellent Cocoa with Love blog for "introducing" a technique that I demonstrated three months earlier.

Anyway, the ability to do multi-row delete is now built-into UITableView starting with SDK 3.0, meaning you can now implement multi-row delete it with just few lines of code. Yay.

Or, perhaps not.

Unfortunately, using this functionality requires you to return an undocumented UITableViewCellEditingStyle value from tableView:editingStyleForRowAtIndexPath: in order to turn this feature on. To fully utilize the functionality, you have to use and override other undocumented, private methods.

Technically, doing that in an application submitted to the App Store violates your SDK agreement and is grounds for having your application rejected.

Will your apps be rejected if you do it? Who knows? Maybe yes, maybe no. It's even possible that people using the older, manual technique will get their apps rejected for using private methods even though that technique doesn't, similar to the Coverflow debacle from last year.

Now, I'm not going to advise you whether to use this functionality in your apps. It's a risk, and you have to decide how risk tolerant you are. I am going to advise that if you have any desire to use this functionality at all, go now and open a bug report with Apple requesting that they make the multi-row delete functionality available to developers.

John Gruber says pretty much all that needs to be said on this. Not a sign that things are heading in the right direction, I"m afraid.

Our mutual admiration society with the good folks at the 360iDev Conference continues!

I’m pleased to say that we’ve arranged a 20%/$99 conference discount for attendees of Noel’s OpenGL iPhone Programming Class that immediately precedes the conference.

When you add up the discount to attend 360iDev, the discount we’re offering on our class to people who attend both, and our (still available) early-bird pricing you’ll save over $600.

360iDev is about half sold-out — that that’s the case this far our is impressive. Our last two classes have sold out before their early bird registration clocked out. Odds are good that both will be widely attended; good idea to register early.

Our class in the same hotel and the same discounted room rate applies.

To get the discount, register for the class and, once you do, we’ll send you a coupon code you can use when you register for 360iDev.