Wednesday, September 30, 2009

More iPhone 3 Development Update

Today, I teased my Twitter followers with this and this. I thought it would only be fair to elucidate a little bit.

The first half of More iPhone 3 Development has been a struggle to write. In the first half of the book, we create a navigation-based application using Core Data. Although the chapters are primarily intended to teach different aspects of Core Data, I also wanted to set a good example design-wise. If you've ever written a table-based detail editing view, you know that's a challenge. Even Apple's sample code uses kludgey, hard-to-maintain techniques because the table view architecture simply wasn't designed primarily for creating this type of view; it was designed to display values from a collection or list not for displaying or editing different attributes of a single object.

My early thought was to create a generic framework of controllers that could handle editing any Core Data object just by creating property lists. This approach, although I think it has great merit for use in development, made the book too hard to write. All the code that I needed to show was getting squirreled away in these generic classes, and I was having to spend a lot of time explaining the architecture rather than the important Core Data concepts that I needed to get across.

After a lot of struggling, and writing probably twenty-five different prototypes, I finally hit on a solution that I liked. It was a maintainable design that borrowed a lot from the property list prototype, but kept everything in the places where people are used to seeing it. Instead of property lists, we store the structure of the table view in arrays, but we start simple enough that the concepts don't become too overwhelming. Or at least I hope they don't.

As I started working on the Chapter 7 version of the application, which is the first time that we need to add another detail editing controller, I realized that in just a few short pages, we could refactor the controller class written over the previous six chapters to be completely generic and totally reusable, meaning we wouldn't need to write any more substantive code for editing or displaying data once the refactoring is done. We can add drill down into an infinite number of controllers, traversing relationships or fetched properties, and never have to add more code than what's needed to create a couple of arrays that define the object and attributes we want to let the user see or edit.

It's so far been a somewhat difficult chapter to write, but it's incredibly edifying to get here and realize that the attention to design has paid off. The end-result of Chapter 7 is basically an extensible infrastructure for creating navigation-based Core-Data applications. Hopefully, the reader will also have taken away a strong understanding of Core Data, but even if not, you'll have a starting point to work from that will save you a lot of development time. You just create your model, and set the controller instance's arrays to reflect the objects and data to be displayed or edited in your application. All the really hard stuff is done and can be leveraged over and over again.

Thanks for your patience. Once Chapter 7 is done, I should be able to make much faster progress.



PatrickJ Interviews Loren Brichter

An interesting and apparently amicable end to the Twitter 2 controversy? It sorta looks that way.

Not everyone will agree, but I think now people have a better understanding of the situation Loren was in and the reasons he made the decision he made.



Critical Thinking from Critical Thought

This is an excellent blog post by David Whatley of Critical Thought Games. I was already bummed about not being at 360 iDev (the first was awesome), but I really would have liked to have been in the audience for David's talk, especially to watch the crowd's reaction.

I've been known to grouse about things from time to time, but I also try to keep a sense of perspective and not lose sight of just how amazing this thing that Apple has enabled with the App Store and iPhone SDK is. David does it better. Well worth a few minutes of your time to read this.



Tuesday, September 29, 2009

Comments are Broken

Note: No word from Blogger.com yet, but the comments to this post seems to be okay, it's just the original post that's not working, so the discussion has started back up in the comments to this post.

Yes, I'm aware of the problem. I've posted the error code and information to Blogger's tech support forums and am hoping for more information sometime today.

It is a shame, though, the Just Another iPhone Blog author I linked to in my last post wants to respond to my post, and can't. We've tweeted back and forth a bit, and I think the discussion will be both interesting and fruitful and, believe it or not, civil.

As several C4 attendees became painfully aware this past weekend, the way our words are received are not always the way they were intended when written. It's altogether possible that I read the intent of that post differently than the author intended, and I think there's a real opportunity here for users and software developers to better understand each others' perspective.

I'm not sure that there's going to be common ground - I feel pretty strongly that Tweetie is fairly priced and that there's nothing unfair to the users about making Tweetie 2 a new product, especially in light of the fact that there's no built-in mechanism for paid upgrades on the App Store (yes, I know you can do it with in-app purchase, but that requires building infrastructure to support it and would be non-trivial to backfit into an existing application) - but I think there may be a possibility of closing the gap a little bit, educating users and ourselves in the process.

Stay tuned.



Monday, September 28, 2009

A Sense of Entitlement: Tweetie 2

For the most part, I stay out of discussions about App Store pricing. The so-called "race to the bottom" is, I think, somewhat blown out of proportions in many discussions held between iPhone developers, who have a very personal and one-sided view of the market. There's a lot of competition and prices are lower than traditional software markets, but there's also a large volume of buyers (2 billion applications sold so far and counting according to Apple), which means you can still make a living charging relatively low rates. If EA or Infinity Ward can make a profit selling a game for $49.99 that takes a team of literally hundreds of people two years to create, it seems like 1-5 person iPhone development shops should be able to make a profit at a much lower amount if the program is marketed diligently and intelligently and is truly useful or fun.

The early seemingly overnight success stories have, I think, created a skewed perception of how easy it is and should be to make money in the App Store. That being said, I think there is some merit to the argument that the low prices and large number of free applications that dominate the app store have created a sense of entitlement and have fostered an environment where people feel like they are owed free upgrades in perpetuity.

This can be evidenced by this blog posting that takes Loren Brichter to task because he's releasing the next version of Tweetie for the iPhone as a new app with no upgrade path. This blog post has such gems as
A slew of new features and functionality does not, to me, make it a different app.
Right, and when Adobe releases a new version of Photoshop or Microsoft releases a new version of Word with "a slew of new features and functionality", those are, of course, free, right?

Of course not.

It takes time and money and hard work to create that slew, and that has to be paid for somehow. When you get your oil changed in your car, you don't expect it to be free the next time bring your car in, because it's the same task they're performing, do you? Because you paid for a newspaper to be delivered today, doesn't mean you expect to get it free tomorrow and forever, does it? Of course not. No business can run without revenue. If Loren continued to spend all of his time developing Tweetie and never got more money from his existing customers for the new features, he would eventually go bankrupt and starve. Or more likely, he'd stop developing Tweetie before that happened, and we'd never get any cool new features again.

I don't know Loren personally, but I use Tweetie as my iPhone client (along with Twitteriffic which is also excellent) and I try to keep abreast of what's going on in the iPhone development world. Many of the people I follow on Twitter are beta testers for Tweetie 2, and I can tell you from the chatter I've seen that an awful lot of hard work has gone into the next version of Tweetie over quite a long period of time.

Loren has decided to ask a very reasonable fee for the new iPhone version of Tweetie, which should be showing up on the App Store in the next week or so. The $2.99 he's asking is less than most of us spend per day on coffee. If the author of the blog post above is making minimum wage, then he made more money from penning that whiny rant that it would cost to buy the new Tweetie. Get a fucking sense of perspective. The world owes you nothing. Loren owes you nothing. You paid for Tweetie 1, and you got Tweetie 1. Nowhere in that transaction did anyone promise to deliver to you new versions on a silver platter in perpetuity.

The old version will still be available to those who have purchased it. You won't be made to stop using it, or forced to upgrade, you just won't get the cool new features that Loren's been busting his ass to write over the last six months. You won't stop getting the benefit of what you've paid for.

Even though I occasionally offend people with my opinions, I rarely do it intentionally. But in this case, I think certain people, like the author of the blog linked above, along with all the people echoing similar sentiments on Twitter deserve a little verbal slapping around. This kind of immature sense of entitlement should not be coddled or put up with. People whining about the cost of the upgrade should be told in no uncertain terms that they are acting like fucking toddlers. Worse, because toddlers are, well… toddlers. These people are presumably adults and should know better.

If the new features aren't worth $2.99 to you, fine, don't buy it. There are plenty of other Twitter clients available, several of which are free. So shut your pie hole and go find another client rather than whining about how you are entitled to the end-product of Loren's hard work for the last half year simply because you paid about the price of a bottle of soda about a year ago.

If you really like Tweetie… if it's your favorite twitter client, then for fuck's sake, it's only three bucks to help ensure that we keep getting new features! If you don't, then why would you want the new version anyway. Just on principle?

Note: Comments are broken on this post. You can comment on this post instead if you desire.




The Grass on the Other Side of the Fence

Here is an short account of the experiences of one of the earliest Palm Pre developers. Be warned, though: The neon green on black is a little hard on the eyes.

Not intending to pass judgment here, just think it's interesting to see what life is like developing for other mobile platforms. I think keeping a little in touch with what's going on in the Palm and Android development world helps us keep a sense of perspective when we get frustrated with the App Store and iPhone development process.



Two Billion and Counting

Today, Apple announced that they have reached another milestone: two billion applications have been downloaded from the App Store. Other numbers from the press release include the fact that there are 85,000 applications available in the store, and 125,000 registered iPhone developers. The App Store is currently available in 77 countries and allows you to reach 50 million potential customers.

Holy hell, those are some big numbers.

via Michael Jurewitz



Saturday, September 26, 2009

Read for You, Write for Me, Right?

Properties are a way to expose data to other classes. Because they make memory management more convenient on the iPhone and in non-GCC Cocoa apps when you declare them retain, many of us also use properties within our class. When we use synthesized instance variables, we don't have a choice, because the underlying instance variables created by the runtime aren't available even to our own class, and we have to use the accessors and mutator or dot notation to use them.

What happens, however, when you want a property to be read-only to other objects, but you also want to be able to use the synthesized mutator within your own class to assign new values? In other words, what do you do when you want a property to be read-only to the rest of the world, but read/write within your own class?

Extensions to the rescue. Before we had extensions, it was common to declare a category at the top of your implementation file with any private methods. This would prevent the compiler from complaining when you called a private method from within your class. The compiler would see the private method declaration in the implementation file when your class was compiled, but wouldn't see those methods when it compiled other classes. Under this old way of doing it, we would simply include the mutator method in the category, and only put the accessor in the header file, and that would effectively make the instance value read-only to the rest of the world by not exposing the mutator.

In Objective-C 2.0, this practice has been formalized into extensions, which are basically just anonymous, nameless categories. One thing you can do with an extensions is to redefine your declared properties. So, you can declare a property in your header file as readonly, and then in your implementation file, create a class extension with the same properties re-declared as readwrite. Ét voilà! Your class will be able to use both the accessor and mutator for those properties while external classes will only be able to use the accessor. Cake and nom nom. Life is good.

Note: you cannot change all aspects of a property. You can't, for example, declare it copy in your header file and retain in your extension.
Let's look at a simple example. Let's say we were writing a subclass of NSOperation that had two properties. We want these values to be set by in the init call, but because our operation will be running concurrently on another thread, we don't want the values changed after that by external objects, but we may need to change them ourselves. To do that, we might declare our class like this:
#import <Foundation/Foundation.h>
#import <QTKit/QTKit.h>


@interface MyUpdateOperation : NSOperation {

}

@property (readonly, copy) QTMovie *movie;
@property (readonly, copy) NSView *view;
- (id)initWithMovie:(QTMovie *)inMovie andView:(NSView *)inView;
@end


And then, in the implementation file, we would use an extension to redefine those two properties:

#import "MyUpdateOperation.h"


@interface MyUpdateOperation ()
@property (readwrite, copy) QTMovie *movie;
@property (readwrite, copy) NSView *view;
@end


@implementation MyUpdateOperation
- (id)initWithMovie:(QTMovie *)inMovie andView:(NSView *)inView
{
// Logic goes here
}

-(void)main
{
// Logic goes here
}

@end


It's a simple trick, but one with the potential to make your life more pleasant.



Thursday, September 24, 2009

Barcode Generator Application



For grins and giggles, I tried compiling an Xcode project I created back in 2002. Well, technically, it was a Project Builder project created in 2002 that was converted to an Xcode project a couple of years later, but the bulk of the code was written back in 2002. I wanted to see how much work would be involved in taking a project that was written when Puma was the current version of Mac OS and Macs were shipping with PowerPC processors and getting it to compile to work in 32/64 bit mode for Intel Macs.

Code changes required? Not a one.

There were a bunch of warnings that I would address if this were shipping software, since a couple of methods I used back then have been deprecated. None of them have yet been removed, so the application works (as far as I can tell) exactly as it did back in 2002. The project configuration was where almost all of the work was in updating, and there wasn't much of that, to be honest. Total time investment, about 20 minutes.

That's pretty damn amazing, different architectures, different register size, and a seven-year-old codebase written when I knew a heck of a lot less about Cocoa. Despite all the amazing changes to Snow Leopard, this old code still works flawlessly.

If you're interested in a free Barcode application, you can download the compiled application right here. If you have a version of the OCR-A font installed, it will attempt to use it (you can get a free one here), otherwise it will fall back on the system default monospace font.

I will push the project changes to Google Code when I have some free time.



Wednesday, September 23, 2009

Opacity - Export as Source Code

Okay, I don't ordinarily repost items covered by Daring Fireball since most of you probably read it anyway, but this one's just too cool and too relevant not to include. The vector art program Opacity now has the ability to export your graphic as source code, presumably as CoreGraphics calls that you can use in your Mac and iPhone applications.

Now, in most cases, you don't want resources contained in code - you should just store the graphic file as a resource in your application's bundle - but there are times when this would be hugely helpful, like when you want to animate the vector art, or when the specific appearance of the image depends on values only available at runtime.



Tuesday, September 22, 2009

More Housecleaning

Here's another category I found while cleaning out my dev folder. It's another bit of Quicktime code for Cocoa. This is a category on QTMovie that makes it easier to deal with standard movies (i.e. ones with one video track and any number of audio tracks).

This same category exists in the MovieStepper project, but that version won't compile for 64-bit Cocoa applications because Apple has removed access to the underlying Quicktime data structures like Track and Media. This version uses only QTKit objects to accomplish the same tasks, and thus will compile for both 32-bit and 64-bit applications.

QTMovie-Frame.h
//
// QTMovie-Frame.h
// MovieStepper
//
// These are methods designed to be used on movies that contain only
// sequential frame data, e.g. straight movies. These methods make
// the assumption that the framerate is constant and that each frame
// is displayed for the same length of time. Do not use these methods
// on movies that have tracks other than a single video track and
// some number of audio tracks.
//
// This code may be used freely in any project, commercial or otherwise
// without obligation. There is no attribution required, and no need
// to publish any code. The code is provided with absolutely no
// warranties of any sort.

#import <Cocoa/Cocoa.h>
#import <QTKit/QTKit.h>

@interface QTMovie(Frames)
- (long)numberOfFrames;
- (void)gotoFrameNumber:(long)frameNum;
- (long)currentFrameNumber;
- (int)displayFPS;
- (float)desiredFPS;
- (NSImage *)frameImageForFrame:(int)frameNumber;
- (NSSize)size;
@end



QTMovie.m
//
// QTMovie-Frame.m
// MovieStepper
//
// Copyright 2009 Jeff LaMarche. All rights reserved.
//
// This code may be used freely in any project, commercial or otherwise
// without obligation. There is no attribution required, and no need
// to publish any code. The code is provided with absolutely no
// warranties of any sort.
//
// This code has been updated to work in 64-bit mode where access to
// the underlying Quicktime Carbon structures has been removed.

#import "QTMovie-Frames.h"

@implementation QTMovie(Frames)
- (long)numberOfFrames
{
NSArray *tracks = [self tracksOfMediaType:QTMediaTypeVideo];

for (QTTrack *track in tracks)
{
QTMedia *media = [track media];
NSNumber *frames = [media attributeForKey:QTMediaSampleCountAttribute];
if (frames != nil)
return [frames longValue];
}


return -1L;
}

- (void)gotoFrameNumber:(long)frameNum
{
int frames = [self numberOfFrames];
double percentDone = (double)frameNum / (double) frames;
QTTime duration = [self duration];
QTTime newTime;
newTime.timeScale = duration.timeScale;
newTime.flags = duration.flags;
newTime.timeValue = duration.timeValue * percentDone;
[self setCurrentTime:newTime];
}

- (long)currentFrameNumber
{
QTTime now = [self currentTime];
QTTime duration = [self duration];

if (now.timeValue == 0 || duration.timeValue == 0)
return 0;

double percentDone = (double)now.timeValue / (double)duration.timeValue;
int frames = [self numberOfFrames];

return (int) ((double)frames * percentDone)+1;
}

- (Fixed)rawFPS
{
NSArray *tracks = [self tracksOfMediaType:QTMediaTypeVideo];

for (QTTrack *track in tracks)
{
QTMedia *media = [track media];
QTTime duration = [[media attributeForKey:QTMediaDurationAttribute] QTTimeValue];
long numFrames = [self numberOfFrames];
double frameRate = numFrames*(double)duration.timeScale/(double)duration.timeValue;
return X2Fix(frameRate);
}

return -1;
}

- (int)displayFPS
{
return FixRound([self rawFPS]);
}

- (float)desiredFPS
{
return FixedToFloat([self rawFPS]);
}

- (NSImage *)frameImageForFrame:(int)frameNumber
{
QTTime restoreTime = [self currentTime];
[self gotoFrameNumber:frameNumber];
NSImage *ret = [self currentFrameImage];
[self setCurrentTime:restoreTime];
return ret;
}

- (NSSize)size
{
return [[self attributeForKey:QTMovieNaturalSizeAttribute] sizeValue];
}


@end





Monday, September 21, 2009

MV Blackjack - More Dev Folder Housecleaning



Here is an Xcode project for a simple Blackjack program. This is another one that was developed as part of a writing assignment, but then ultimately not used. This shows how you can use Core Animation rather than OpenGL to create a simple game. The cards are "dealt" to both players using the animatable properties of the views, and the effect is quite nice considering how simple it is to implement.



Dice Poker - Another One from the Dev Folder


Here's another Xcode project from the dusty corners of my dev folder. This is a project I wrote for an article Dave and I were going to write, but we decided on a different application.

As usual, typical warnings about not being production-ready, yada yada.



A Look at Android Development

I stumbled across this article on Android development today, and it was a very interesting read. The author gave a very balanced look at the Android platform, saying what he thought was good and bad. It reads like a very honest assessment. I didn't detect any obvious spin.

The one area where I don't agree with the author is his statement on Android's Intent/Activity model. This post claims that Android is "a big step ahead of the current iPhone programming model", but I can't help but to be reminded of OpenDoc and CyberDog. This idea of getting "away from monolithic, isolated applications" is not new; it's been floating around at least since the 1990s. If you look at theoretical, rather than practical implementations, it probably goes back much further than that, even.

Yet, here we are in 2009 still using monolithic applications.

Oh, wait, no we aren't. Not really.

When I write an iPhone application, much of the functionality I'm using wasn't written by me and isn't part of my application. It's part of a framework that's already on the phone. I think time has shown that the content-focused (or, intent-focused, if you will) way of dividing up code is problematic at best. It's great in theory, but problematic in practice.

In the example in the blog posting, how do I know if that barcode application is installed? What do I do if it's not? This approach opens up a huge number of problems with testing, installation, and development that offset any of the gains you get from not having code duplicated. The problems of Intent/activity are even more pronounced on an open platform like Android where the user has a lot of flexibility in terms of how they configure it and what they install on it.

This concept also just doesn't really fit the mobile application model that well. The iPhone isn't a general-purpose computer, and neither is an Android phone. If you look at the general population of consumers using smart phones, the way they use the phone the vast majority of the time really doesn't lend itself to this concept at all. They use and expect small applications to serve a defined, finite purpose.

If you're building megalithic applications for a smart phone, you're (quite simply) doing it wrong, and if you're not, you're not going to get all that much benefit from Intent/Activity, and you are going to pay a price in added complexity in the development process and the install process, not to mention greatly increasing the likelihood of problems for your customers.

That's not to say that the iPhone couldn't use some improvement in the inter-application communication arena. We currently have the ability to register application URLs, but it's a one-way trip. I can launch a barcode application, but I can't tell the barcode program to send me anything back unless I control both applications. In reality, I'm not sure how big of a limitation this really is, however. Most of the time, we're not going to want to rely on another application's functionality to handle an important application task unless the other app is one we wrote and have control over. If that's the case, then we have access to the source code and can included the functionality in the app and make it self-contained, greatly reducing the chance that our customers will have problems and get mad at us.



More Desktop Code

Although my focus for the last 20 months has been the iPhone, I've tried to stay at least in touch with Cocoa for the Mac. As a result, I tend to start a lot of small projects designed to help me learn, re-learn, or brush up on some specific area of functionality. A lot of these projects just end up gathering dust on my hard drive and are never used in any kind of production application, so since I'm doing a little housecleaning, I thought I'd post some of these projects that might be useful to iPhone developers wanting to get into Mac development or for newer Mac developers.

I've written several Cocoa applications over the years that work with Quicktime, including Crimson FX, a simple rotoscoping and special effects application. Back when I wrote these, most of the Quicktime functionality had to be accessed through Carbon calls. Since then, there have been several major releases of Quicktime, and Cocoa has gained some very robust Quicktime support by way of QTKit.

To familiarize myself with Cocoa's current Quicktime functionality, I wrote a small application that loads in a Quicktime movie and allows you to step through it frame-by-frame or to scrub through the frames using a slider. There's also a custom view that displays a filmstrip timeline, similar to the way iMovie displays a timeline.



This is neither a full-featured, nor a production-ready application, but if you're interested in writing a Cocoa application that needs to do more with Quicktime than simply play a movie, you may find some of the code in here useful. In addition to the filmstrip view, there's also a category that adds several methods to QTMovie for dealing with the individual frames of a movie's video track.

You can find the project here. As always, there are no restrictions on the use of this code, and I welcome any improvements or bug fixes you might come up with.



Sunday, September 20, 2009

Some Desktop GL Goodies

No time for a tutorial or lengthy description, but I thought I'd quickly post a few Xcode projects I've got.

First is the OpenGL ES icosahedron project from way back in OpenGL ES from the Ground Up, Part 2, only ported to Cocoa for the Mac. This is the very first one, with no lighting. It does show how to set up OpenGL ES on the desktop, including toggling full-screen mode. You can also use the arrow keys to increase or decrease the rotation speed.

Second, I've taken Apple's very old NSOpenGLView Full Screen sample code, and updated it to use the modern approach that works nicely with multiple displays and multiple GPUs. You can find the updated Xcode project here.

Third, here's another version of NSOpenGLView Full Screen sample code that creates a dedicated full screen app that doesn't support a windowed mode.



Saturday, September 19, 2009

App Store Resource Center

If you're part of the iPhone SDK Program, you likely already now about this, but I think it's cool enough to warrant a post.

Apple has just opened the App Store Resource Center for Developers. I haven't had the opportunity to go through it exhaustively, but at first glance, it appears to a welcome and pretty awesome tool for third party application developers.



Wednesday, September 16, 2009

Persistence Pays Off

Here's a report that says Microsoft's Bing search engine has captured over 10% of the search market. That's pretty impressive, but when you take into account that Yahoo! search is also powered by Bing, that means the Bing search engine is actually handling 26.7% of search traffic. That's over a quarter of the search traffic being handled by a product that's only existed for four months.

Wow.

That's impressive, phenomenal growth, and Google should be just a little concerned. It'll be a while before Bing has a chance of knocking Google out of its number one position, but they certainly look like they are going to fight the good fight in search now. I bet this number continues to grow for a while, they look to have momentum and are getting almost exclusively good press.

There's no doubt that Bing's presentation is slick and the search engine is capable. It's going to be a lot of fun watching the competition between Google and Microsoft heat up. It will also be interesting to see if Microsoft can get more of their departments to find their groove the way Search has. Maybe they should consider transferring some of Bing's management team over to the Windows Mobile groups.



Multi Core Mobile Chip

It looks like the rumors of a multi-core mobile chip are actually well-founded. Boy, would something like this make for a jaw-dropping future iPhone model that would give us a real need for blocks and GCD.

from Bill Dudney



Monday, September 14, 2009

iPhone Dot Net

Here's another interesting project, which allows programming iPhone applications in C# using Mono. It's based on the open source Mono project, but is a commercial product.

I have such mixed feelings about projects like this one. On one hand, I have tremendous admiration and respect for the ingenuity and hard work that went into making this work. Yes, it definitely does lower one barrier to entry for a considerable number of people with solid .NET experience, but that's not necessarily a good thing.

Tools like this encourage people to become hammer developers, that is to say, developers who use and are comfortable with only one language and framework. I have a very strong belief that being a hammer developer is, to put it bluntly, bad. I'm a strong believer in the importance of cross-training. I think it's important to see multiple approaches to problems. To become a great programmer, you need to be exposed to the work of a lot of different great (and not-so-great) programmers, and not just ones working in a the same language and toolset as you. Good developers have both breadth and depth of knowledge to draw upon when solving problems.

Although C# has some similarities to Objective-C, C# derives from the Simula object model, like C++ and Java, meaning it's strongly typed and does a lot more at compile time than Objective-C. There's nothing wrong with strongly-typed, static languages, but in many cases, the Simula and Smalltalk models really do require the use of different design patterns to be used most effectively. These differences are not insurmountable; Apple, for example, ported WebObjects from Objective-C to Java several years back. But, there were definitely bumps in the road; some parts of WebObjects 5.0 were necessarily klugey to work around the fundamental difference in the two languages.

Now, before people jump on me, let me just readily admit that I'm biased here. I really like Objective-C and I do think it's the absolute best option for programming on the iPhone. I also fully realize that Objective-C seems like a weird beast when you first come to it, especially after spending a lot of time with languages like C++ and C#.

But I do honestly think that one mark of a good developer is choosing the right tool for the job even (or maybe especially) when it's not a tool you are comfortable with. Learning is good, people. Learning is good. Don't ever say you're too busy to learn a new language or framework. Learning is an investment in your future viability and employability. You can't afford to stop.

Now, obviously, there's more than one opinion on this. The developer of MonoTouch, Novell, has a very different take on it. They believe that C# is so much more efficient than Objective-C that they're kindly willing to sell you a $1,000 toolkit. You'll still need to be a member of the iPhone Dev program, and you'll also still need a Mac for development. So, while this may lower the knowledge barrier for .NET developers to create iPhone programs, it certainly doesn't lower the financial ones any.



More on Blocks

Joachim Bengtsson has a very nice post on using C Blocks, well worth the read, even though we don't have blocks on the iPhone yet.



Friday, September 11, 2009

Grand Central Dispatch is Open Source

I find this fascinating.

Apple has open-sourced libdispatch, better known to most people as Grand Central Dispatch.

Grand Central Dispatch is something that developers - at least those who attend WWDC - have known about for well over two years. It's not something that your typical computer user would get excited over, but from the perspective of a developer, it's a really exciting technology that allows you to leverage the power of all the processing units in a given machine relatively easily.

When I saw the GCD demo that Bertrand Serlet gave at WWDC 2008, I was blown away. I looked at it as a game changer for the long term. Until there's a huge breakthrough in chip technology, utilizing multiple cores and multiple processors is the way to improved performance and this looked like something that was going to launch them way ahead of everyone else.

I saw GCD as a huge competitive advantage for Apple. And now, they're giving it away under a fairly liberal open source license (the Apple Open Source license, a variant of theApache license). They not only proposed a new standard, they're giving away the underlying implementation that's been in development for probably three or more years. Though I haven't looked at it, from some of the sessions I attended this year, it sounded like getting this working was quite an engineering feet

I think it's awesome, but I'm honestly surprised by it. Strategically speaking, it's an odd move. I see the benefit to Apple for having the block notation and syntax be an open standard. I'm having some trouble seeing the strategic benefit to letting other people use this amazing technology for free. I have to think this will buy at least a tiny amount of good karma from the Open Source community. Maybe.



Thursday, September 10, 2009

3.1 OpenGL ES Template

I've had some questions about whether I was going to upgrade my OpenGL ES template any more. I probably will, but it won't be any time soon. I did want to just point out that the iPhone SDK 3.1 is now GM and I can point you to the excellent OpenGL ES Application template in 3.1. I haven't had time to use this template extensively, but it looks to be setup really well for supporting both OpenGL ES 1.1 and OpenGL ES 2.0, so you might want to upgrade if you haven't and check it out.



A Disappointment?

I came across an interesting little rant today about how yesterday's announcement was a "disappointment". I understand that a lot of people were expecting cameras in the iPod Touch, and are let down. But putting things into perspective, I do think the important upgrade to the iPod Touch happened - the move to 600mhz ARM 7 CPU and the PowerVR SGX GPU) happened even though it wasn't explicitly stated.

But here's the comment that I found weird:
The shocker for me was to see Apple putting a video camera onto the iPod Nano 5th gen along with a bigger LCD and FM Radio w/ live pause. I just don't see the point or appeal here. A video cam is much needed on the iPod Touch. But apparently, Mr. Jobs thinks of the iPod Touch only as a video gaming platform... whatever!

I'm not surprised that people are upset about no camera on the Touch. It was heavily rumored and would, without a doubt, be a nice addition. I don't disagree that it would have been great for that to have happened. Here are the two things I take issue with:
The shocker for me was to see Apple putting a video camera onto the iPod Nano 5th gen along with a bigger LCD and FM Radio w/ live pause. I just don't see the point or appeal here.

You don't see the appeal? Have you not heard about the Flip Mino and other mini digital video camcorders? They're selling like crazy. So, now you can get an iPod that's also a fully featured video camera for the same price as a Flip Mino? It's basically a buy-one-get-one-free deal. I think these things are going to sell like hotcakes this holiday season. I see shades of the iPod Mini in these things, only more so. I probably won't buy one - my iPhone meets my needs - but I definitely can see the appeal, especially at that price point.

The thing I really have a problem with is:
Mr. Jobs thinks of the iPod Touch only as a video gaming platform... whatever!

Apart from sounding like the sort of comment that an annoyed spoiled twelve-year old child would make, it's a huge leap to assume that the lack of a camera in the iPod Touch yesterday is due solely to Steve Jobs' personal belief in the Touch as a gaming device only. He's already gone on record saying the decision not to put a camera in was to keep the price down. Some people don't believe this, but I think it's at least part of the reason. Apple has been working hard to combat their (not entirely justified) reputation for selling overpriced hardware lately. They dropped their laptop prices across the boards at WWDC while making the whole line faster and better.

I suspect that there were also technical limitations of some kind involved with the decision. The fact is, those of us who don't work at the Mothership don't have any knowledge of the process Apple went through to get to the product announcements at the event yesterday. There could have been supply issues, there could have been technical limitations with the thinner iPod touch case, or they could legitimately have thought it wasn't worth the additional expense, and that adding a camera wouldn't move substantially more units. It could simply have been too much to re-engineer both to accommodate new chips and to add a camera in the time they had.

It's fine to be disappointed or to wish that Apple had done something different; who hasn't done that at some point? But oversimplifying a scenario that you know almost nothing about based only an adolescent assumption that Steve Jobs is some kind of simpleton who just doesn't see the big picture or the potential of the iPod Touch is ridiculous.

For me, personally (fanboy that I am), with Steve Jobs giving the presentation, it would have been very hard to come away feeling disappointed. But even if you're disappointed, please still try to act like a grown-up, okay?