Sad Tales from the Android App Store

Makes you think twice before abandoning the iPhone, even with the hassles and review process problems, doesn't it?

Read more »

Click-to-Flash

Just thought this was an apropos time to mention Wolf Rentzsch's wonderful Click-to-Flash, which disables the Flash plug-in from working in your browser unless you specifically authorize it. It's a wonderful tool that any Mac user should have installed (except you Flash developers, of course).

Read more »

Flash Post Mortem

Okay, this is going to be my last word on Flash for a while. As fun as this has been, beyond this, I think that things will begin to get counterproductive and I have a lot of stuff I have to get done in the next few weeks.

I do appreciate everyone who took time to point out their perceived flaws in my argument, and to everyone who provided links and information about the Flash Platform with regards to the mobile web. Nothing I saw changed my mind about the future of Flash as a web development tool, but I feel better informed about Adobe's desperate attempts to hold onto the position they've carved out for themselves on the pre-mobile web.

Even if my predictions are completely wrong and Flash manages to survive as a dominant web development tool, it won't change my conviction that it's simply the wrong paradigm for the vast, vast majority of web development tasks. It's a fine tool for interactive presentations, kiosks, and limited cross-platform development. But for the web? It couldn't be a worse tool. Sorry. I know many of you disagree with me on this, but I've used a lot of web development tools and visited a lot of websites over the years on multiple platforms and Flash is just a back-asswards approach to web development. If Adobe changes the fundamental architecture of the platform, then I'm open to re-assessing Flash's worth, but until then, any enhancements or new features are nothing more than turd polishing. The shiniest, most jewel-encrusted turd, is still a turd.

But I'm completely unconvinced that Flash is going to survive the growth of the mobile web, at least as the dominant player it has been. Here's the thing that's missing. Adobe has created a consortium to get Flash on to "billions" of mobile devices. Who's not on that list right now? Apple and RIM, makers of Blackberry. When you look at the mobile web, either by units or packets transferred, those two have the lion's share of the market. Having a consortium to promote something on the mobile web without those two participating would be like having a consortium to develop standards for the regular web without including Microsoft. If you can't get at least one of them, and probably both, Flash is a dead end for the mobile web. That's just the political reality. Even if you can get RIM, you've still got the single largest smart phone in terms of units, packets transferred and, certainly, mindshare not participating in your "consortium". So, are companies going to want to do their sites one way for the iPhone and another for everyone else? Or are they going to start veering towards the open standards that will work on all devices? I think the slow move toward standards whenever feasible has already begun and eventually Flash will be left to handle the small number of niche jobs that can't be handled using Javascript/HTML/CSS.

On top of that, as long as Apple is in the position they're in with the iPhone not supporting Flash, other phone manufacturers are going to view mobile flash as "not mission critical", even if they join your consortium and let you put their logo on the consortium's web page. As long as that's true, these companies are going to view Flash as a potential marketing advantage and nothing more. They'll list it as a feature they have that the iPhone doesn't, but they're not going to expend huge resources making sure it's wonderful, because it's already been proven that people will buy smart phones that don't have Flash. These companies will do just enough to be able to put "Flash-enabled" in their ads and that's it. Again, it might not be right, but it is the political reality of how decisions are made at large companies. There's always too much to do and too few hours, and if you can't convince them all that Flash is mission critical, they're not going to pull resources away from other things to get it done.

Now, if Apple and RIM get onboard with Flash, that completely changes the political landscape. It won't change my mind about Flash being a poor choice for most types of web development, but it certainly will change its future viability substantially.

Read more »

Nested Arrays

I'm staying the heck away from talking about Flash for a while. ☺

In my quest for a good solution for handling table-based detail editing panes, I've been experimenting with using nested arrays to drive the table structure. A nested array is nothing more than an array of arrays (and I'm talking about NSArray instances here). The main or outer array contains one instance of NSArray for each section, and each subarray contains one object for each row in the section it represents. It takes multiple nested arrays to hold the structure of a table, with one nested array holding the labels, another holding the keys, and another holding the class of the controller class that can be used to edit that item. They're paired nested arrays, I guess.

This solution isn't quite as turnkey as the property-list driven solution I was working on earlier, but it's conceptually a lot easier to explain, and it doesn't squirrel away all the code I need to demonstrate into complex, generic classes. It's a hell of a lot better than having large nested switch statements in your controller class.

The entire process I'm developing will be shown in More iPhone 3 Development, but here's a category to make it easier to pull information out of a nested array in case you want to experiment on your own. This category adds a method to NSArray that lets you retrieve the right object from the nested array for a given NSIndexPath. Note that this category, like the table views it was created to support, supports only simple index paths that store a row and a section.

NSArray-NestedArray.h

//
//  NSArray-NestedArrays.h
#import <Foundation/Foundation.h>


@interface NSArray(NestedArrays)
/*!
 This method will return an object contained with an array 
 contained within this array. It is intended to allow 
 single-step retrieval of objects in the nested array 
 using an index path
 */
- (id)nestedObjectAtIndexPath:(NSIndexPath *)indexPath;
@end

NSArray-NestedArray.m

//
//  NSArray-NestedArrays.m
#import "NSArray-NestedArrays.h"

@implementation NSArray(NestedArrays)
- (id)nestedObjectAtIndexPath:(NSIndexPath *)indexPath {
    NSUInteger row = [indexPath row];
    NSUInteger section = [indexPath section];
    NSArray *subArray = [self objectAtIndex:section];
    
    if (![subArray isKindOfClass:[NSArray class]])
        return nil;
    
    if (row >= [subArray count])
        return nil;
    
    return [subArray objectAtIndex:row];
}
@end

Read more »

Just a Few More Vacation Thoughts

Wow. I really didn't expect this kind of response. I see that my original Flash rant is up to 29 comments. I'm a little scared to read the ones I haven't read when I finally get back from vacation. I really seem to have pissed off a lot of people. That honestly was never my intention.

To some extent, I regret the "Flash Sucks" part of the discussion. Not because it's necessarily untrue, though: It's my honest opinion of Flash on Mac OS X - it's leaky, crash-prone and, well... sucks. But, I regret it because that statement has detracted from the real discussion that's been going on underneath it all. It seems to me that many Flash proponents are trying to write me off as "just another run-of-the-mill Flash Hater" predicting the demise of Flash "yet again". The same old story, nothing to see here. Move along, move along.

But I'm not a run-of-the-mill Flash hater, and I'm not predicting Flash's demise because I hate it. I'm not even predicting Flash's total demise, just the demise of Flash cum general purpose web-development tool. And my predictions are the result of a fairly thorough knowledge of the history of web development and a reasonably educated guess about where things are likely going next.

And you know what? Flash is the completely wrong approach for a general-purpose web development tool. Flash's current approach is anathema to what has become fairly widely recognized as good web development practices. The fact that Flash is fun or easy, or that the tools are great doesn't change that it is fundamentally flawed approach to doing web development.

And, believe it or not, I'm going on about this for the opposite motivation from hate. I'm dwelling on this because I don't want the many excellent Flash and Flex developers I've met to get screwed if the walls do come crumbling down. I can tell you stories about programmers I've known who spent a career working in PL360 or COBOL, only to find themselves without a job and with a skillset that was completely obsolete and not marketable. Take a look at this list and tell me how many languages you recognize. Languages go obsolete all the time. Some of the ones that have gone obsolete were bigger stars in their day than Flash is now.

Right now, we have fifteen years of web development evolution to look back upon. It's now a fairly mature space, and we are at a point where we have a pretty good idea of what things have worked and are sustainable and scaleable. We also have a pretty good idea of what things have not worked. And though you might disagree with me, when I look at the web technologies that have survived, the Flash plug-in is an anomaly. If the web is headed where it looks like it's headed, it's hard for me to see how Flash can continue to remain as relevant as it has up until now. That's not hate, that's just reality.

You can do so much more with HTML and Javascript today than you could a decade ago, or even a couple of years ago. With the exception of certain types of online games, the vast majority of what Flash is used for on the web can already be done in HTML and Javascript without waiting for HTML5 (combined, of course, with server-side development of some sort). The situations where Flash is truly necessary are dwindling, and Flash's uptake in the area of greatest growth (the mobile web) has been lackluster at best. "Dismal" is probably a better adjective than "lackluster" to describe the mobile Flash uptake.

There might be a silver lining here, but I don't see it. Adobe's done too little too late when it comes to opening up Flash, and has done too little too late in the mobile realm period. Adobe can send out press releases about "billions of Flash-enabled mobile devices" till the cows come home, but it's simply not reality. It's just marketing types playing with semantics. Companies only mince words when they have something to hide. To a consumer, a Flash-enabled mobile device is one that can access most any Flash content that's anywhere on the web just as if they were at home on their computer. There aren't billions of devices that can do that. There aren't any devices that can do that yet.

And think of this. If Flash somehow maintains or increases its prevalence as a web development tool going forward, I'll have been wrong in a couple of blog postings on the Internet. If I'm right, an awful lot of people are going to be finding their skills less and less relevant and less and less marketable.

I've been wrong before. I can live with being wrong. But what if it turns out I am right? What if it turns out that after 26 years of being online¹ and keeping abreast of the technology involved in online communications I actually know something about it? What if these rants aren't the result of hatred but are rather just an honest assessment of Flash's current place in a complex and ever-changing technology landscape? If you're a Flash developer, especially if Flash development is your only marketable software development skill, well… just make sure you can live with me being right. I'll continue to be able to put food on the table if I'm wrong about this. Please make sure you can say the same thing.

Just as an aside: I left my last full-time gig (at PeopleSoft) in 2002. I'm not sure if you remember, but 2002 was a pretty crappy economy. Not as bad as today overall, but it was a pretty rough time for programmers and software consultants because the dot com boom and subsequent bust had created a glut of tech workers. I started my first project as an independent consultant only four days after walking out the doors at PeopleSoft (two of which were a weekend). After that project (knock on wood) I've found steady work with very little unplanned downtime. The work hasn't always been in my preferred language or using my preferred tools, but I've always found work quickly because my most marketable skill is that I have a varied toolbox, an understanding of what tools exist outside of my toolbox, and a willingness to expand my toolbox if that's what I need to do to get a job done right. Languages and environments come and go. Don't tie your fortunes too tightly to something that can become obsolete unless you want to risk becoming obsolete yourself.

---

1 - I got my first modem in 1983, a hand-me-down acoustically coupled modem from a friend's dad who was a college professor. It was replaced less than a year later with a Hayes-compatible 1200 baud model. I had my first internet e-mail address in 1986 (a fidonet address through a BBS I called using PCPursuit), and I got first true Internet account in 1988 (a Unix shell account through my university that I accessed using Kemit). I had my first PPP internet account in 1992: a metered account through a company called holonet.

Read more »

You Guys Rock

A lot of you disagree with me on my Flash assessment and your comments have been great. Unfortunately, I really do need to get back to my vacation. Do please feel free to keep knocking down my arguments in the comments, though.

I want to leave with this definition that I tweeted a minute ago, because this is the crux of my point in the last point. I'm really not hoping Flash dies, but I do fear for the hammer developers in the Flash world because there's at least some chance of the platform becoming obsolete. We can argue all night about how great those chances are, but given the current environment, the chance is at very least greater than zero.

A "hammer developer" is a developer who has only ever learned one language and development framework. With only one tool in their box, every problem looks like a nail. It's the hammer developer that's responsible for sites like Disney's, where even basic things that HTML has been able to handle for years (like navigation bars) are done in Flash.

Hammer developers are the ones who have the hardest time when a technology does become obsolete. Even if you love Flash, don't be a hammer developer. Seriously. Diversify your toolset, even if you love one particular one. No toolset is guaranteed to be around forever.

And, yes, hammer developers exist in every developer community. I'm only singling the Flash community out because the platform sits in a unique position at this point in time. Flash has a lot of baggage from a different era and I'm not sure Adobe really understands what must be done for Flash to remain viable. Maybe they do, but are you willing to bet your income on it?

Read more »

Flash is Dead! Long Live Flash!

I am on vacation.

I did not intend to do a blog post while on vacation, but I feel like I need more than 140 characters to explain my recent twitter rants. We're having a quiet night after several days in the Disney parks, so it's a good opportunity to expand on these recent tweets, since the twitter versions, limited to 140 characters, are evoking a lot of anger.

The Spark

While at Disney World's Magic Kingdom, I wanted to look something up on Disney's website. Navigating to one of the Disney.com web pages using my iPhone resulted in an error page. That's right, I thought to myself, Disney uses Flash for almost everything, don't they.

I'm not thrilled about a company doing that, but that's absolutely not the thing that set me off. It was the fact that Disney's explanation for why I couldn't view their page was that I wasn't using a "Standards compliant browser".

Now, say what you will about Mobile Safari, but one accusation you can't reasonably level at it is that it isn't Standards-compliant. It's based on WebKit, and WebKit fully passes the Acid3 test. It's as standards-compliant as any browser, certainly any mobile browser. It's a hell of a lot more "standards compliant" than IE5 (look at the screenshot).

Disney is, basically, putting the blame on the user for their decision to require Flash on their website, and using made-up statistics to make the user sound like an anomaly. A weirdo. C'mon, be cool like 99.9% of our viewers! Yet, they couch it in language that SOUNDS like good customer service (we want to help). Crikey!

Out of Place

Now, I find this odd. For all of their faults, Disney tends to be incredibly good at not insulting their customers. Some of the best customer service I've ever seen has been within the 47 square miles owned by the Disney corporation in Central Florida. Seriously. I'm not exaggerating here at all. Disney castmembers bend over backwards to accommodate their customers and the company has been incredibly progressive over the last thirty years or so in their treatment of customers. When they do screw up, they're usually quick to apologize and do everything possible to rectify the situation.

I had a situation with park security several years back. The details aren't important, but I was accused of doing something illegal (in front of my children and many, many strangers) in a situation where it would have been physically impossible for me (or anyone) to have done the thing I was accused of. The situation was rectified quickly once I asked for management involvement, and I was sent on my way with a sincere-sounding apology. When I got home from vacation, I received a box of gifts for my children with a hand-written apology from a VP. A few days later, I received another apology by phone and was given specific information about changes that would be made to their training to make sure that same situation didn't happen again.

That relatively minor situation, if handled wrong, could easily have ended with me never wanting to do business with Disney again. But, it didn't, because they handled it right. Whether any of the apologies were sincere or not makes absolutely no difference. They acknowledged that they had made a mistake, apologized to me for making it, and then followed up afterwards to see if I needed anything. It wouldn't be reasonable to ask for or expect more than that. And to their benefit, Disney Management did not blame or scapegoat the castmember, either. They recognized it was their responsibility to train their castmembers for foreseeable encounters, and that they had failed.

As a result, I have been back to Disney World several times since then. I've never had another serious situation myself, but I've become acutely aware of how this company handles customer service, and often notice little details about the way the Disney castmembers treat people that probably go unnoticed by most people visiting the parks and hotels. With only rare exceptions, Disney does a phenomenal job interacting with their customers.

Except online.

When it comes to the online world, they seem to act with a much more typical corporate attitude, one that, if they were a person, would probably be labeled "arrogance".

So, anyway, my inability to look up something on Disney's website from my iPhone while standing in a Disney park led to my recent twitter-rant about Flash. It was a somewhat adolescent but very cathartic outburst that can basically be summed up as

• Flash sucks
• Flash is not a standard, and
• Flash sucks

Oddly enough, these comments seemed to hit a nerve with a lot of people. I probably should have expected that - one of the more prevalent backgrounds in the iPhone developer community is that of Flash/Flex developer, but I really didn't expect people to take it quite as personally as they did. The only other place I've seen people take criticism of a language or development environment so personally is when I've dared to criticize .Net or, before .Net existed, Visual Basic.

The next twenty-four hours or so after my twitter-rant saw a fair number of replies, including several ad hominem attacks and many factually incorrect assertions about Flash being a standard, along with a lot of "the iPhone is FAIL cuz it don't support Flash" kinds of statements.

Let me just clarify my comments a bit and explain them in more rational terms here.

Flash is Dead

I hate to break it to you, but Flash, as it currently exists, is dead. Oh, it's not going to die quickly, it's going to die a slow painful death precisely because there has been such a large investment of time and money into using it by so many large corporations like Disney. Flash's roots run way too deep for it to disappear quickly.

Here's the thing, though: Flash is a product of a different generation of computing. It's a product of a world where 90% of the people used one platform, and the bulk of the remaining used another. There was Windows, and there was the Mac. And then Linux gained some popularity and became a viable platform, yet for a long time, Linux users couldn't access Flash web sites. Eventually, Linux got Flash too.

But Adobe never lavished the kind of love on the Linux or Mac versions of the Flash plug-in that they did on the Windows version, and less-popular options were SOL because Flash is a proprietary platform.

And now, the world is changing. People are increasingly browsing the web from mobile devices, and unlike the computer world of a decade ago, the mobile computing landscape is not anything like a monoculture or monopoly. There are several viable mobile platforms all competing in that space. We have the iPhone, Blackberry, Palm Pre, Windows Mobile, Android, Symbian and probably others that have slipped my mind. All of these are operating systems currently shipping on phones and all come with browsers. None of them, except a solitary model of Android phone, has Flash.

Do you think Adobe is hard at work writing Flash virtual machines for every possible configuration of hardware and software that exists in the mobile space. Hell, no! They're not even willing to fix the massive memory leaks in the OS X Flash plugin. No, they're going to wait for one or two clear leaders to emerge and then, if they can, and if their MBAs decide there's a sufficient ROI in doing so, then they'll develop Flash for those platforms.

If no clear victors emerge, who knows what we'll see. It's unlikely we'll ever see Flash on the iPhone¹. Flash on the Hero is painfully slow and clunky. And, Adobe is also unlikely to ever devote the resources necessary to fully develop and maintain versions for even the platforms they do decide to support. They're going to do the least they can do to say that Flash is part of the mobile web, and that's it.

What I mean by Sucks

When I say that Flash sucks, I'm not talking about ActionScript or the developer tools or anything of that nature. I'm not a Flash developer and never have been. Developing for Flash might be better than receiving oral sex for all I know. When I say that Flash sucks, I'm specifically referring to the leaky, crash-prone implementation of Flash available for Mac OS X. I'm selfish; I rant about things that affect me. And Flash definitely affects me. I'm talking about something that is the polar opposite of a "thin-client" - Flash is a client that can suck up 60% of processor cycles on a high-end machines to run a recreation a a 40-year old arcade game. I'm talking about a technology that is more likely to bring up the SBBD than any other piece of Mac software. Flash on Windows is tolerable (barely), but even on a fast Mac, it can be a horrible, horrible experience to have even a single Flash item on a web page. Every Safari crash I've had in recent memory was directly caused by the Flash plug-in.

I'm absolutely not saying that Flash developers are bad people. I'm absolutely not saying they're dumb. I had no intention of saying a single thing about Flash developers at all. My intentions was just to point out one of the problems of treating Flash as if it were a "de facto Standard" and using it as a general-purpose web-development tool. Flash is controlled by a single-company. It's got the same Achille's Heel as every other proprietary solution (including several Apple technologies like Quicktime, iTunes, and the iPhone SDK). For web development, that was sort of okay when there were only three operating systems to write for and one of them had most of the market share.

I'm not even saying proprietary is always bad. I love my proprietary iPhone and Mac, and you can pry them from my cold dead fingers. But, I wouldn't ever advocate only supporting the iPhone or the Mac on your web site simply because I love them. The whole point of the web is that it's platform agnostic (or, if you buy into Google's point of view, it IS the platform). When you put something on the web, it should be readable by any device that can get on the internet. Your site should use open standards so that the developers for platforms that can't already view your content have the ability to implement that functionality for their users simply by referring to the standard. You should only use a proprietary option like Flash when you have a compelling reason to do so. Implementing a drop-down menu in your navigation bar is NEVER a compelling reason. If something can be done with Javacript and HTML, you'd better have a damn good solid reason for doing it in Flash (or any other proprietary solution, for that matter) rather than using standards-compliant tools, and that reason had better not be "it's what our developer knows/likes" or "it was convenient".

Degrade Gracefully

Someone responded to my Twitter rant by pointing out the crux of the original problem: when you put something on the web, it should at very least degrade gracefully. This is just common sense. If you detect that a browser can't support some feature you use, don't assume it's because your user is running old software. It's just as likely that they're running newer software that wasn't around when you wrote your detection algorithm. Don't make any assumptions or implications in your error page. Just describe, in as much detail as possible, what the problem is and apologize for the inconvenience. That's all. You don't need to explain or defend your choice. Treat your virtual customers the same way you would treat real ones in person. If you've made a decision that will inconvenience some of your customers, man up and live with it, don't try to place the blame back on your user for your fracking decision.

The Future of Flash

I understand what causes some of these attacks I've received. I really do: panic. When people point out to a Flash developer the fact that Flash is not well-positioned for the future, increasingly mobile Web, Flash developers feel a rush of panic. They go into defensive mode. They want those statements to be wrong. They don't like the fact that something they like and have invested a lot of time and energy into might be obsolete in a few short years. This isn't anything unique to Flash. I've seen it before many times. Some people manage to hang on by finding niche work (hell, I know full-time Cobol developers), others (sometimes grudgingly) move to other technologies, while others, like the many NextSTEP developers out there who got a second chance with Mac OS X, and a third chance with the iPhone, get a reprieve.

Hell, I never thought I'd find a way to code in Objective-C for a living. It was a dying language when I started learning it. I didn't learn it because it would make me money², I learned it because I saw something in it that I thought was right. I learned it because I wanted to be able to write code that was as good as the code that I saw from the NeXT developers.

What will happen with Flash? Hell if I know. My current level of confidence in Adobe is not very high. The management team there has somehow managed to take a customer base who were rabidly loyal and turn them into customers who feel trapped and desperately want an alternative. This has happened in less than a decade. Talk about spending political capital! Somewhere along the line, Adobe stopped being a company that did, first and foremost, what their customers needed, and instead became a company that looked to make the most money they could with the least expenditure. It's a short-term strategy taught in many business schools (including Harvard) using impressive-sounding phrases like "maximizing shareholder value". Yet, it's a strategy that anyone with any common sense (aka not an MBA) knows is completely and utterly moronic. In the long-term, rabidly loyal fans are far better than great salespeople. They're better than good advertising campaigns, slogans, or even Superbowl ads. They're better than product placement in a summer blockbuster.

And you can't buy them for any price.

Any management team that can do what Adobe's has done in the past ten years truly deserves to die. Frankly, I wouldn't bet on them doing the right thing in any particular situation, including this one.

But, that doesn't mean there's no hope. There are many ways that Adobe could save Flash/Flex for the mobile world. One way would be to create something like Google's GWT - an environment where some or all of the code gets translated into HTML and Javascript to be run on the client, leaving to a VM only those tasks that can't reasonably be handled that way.

With the determination to do it, and the willingness to recognize that the world has, indeed, changed, Adobe could future-proof Flash/Flex code. It would be a hell of a first step back to having rabidly loyal fans. As an aside, a Carbon-free, 64-bit clean, GCD-enabled Photoshop would be another big step in that direction.

Learning is Cool

But, even if Adobe continues to be Adobe, all is not lost. You may like a lot of things about Flash/Flex and ActionScript, but learning a new language and new frameworks is very possible. In fact, it's a lot of fun. It's an adventure. The really hard, brain-bending stuff is the conceptual stuff, much of which you've already got worked out from learning to develop in ActionScript. Heck, don't even wait for Flash to die! Cross-training is good for developers, and you should look forward to an opportunity to see how different languages and frameworks have solved the same problems. You'd be surprised at how much you can use from other languages when writing code.

And if you face the prospect of learning a new language with more than a little trepidation, maybe software development is not the right line of work for you. And I mean that very seriously.

---

1 - If Adobe manages to come up with a 64-bit clean, GCD-enabled Photoshop, then all bets are off.
2 - A joke from a few years back that I heard from Mike Lee jumps to mind here. What's the difference between a Cocoa developer and a large pizza? A large pizza can still feed a family of four.

Read more »

Preview: Madden 10

Madden 10 is the upcoming NFL game from Electronic Arts. Here are some of the key features about what to look forward to. This looks like a game not to miss when it is released, hopefully in early September.

Product Description
THE #1 SELLING FOOTBALL GAME OF ALL TIME IS ABOUT TO HIT THE APP STORESM. GAME ON.
ACCEPT NO IMITATIONS ─ only EA SPORTS™ delivers the most authentic, hard-hitting experience in football, and we’ve got the history to back it up.
Combining the realistic action that Madden NFL fans expect with the mobile gameplay that allows anyone to pick-up and play – Madden NFL 10 brings the ultimate football experience to the App Store.

Key Features
• TAKE IT TO THE GRIDIRON ─ Dominate the field with packed rosters of your favorite NFL players from all 32 licensed teams.

• THE REAL DEAL ─ From Lambeau to Heinz, you’ll be impressed by the detail throughout this game. Play in authentic stadiums against life-like players on real NFL teams.

• CREATE YOUR OWN PLAY ─ Use touch controls to draw hot routes for passing plays, exclusive to Madden NFL 10.

• ACTION CONTROL TIME ─ This cool feature lets you adjust the speed of your game whenever you want, giving you time to pick the best moves for each play.

• SEASON MODE ─ Play a quick one-off game, or try the robust season mode, which features in-depth trades, stats and individual player rewards.

• ASSEMBLE YOUR OWN TEAMS ─ Detailed roster management gives you full control over depth charts, cross-team trading, and access to huge free agent pools.

• BROADCAST COMMENTARY ─ Hear the unmistakable voice of John Madden himself along with legendary announcers Tom Hammond and Cris Collinsworth.

Read more »

To Autorotate or Not to Autorotate

Toby Joe Boudreaux has a great post today about one shortcoming of autorotation on the iPhone, which is when you try to use an application that supports autorotation laying down. In that scenario, the phone often doesn't do what you expect it to do and it can be a pain. Toby Joe shows how to allow your users to turn off autorotation from within your app.

Read more »

iPhone Sketch Book Mini-Review

Well, only one day after finding out about the iPhone Sketch Book, one showed up in the mail. Very nice. The stencil I ordered a week and a half ago still hasn't shown up, so Kapsoft, the creators of the iPhone Sketch Book are already getting brownie points by being prompt.

The sketch book itself is quite nice. The cover design is professional looking, although the pink eraser and #2 pencil seemed out of place to me. Personally, those objects tend to make me think of elementary school as opposed to professional design. I probably would have opted for a mechanical pencil myself, but that's a tiny quibble if ever there was one. I know many people do, in fact, use #2 pencils and rubber erasers to do their designs.

The binding is a wire coil binding, which means it will lay flat on any page, which is a nice feature. Because it's a wire coil, the book will lay flat without having problems with pages coming loose like you have with plastic comb bindings.

The individual pages are nice. I'll be honest with you, I've been a sucker for graph paper since I was a kid. I loved it even before I started playing Dungeons & Dragons in the late seventies, and that hobby really reinforced my feelings for it. It's been years (decades, actually) since I've mapped out a dungeon on graph paper, but I still love graph paper, so I was thrilled to see that the background of each page is light-blue quad graph. And it's not that horrible 1/4" grid stuff, either. The grids are nice and small. And my love of graph paper isn't completely irrational. It gives you both vertical and horizontal guides for drawing shapes and letters, which lets someone with poor handwriting (like, say, me) to create something not completely horrible looking, which is nice if you're going to show something to a client.

The center of each page is an illustration of an iPhone drawn exactly to scale, which can be good or bad depending on your ability to draw small. There's a status bar at the top, and a black line at the bottom, the rest of the space is blank, ready for your designs.

And here's my one real quibble with the notebook. The status bar and the line at the bottom (that I assume is for a toolbar - it's too small for the Dock or for a tab bar) should have been drawn in non-photo blue like the background grid rather than in black. In any given application, a substantial portion of my views are unlikely to use a tool bar, and some applications won't show the status bar. Ideally, there should be light blue guides for tool bar, tab bar, nav bar, and status bar, but no black inside the iPhone's screen. It's not a huge deal, but I would definitely recommend that version 2.0 remove all black lines inside the screen space and replaces them with a light blue or light grey guideline that won't draw the eye if not used.

Other than that, though, the paper is thick and high quality, and the whole package gives off a professional air. I would not have any hesitation in showing a client designs from the sketchbook whatsoever. The book is thinner than the clipboard I currently use, so I plan to put my copy to good use.

Other recommendations I have for future versions of the iPhone Sketch Book: a version with the phone at 1.5 scale so it can work with the stencil, and one with the iPhone illustration only on the right-side pages, leaving the left side as just graph paper so that the developer has more space for notes about the view.

Read more »

Another Pimp My Code

Wil Shipley has another installment up in his Pimp my Code series of blog postings. Wil's blog is on my very short "must read" list, so I'm heading off to read this one. You should to.

Yes, I know that on a few subject areas (unit testing, use of the oxford semicolon) Wil argues against the widely accepted view, but Wil's been coding Objective-C almost as long as anybody, so it's always worth reading what he has to say, even if people occasionally disagree with some of it.

Read more »

Minigore

iTunes Link

Minigore is a survival shooter by Chillingo. $0.99

Minigore is the latest survival shooter game from the publishers who brought the the hit iDracula. This time everything has been given a cute touch over with a brilliant cartoon world to frolic and play in, or is it? Minigore probably isn't as in depth at this stage as iDracula, but great graphics and alleged future updates bringing more amazing characters like Enviro-Bear and Lizzie from Sway should improve the game. What makes this game good though is the brilliant graphics and sound effects coupled with the easy pick up and play nature of this game. But is it worth it at its current price? Keep reading to find out if I think it does the game justice.

Minigore has, as I said above, great graphics that really make this game feel like it is a feel good game with bunny wabbits and love hearts. This is certainly proved wrong when you find yourself, a 3D human, running around beautifully created trees and bushes escaping and shooting various sized black blobs of evil. This game is almost all in 3D, with some bushes etc. being in 2D, but it looks absolutely amazing. There are no dodgy points in the game with everything from the smallest evil blob to the raging animal version of John Gore being beautifully hand crafted for the iDevice. I found this better graphically than iDracula, with that not as clear and colorful as Minigore.

Minigore has some brilliant sound effects that don't seem to fit the shooter genre but work so well. Basically you have small popping noises everytime you fire your gun and the random roar when you kill the bigger black blobs. John Gore also has some input with a witty comment about that game that can give you a bit of a giggle and make you lose concentration. One example I found of this is, "Oh come on, how many of these are there? I've already killed 100 of them!"

This game is pretty easy to get the hang of straight away. The controls are as simple as it gets, yet the game is really challenging. The only controls in this game are two D-Pads which are located on the bottom of the screen. One lets you control where John Gore moves around and the other lets you choose where and when to shoot. The controls are similar to iDracula but are slightly different in the way the D-Pads work.

What I felt disappointed by the most in Minigore is the lack of content. Even in iDracula's first version the ranks and multiple game modes kept me coming back for more. Minigore only has one game mode with two difficulty levels. This is a bit disappointing and even though it is quite fun, doesn't give me much game time. I am now finding myself after a few weeks with limited play hoping for more game modes, basically hoping they deliver with good updates to the game. The aim of Minigore is go around the landscape and kill as many blobs as possible without dieing. This is quite hard as you only have two lives as such. The first time you are touched by a blob you lose some of your clothes and get some cool cuts and such. The second time you keel over and die while the blobs seem to swarm around your body. This is an entertaining game that will last you a good five minutes on both easy or hard and the willingness to improve will keep bringing you back to this game.

Minigore is a fun and hilarious pick up and play shooter which will be a joy to play for all those many fans of iDracula. While the amount of gameplay of Minigore isn't where I think it should be as of yet, the future updates should hopefully bring this game up to scratch and be a amazing, not just great, shooter. Once again Chillingo have picked a great title to publish and hopefully this success can bring Mountain Sheep to create many more great titles with the same level of love and care put into the life of John Gore.

Gameplay- 7/10

Graphics- 9.5/10

Sound- 9/10

Overall- 8/10

I would recommend this game if you enjoyed- iDracula

Tell me what you think about this review at Twitter- http://www.twitter.com/iPhone_Reviews next up is Madden Preview

Thanks- iPhone_Reviews

Read more »

Guitar Rock Tour 2

iTunes Link

Guitar Rock Tour 2 is a music game by Gameloft. $4.99

[A modified post from TheAppEra]

This sequel certainly isn't as good as the original, its way better!

Guitar Rock Tour was Gameloft's answer to the might of Tapulous and the Tap Tap Revenge series. However, what Guitar Rock Tour actually brought to the table was multiple big name songs ala Guitar Hero. I thoroughly enjoyed the game with hits from some of my favorite bands like Blink-182 and Good Charlotte, but the sequel smashes all of this out of the ballpark. Wanna find out why?

Guitar Rock Tour 2 is basically the original + more tracks + a better career mode + better graphics + Downloadable Content + Wolfmother. Yes, GRT 2 basically outdoes the original in all possible ways meaning its not just the same game with some new songs so Gameloft can make a quick $100k. After a somewhat letdown in DJ Mix Tour Gameloft has redeemed themselves with this game.

Guitar Rock Tour 2 smashes the sequel in all standards of graphics and sound. While you wouldn't expect the sound to be much different apart from the songs there is quite a bit. In the original game quite a few tracks was the proper song but it wasn't sung by the actual band who produced it. This game seems to have quite a large number of tracks that ARE the original tracks. Having this makes it alot better because the songs are better interpreted and perceived by its original artists.

The graphics in this game have been stepped up a notch from the previous version. The graphics are spectacular with a great live performance environment in the background coupled with the smooth gameplay below. The background consists of various band members rocking their stuff in a kind of music video with special effects and locations for each city you travel to.

There are many choices as to who is playing in your band as well as the guitar/drums that you play. The actual game itself has been improved with flasher buttons and special skills that have been given that graphical edge. The performance of the game has also been greatly improved with less likelihood of lag in the game.

As you can guess the controls are pretty simple and stay the same from the original. To play you must tap and sometimes hold the beats as they come down the screen. When you get so many fire power beats in a row you get the option of flicking one of two switches. One of these activates double score and lets you rock hard for so many seconds. The other one lets you regain your fans if you have been missing some notes recently. The drums are slightly different in that you must hit the drums as the notes hit the required area and the double points option comes on automatically so you don't have to worry about it.

The game has been ramped up to have a better career mode to play around with. Previously, the games have only featured a set list before moving onto the next location. Now this time there are also optional assignments to complete that involve tasks like getting a certain % accuracy or not missing any of the solo beats. This greatly adds to the experience and puts a bit more of a challenge.

There are 18 famous songs to rock out to ranging from Sweet Home Alabama to Nine in the Afternoon. These can be played at any time in quick play as long as you have played it once in career mode. Once played in career mode for either drums or guitar, it is unlocked for free play in all difficulties on both instruments. This is good for practice if you are stuck getting an assignment completed or if you just want to rock out to your favourite track.

A new part of the game is the 'solo' section of the track where you are the only guitarist playing the song. In here you get double points (And if you already have the double points mode on can get up to 16x multiplier), and if you get 100% of the notes a nice bonus will be added onto your score after completing the solo. This is crucial to getting higher scores for each of the songs as you keep the double points until you miss a beat, even after the solo is finished.

Finally the other new part of the game is coming soon, but its going to be downloadable song packs which I assume will have an extended career mode and be priced for $1 or $2. These will be great for those wanting to play a bit more of Guitar Rock Tour.

Guitar Rock Tour 2 is matched what the original was, with some hefty bonuses on the side. While my personal preferences to song choice lie with original artist tracks, they are not too shabby. With the added DLC coming soon, this will hopefully diversify what I'm looking for with a more Punk/Rock style of music to tap along to.

This game is amazing and should be picked up by any fan of the Tap Tap Revenge or similar games. Fans of the sequel and DJ Mix Tour will crave this game and won't be able to stop rockin' with the music!

Gameplay- 8/10

Graphics- 9.5/10

Sound- 9/10

Overall- 9/10

I would recommend this game if you enjoyed- Guitar Rock Tour

Tell me what you think about this review at Twitter- http://www.twitter.com/iPhone_Reviews next up is Minigore

Thanks- iPhone_Reviews

Read more »

Property-List Driven Detail Editing Pane

A while back, I discussed using a property list to drive a table-based detail editing pane. I had intended to use this code in a sample project in More iPhone Development. I still feel strongly that this is a good approach, and when I have some time, plan to work on it more. However, from a pedagogical standpoint, it wasn't working for me. All of the code I needed to demonstrate was getting moved to generic classes and the main point was getting lost in a confusing mess of classes.

Therefore, since it's not going to be used in the book, I'm releasing the code for people to look at and use (no restrictions or requirements). Please note, however, that this is NOT production quality code, so caveat emptor. If you want to use this in a real application, expect to sink some time into extending and debugging. In the long run, I think you'll be happier than maintaining huge sets of nested case statements, however.

You can find the project here.

Read more »

Interesting...

Here's an interesting post on how to get an iPhone-like interface in your WinMo application. It seems like a lot of work to get the functionality you'd get for "free" if you created an iPhone application. My first thought was that I didn't think it was a good sign for the Windows Mobile community that an article like this even exists. It felt like SDK-envy to me.

But then I thought about it some more. As somebody who spent years programming for my non-preferred platform, I really do applaud an effort to work around the limitations of a platform in order to create something that's better, even if it takes a lot more work. I also applaud the willingness to borrow good things from other platforms, as long as the goal isn't to be "as good" as the other platform. Shooting for "as good" never results in greatness, but recognizing that there is a better way can be the first step toward it.

In the long run, maybe it's a really good thing for the WinMo community that you have people who want to create apps with interfaces that are better than the standard WinMo user interface and are willing to put in extra effort to do it. There are definitely signs of life in the WinMo developer community. And, if you think about it, every .Net developer out there is a potential WinMo developer, so with some smart non-Balmer-esque management decisions, Microsoft could capitalize on that base of developers and the apparent desire of at least some of them to create something really good to catapult WinMo solidly back into the fray.

Alas, the chances of any non-Balmer-esque management decisions is not particularly good, but one can hope.

Read more »

Nice iPhone Application Idea.

I don't often post about specific non-developer iPhone applications, but this is just too neat not to mention. Very nice, and a great price to boot.

Read more »

iPhone Sketch Book

I just found out about the iPhone Application Sketch Book, a product aimed firmly at iPhone developers.

It looks like I may get a chance to review one of these, so probably when I get back from vacation I'll post my impressions of the actual product.

It's going to get bonus points if the template matches in size the iPhone Stencil Kit I ordered last week.

(yes, I like doing designs using analog tools, sue me)

Read more »

Blocks on iPhone

I really do no need to start writing, but just one more thing that came out of last Thursday's meetup. We talked a little about when some of the cool Snow Leopard features like Blocks and Grand Central Dispatch might be coming to the iPhone.

Again, I'm purely speculating, but I think we will see blocks sooner rather than later, maybe in iPhone SDK 3.5. Grand Central Dispatch is harder to predict. Although there is some value in it now, since the iPhone has two processors - a CPU and a GPU - the real power of GCD comes with even more processing cores, and I have no idea if or when we'll get a multi-core iPhone.

But, blocks? Blocks on the iPhone would be cool, and you know what? You don't have to wait.

Sure, by using this, you don't get block support in the Foundation and UIKit classes, but you do get blocks, and you can always create categories to add block-based methods to existing classes, so you might want to check it out.

Read more »

On iPhone Competitors

At the New York City iPhone Meetup last week, Steve Kochan and I were tasked with talking about the future of the iPhone and the iPhone SDK. I'm not sure either of us were particularly qualified to speak on that. I'm not being modest; I'm not sure anybody outside of One Infinite Loop is qualified to speak about that, and anybody who is qualified is almost certainly not allowed to speak about it. But everybody's got ideas of where things should go and where they might go, so we talked for a little while about some of the things we might see in a hypothetical iPhone SDK 4 or in the next generation of iPhone OS devices.

First of all, I hope nobody took anything I said as gospel. Although I do know a small handful of people inside Apple, none of them are close enough friends that they'd be willing to risk their jobs by giving me secret information, and if any of them did give me secret information, I wouldn't stand up in front of a group of people and spill that secret. I do NOT know what will be coming out when. I don't know if there will be a tablet, or what it will look like. As far as hardware is concerned, I don't know what the future holds at all, and as far as software is concerned, I don't know all that much that hasn't already been made public. I don't know that we'll get garbage collection or, at least, I don't know when we'll get it. I know Apple is capable of delivering a tablet. I highly suspect that they've prototyped several ideas, but Apple prototypes lots of ideas that are never turned into actual products. I know that there are indications of a move toward a completely resolution independent OS, but that's not a secret. Apple has been moving that way for quite some time in the Mac OS, since even before the iPhone OS was forked off.

So, just for the record, anything I said last Thursday night was pure speculation. Do not buy stock based on it, or spread anything I said as if it came from somebody who actually knows something.

And with that out of the way, I noticed that John Gruber has tackled one topic we discussed at the end of the night, which has to do with challengers to the iPhone throne. John's specifically speaking to the Android platform in his posting while we were talking about a handful of platforms, including Palm, RIM, Android, and Microsoft, but a lot of what he says echos what I said during that discussion. And John has a much, much better track record than I do with regard to making predictions about technology and specifically about Apple, so for that part of the discussion, at least, I feel like I was on fairly solid ground.

Read more »

Workshop Done

I am back home, at my desk for the first time since last Thursday.

The workshop went pretty well. Being the first time I had taught a class of that length, it was a bit stressful. It ended up being even more stressful than I had anticipated. A combination of a really, really bright group of students, and the fact that we provided the exercises in digital rather than printed form, meant that exercises that should have taken an hour, often took fifteen minutes. Because they were smart students, they absorbed material quickly, and because the instructions were provided digitally, they were able to copy and paste the code portions of the instructions, which is not only faster than having to type in the code, but it also has a considerably lower possibility for making mistakes. Frankly, we learn a lot more from making mistakes, than we do from having things work right the first time.

For the future, I will probably use printed exercises. I think the way most people learn, something that can be copied and pasted bypasses the type of brain processing that moves stuff from short-term memory to long-term memory. Now, I'm no psychologist, so I could be making it up, but I know that in my personal experience, when I've been able to just copy and past and then tweak somebody else's code rather than figure it out myself, the next time I needed to do it, I didn't really remember it.

All things considered, though, I felt like it went pretty well and I hope the students felt it was valuable and worth attending. I did run out of steam toward the end of the day Sunday, having only gotten about two hours of sleep each of the two previous nights (thank Dog for caffeine!), but we covered a lot more material than I ever anticipated over the course of three days. I think that the Keynote presentation I have right now is more honestly a week's worth of material for a more typical classes working from printed exercises.

Now of course, I'm scrambling to catch up even more than I was before. My inbox has really piled up, and I'm even further behind on the book. On top of that, our annual family vacation is coming up next week, so you probably won't see a long tutorial post for the next two weeks.

Read more »

Boot Camp Imminent

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.

Read more »

The best new software for your PDA/Smartphone

Here is a short review of software to help make practicing medicine a little easier.

Includes a review of device characteristics:

Android,Apple,BlackBerry,Palm,Symbian,Windows, memory issues, input methods, WiFi, 3G and EHR integration.

Includes products from:

AAP,AAFP,ACP,Epocrates,Johns Hopkins, Merck,Skyscape, UpToDate. SV

Medical Economics Article

Modern Medicine Podcast

Related Article: Consumer Health Applications for the iPhone/iPod Touch

Read more »

OpenGL ES Update

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.

Read more »

My Last Word on Dot Notation

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.

Read more »

Make your Smartphone Smarter Podcast

Here are some suggestions for getting the most out of your smartphone. SV

Modern Medicine Podcast

Read more »

How to Use Dot Notation and Properties

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.

Read more »

Dot Notation Redux: Google's Style Guide

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?

Read more »

The Dot Notation Controversy

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.

Read more »

Translations and Xcode

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.

Read more »

Multi-Row Delete in 3.0

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.

Read more »

Baseball Slugger: Home Run Race 3D

iTunes Link

Baseball Slugger is a baseball game by Com2Us. $0.99

And here I was, thinking that baseball couldn't get any more addictive. After Gamevil brought out Baseball Superstars and forced me to play season after season of the game I basically gave up on finding another game better. It has come however, in the form of an arcade home run derby type game from a previous baseball developer. Com2Us previously brought out 9 Innings Baseball, which I found wasn't up to Superstars in terms of the easy arcade style of it. Baseball Sluggers was basically venturing into an unexplored region and could control it with a half hearted attempt at a game. Com2Us has delivered with this game with not only an addictive game and brilliant graphics, but a great online mode that really keeps you coming back for more. This is a real winner in my books and is the reason why it continues to do strong in the charts.

Baseball Sluggers has brilliant 3D graphics that look absolutely amazing. What makes this game stand out from other baseball games is that the game is all in 3D and has a high polygon count (How good the game looks basically). All of Com2Us' games are spectacular but Baseball Slugger takes it to another level. The whole game just screams colorful, crisp and a heap of fun. There are also amazing slow motion cut scenes that happen when you perform the perfect home run and add to how good this game is.

Baseball Slugger is such an easy game to pick up and play, but managing to master it is the real hard part. To play Baseball Slugger you have to tilt you iDevice until the transparent section on the screen is where you believe the baseball is/will be and press the hit button. Timing is everything in the game and you will find yourself fouling and missing the ball quite alot to start off with. This is a great step up from the D-Pad style hitting we have come to play, and more like the batting experience found in MLB World Series 2009.

Before I start lets make one thing clear. Baseball Slugger has absolutely nothing to do with playing Baseball matches as its more of a Home Run Derby event. There are three game modes to play in which are Match-Up, Arcade and Classic as well as a training mode.

Match-Up is where all the excitement happens as you must battle your way through fierce competitors to become the best of the best in the all out slug fest. This mode is extremely slick with only the slightest bit of delay between what you see your opponent doing and their actual score. There are four different levels as such to compete in for Match-Up, each with harder pitchers, generally harder opponents and longer and more excruciating matches. This mode makes the game what it is and you will be playing the bulk of your time in this mode.

Arcade mode is slightly different to Match-Up. The aim of this game is to get as many points as possible with ten lives as such. So for example every strike or foul is a life lost. Points are earned by basically hitting the ball. You get extra points for getting multiple homeruns in a row, hitting poles and scoreboards, hitting the ball over 500ft and hitting the ball in all different sectors of the ball park. There are many special balls which make your job either harder or easier, with ghost balls that disappear then reappear or balls that multiple your score for that hit. This mode lets you earn quite a few gold balls, which can be used to buy new equipment that improves your ability. This customization part of the game is also another reason why its so addictive.

Finally Classic mode takes a kind of customization on actual Baseball rules. Again you have ten lives but this time you have to see how many home runs you can hit, with almost like baseball if you hit it in the air and it doesn't go for a homer you will be caught out. This is good practice to get your eye in and also can be used to earn some decent gold balls.

Baseball Slugger: Home Run Race 3D is a spectacular game that manages to secure your time day after day, hour after hour. The match-up mode is an amazing concept that was pulled off spectacularly. Fun gameplay and brilliant graphics are found in the game that will have you bashing and crashing your way up the global Slugger charts in no time. Any baseball or online fans will crave this game but it will really appeal to anyone. I have friends in the UK and Australia who have never watched a Baseball game in their life, yet they absolutely adore this game. Seriously don't be the odd one out, just buy this game now!

Gameplay- 10/10

Graphics- 9.5/10

Sound- 9/10

Overall- 9.5/10

I would recommend this game if you enjoyed- Baseball Superstars

Tell me what you think about this review at Twitter- http://www.twitter.com/iPhone_Reviews next up is Guitar Rock Tour 2

Thanks- iPhone_Reviews

Read more »