iPhone Development

Wow.

2012-01-24T14:02:00.001-08:00

Just… wow. Those are crazy numbers any way you cut it.

How I Learned to Stop Worrying and Love the iBooks Author EULA

2012-01-23T17:58:00.000-08:00

I've been debating whether to post about the iBooks Author EULA or not. In general, I've been trying to avoid hotly debated and controversial subjects here for the simple fact that those discussions tend to eat up a lot of time and often aren't very productive. My opinion on iBooks Author and iBooks 2 is fairly close to some other authors I know. Because this is something that's near and dear to my heart, however, I figure it's worth a few words. And with me, a few words is usually more than a few.

There's been a lot of foofooraw since the iBooks 2 announcement last week. There's been all sorts of stories, tweets, and blog posts about how Apple is going to "steal your work" if you use iBooks Author. There's also been the all-too-familiar refrains of just how evil Apple is. It all seems vaguely familiar. Almost like… almost like we've been here before, what with all the people gnashing their teeth, rending their clothes, and complaining to the heavens about how evil Apple is because of the ~~developer agreement~~ ~~app store guidelines~~ iBooks 2 EULA.

There's also been a lot of complaints about the fact that Apple is using a proprietary format rather than using and extending ePub 3.

None of this bothers me terribly. Oh, it's not that there aren't things I would want different if I were King of the World, but the reality is that deciding whether to use iBooks Author is just another business decision for me. Emotional outcries and hyperbole are all well and good, but they don't change the parameters of the decision. Business decisions inherently involve risk, and the risk here is at a level that I'm perfectly comfortable with.

Before I explain why, though, I want to put up front that I'm not a lawyer. Well, that's not technically true, but I'm not a practicing lawyer and I'm not YOUR lawyer, so don't take anything I say as legal advice. I'm just explaining why I'm not concerned. If you have concerns, you should take those concerns to your lawyer before making up your mind.

The EULA

Make no mistake, the iBooks 2 EULA is poorly written and vague. The mere fact that people are up in arms is testament to that fact. And if the ambiguity that is there bothers you, don't use it. There are plenty of tools for creating eBooks, so if you think the risk of Apple "stealing" your work is too high, using another tool solves the problem.

There are several reasons why I'm perfectly comfortable with the risk involved. In no particular order, those reasons are:

It's simply not in Apple's long-term interest to take ownership of authors' books and Apple can almost always be relied upon to do what's in their own long-term best interest. Getting 30% of every iBook sale means they are motivated to keep authors happy. More than that, though, they need authors to want to write for this new platform in order to establish it as the dominant interactive next-generation eBook platform. Stealing books won't get them to that goal. Suing authors who publish non-interactive versions of their content for other platforms like the Kindle or ePub won't either.
Although the wording is certainly vague enough that you could argue more than one interpretation, the capitalization of "Work" in the EULA (meaning it has a specific contractual meaning) combined with the verbiage, "Work you create with this software" implies that the intent is to restrict only the application-specific output. In other words, the most likely intent as I read it is to cover the proprietary file format used for the new features not supported by other existing eBook platforms.
Even if that weren't the intent, from a purely evidentiary point of view, the other file formats that iBooks Author exports to are open, standard formats and it would be difficult for Apple to prove a particular non-interactive work was "generated" with iBooks Author even if they really did want to try and "steal our books". A PDF generated from iBooks Author would be nearly impossible to distinguish from one generated using Pages by simply copying and pasting the content from iBooks Author .
The EULA contains the following phrase: Title and intellectual property rights in and to any content displayed by or accessed through the Apple Software belongs to the respective content owner. Basically, it explicitly states that the ownership of any content you create outside of the app and import into it is completely unaffected by any "book stealing" clause, even if such a thing existed. This seems to counter the notion that Apple is trying steal our intellectual property in the first place because unless the words and images were created directly in iBooks (as opposed to being imported from Pages, Word, Photoshop, etc.), Apple would have no claim to the content anyway. Their claim would be limited to the way the content is formatted. Again, from an evidentiary standpoint, it would be incredibly hard for Apple to prove you created the content in iBooks.
The deal we're getting with iBooks Author isn't all that different from the deal we get when using Xcode as iOS developers, and the language of the agreements aren't all that different from each other either, and that's worked out pretty well so far.
And last, but not least, the kicker: Let's say, for giggles, that "book stealing" was Apple's intent, and such an intent was found to be both legal and the actual intent of the contract, and Apple decided to exercise those rights to steal my books. You know what? Even with all that, it's still a hell of a lot better deal than I've ever gotten from a traditional publisher. Apple is offering 70% of the sale price to me. The most favorable contract I've ever gotten from a publisher starts at 12% of the net price the publisher gets from the distributor, wholesaler, or retailer (which is half or less of the retail price). That percentage does slowly escalate up to 20% if I sell a ton of books, but if I publish a new edition of an existing book, the escalators go back down to 12% and I have to start all over. To put this in more concrete terms, if I were to sell a book in the iBooks Store for $9.99, I would get $6.99 per book sold, which is about four times what I get when one of my current $39.99 books sells, and I'd get that money months sooner. Oh, and guess what? I don't own those books published through a traditional publisher, either. My publisher can even have someone else update the book and can continue to use my name to promote it, even if I don't like the revisions or think the update sucks.

You can go on about what Apple "might do" or "could do", but the fact is that contracts aren't magic. If Apple wanted to screw me, there's no doubt they could, with or without this language. They've got a disproportionate amount of power in this contractual relationship because they have the audience and the platform, and they also have a ton of money and lots of really, really good lawyers. If they came after me, the merits of the case would matter little because I couldn't afford to defend myself against them, anyway. That's a risk, sure, but based on my past dealings with Apple, them trying to use the legal system to screw me seems a very remote possibility, and I'm willing to accept that risk. The language of the contract does almost nothing to change the amount of risk here for me. It's little more than a red herring as far as I'm concerned.

ePub 3 vs. iBooks 2

Many people have suggested that Apple should have used the existing ePub 3 standard and worked with the standards body to extend it in whatever ways Apple needed it extended. Instead, they decided to create a proprietary file format using the older ePub 2 specification as a starting point. It is important to note, however, that Apple is not advertising this new format as being ePub; we only know it's based on ePub 2 because people have reverse engineered the generated .ibooks files.

Now, I'll be honest. In a perfect world, I'd prefer to see Apple using an open standard here. But, there isn't an existing open standard that does what Apple wanted to do, and working with a standards body to revise existing standards to meet their needs for a yet-to-be-released piece of software would have tipped their hand about the software they were developing. People would have known exactly what Apple was working on from the things they were requesting of the standards body, which would have given competitors an advantage and could have hurt Apple's negotiations with publishers. Apple's culture is steeped in secrecy, and many would argue that this secrecy has been a contributing factor to their repeated successes over the last decade. Anybody who follows the company and understands the way they work knows exactly why they made the choice that they did here. Was it the best choice for Apple? Only time will tell, but there are obvious reasons why they would think it might be.

It's also important to note that iBooks Author is completely and totally free. But really, nothing is free. TANSTAAFL. Developing both a platform to do what iBooks 2 can do and developing a tool to create content for that platform was not a trivial task and Apple almost certainly devoted a lot of resources to getting it done and to getting existing publishers on board. Apple doesn't write software to be nice, they write software to make money. In this case, they're not making money directly, but make no mistake, it was written to make Apple money. The fact that they are not letting people use this free product to compete with them, or to create works for competing platforms should surprise no one. We, as users, authors, and publishers might desire such a tool and might have all sorts of reasons why such a tool would be an awesome thing for us. But so what? I'd like a pink unicorn that farts money. That doesn't mean I should expect somebody else to find one and give it to me for free.

Embrace, Extend, Extinguish

Lastly, several people on Twitter have pointed out that Apple's move here seems frighteningly similar to what Microsoft did throughout the nineties with their infamous "embrace, extend, extinguish" campaign. There's definitely some uncomfortable similarities, but I'm not quite ready to put this in the same camp… yet.

First, iBooks is not the dominant eBook platform, so any suggestion of a monopoly would be silly. Amazon sells far more Kindle books than Apple sells iBooks, and there are other eBook platforms, including Barnes & Noble's Nook, Kobo, and Sony's eReader to name just a few of many. The very idea of embrace, extend, extinguish requires monopoly-like control of a market to be effective, which Apple doesn't remotely have here (yet). There's also been no evidence (yet) of an attempt to "extinguish" the open ePub standard, or to brand the proprietary extended version as the standard. iBooks still supports ePub, and until Apple moves to change that, we're missing the most important and deadly of the three Es, without which there's really no harm, no foul.

The Bottom Line

To quote the narrator in Peter Pan, "all of this has happened before, and it will all happen again." Many developers railed against the "unfair" restrictions of the iOS developer agreement, the inability to sell apps outside the App Store, and the review process. I'm sure there will be similar teeth-gnashing the next time Apple creates a new market or platform, or revises any of the agreements related to any of the existing ones.

And certainly, there have been bumps in the road, some of which are still around. But overall, iOS has proved to be a great platform for developers to be on. The number of iOS devices in the world now numbers in the hundreds of millions, and many of the owners of those devices have shown a willingness to pay for content, including apps, movies, and books. It's not the gold rush the mass media thought it was four years ago, but it has been fertile grounds providing a great many people with a living, including me.

It's not a perfect place, but personally, there's no other place I'd rather be. The fact that I can now do both of the things I do professionally (write apps and write books) on those same fertile grounds, excites me. The fact that I can do things while writing my books that simply weren't possible before excites me even more.

Absolutely, things could change in the future, but I'll worry about the future in the future if I need to. For now, I'm happy here and thrilled about the possibilities that iBooks 2 and iBooks Author represent.

Blog Files

2012-01-09T05:56:00.001-08:00

As my inbox can well attest this morning, the web server that hosted most of my blog files is gone. I moved all the blog files over to Github, but forgot to post about the new repository.

Unfortunately, I just don't have time to go back and update all the old links, but every bit of code that I've posted that's now missing, can be found at GitHub.

Old code repository at GitHub.

Sorry for the inconvenience.

Speaking at MDevCon

2011-12-30T07:41:00.001-08:00

I'm proud to publicly announce my first speaking opportunity of 2012. I'll be speaking at MDevCon in Amsterdam this year on March 10th. This will be my first trip to Amsterdam and I'm incredibly excited to have the opportunity. I'm so excited, actually, that I'll be staying in the city for several days after the conference to hang out in Appsterdam and visit. When I know exactly which days I'll be in the city, I'll let you know.

I have one other conference that I've already agreed to speak at this year, but that one hasn't been publicly announced yet, so I can't spill the beans quite yet, but I'm equally excited about that one.

Treadmill Desk Update

2011-12-29T11:48:00.001-08:00

I'm coming up on the end of my second week using my treadmill desk, albeit two relatively quiet work weeks thanks to the holidays. I haven't put together the plans yet for those who might be interested in building a similar one, but the desk does seem to be holding up well. It's still very sturdy and has been working great for me.

After a really great first day where I put in over nine miles, my daily averages have backed off a bit to more in the 6-7 mile range and I'm averaging about 800 calories a day burned according to the treadmill. It seems that 1.6 MPH is my sweet spot for being able to type and mouse, though I sometimes go a little slower if I'm tired. I also usually start the morning at about 1.3 MPH, but after about 15 minutes, I'm usually up to 1.6.

I'm not finding it difficult to work for the most part. In fact, often I feel more alert and able to deal with complex problems. However, late in the day, I often feel just the opposite. I start to get fatigued, and when I do, then I often find that a difficult problem requires me to go over to my sitting desk or else needs to be pushed off until the next morning when I'm fresh. I suspect that this problem will go away as I continue to get used to it and am able to walk longer.

I currently spend about 4 hours walking, another 1-2 standing at my new desk, and the rest of my workday right now is at my old sitting desk. My goal is to get up to at least 8 hours of walking, but I'm really happy with this so far. It's not hard to do. There's no motivation for me to find. It's just part of my routine. When I go to my office, I start the treadmill. Easy-peazy.

I'm walking slow enough that I'm not experiencing much in the way of muscle soreness. A tiny bit in my calf last week, but none this week. There are some other problems that go along with the treadmill desk, however. First and foremost, my feet start to hurt something fierce by the end of the day. This week was better than last, and I suspect in a few weeks it will be a non-issue. A lot of it, admittedly, was poor shoe choice. More on that later.

Another problem with spending this amount of time moving is the potential for chafing and rashes. It goes away relatively quickly if you're smart enough to wear appropriate clothing, which I wasn't at first. If you experience chafing, here's two words to remember: coconut oil. Yep, the kind you buy for cooking. It's a solid at room temperature, but will turn into liquid from the heat of your hands. It's magic for irritated skin and it's also a lubricant. It's better than any lotion or salve I've ever tried.

I close my office door and open the window while I'm working, even though it's winter and I wear shorts and a t-shirt while working. Even at that, I'm a little warm, but I'm a warm person in general, always have been. I haven't broken out my winter jacket yet this year, so your experience might be different. Nobody I've talked to has mentioned being this warm, so it might just be me.

This one's important. Get some good walking shoes. Don't wear your existing sneakers or shoes, or worse, don't be stupid and go barefoot or wear sandals, crocs or whatever shoes happen to be closest to you. Good shoes, designed for walking, fitted by somebody who knows WTF they are doing. Four or more hours of walking is a lot of steps you're taking each day. Your feet will thank you.

So, the big question people probably want to know is: Have I lost weight?

It's really too early to tell. The scale says I've lost between two and four pounds, but honestly, my weight can fluctuate more than that just from water weight over the course of a single day. I might have lost nothing, or I might have lost more than that. I need more data points before I can form any conclusions. But, I suspect I have lost some. Even with a holiday party last weekend, I've been eating less than normal. I'm not sure if it's psychological or physiological, but I'm hungry less, and when I do eat, I'm tending to eat less and to eat healthier. I also haven't been tempted by my personal demon, the midnight snack. Well, more like the 2:30am-up-late-coding snack. Part of that may simply be that I'm too tired to work until 2:30am these days, though.

Overall, I'm declaring the experiment a success already. I'm able to work just as well walking as I am sitting except when I get fatigued, I'm burning calories while I work, and am just generally feeling better than I have in a long time.

Brilliantly Simple Idea: the Treadmill Desk

2011-12-20T10:47:00.000-08:00

Software development is not the easiest vocation for getting or staying in shape. For that matter, being part-owner of a relatively young business isn't either.

I've been steadily putting on weight and getting in worse shape since before the dot com boom. Since we started MartianCraft, I've had very few days off, and my average work day has been probably twelve hours, possibly longer. Every time I try and get into a routine of exercising, something happens: a client emergency, a deadline, a build, a new prospective client, a minor family emergency. When there's not enough hours in the day (and there never are), the exercise was always the first thing to get cut.

Recently, I came across this brilliantly simple idea from a Mayo Clinic cardiologist. It's called the Treadmill Desk. Essentially, you replace your chair with a treadmill, and instead of trying to get a good strenuous calorie-burning bout of exercise in a few times a week, you just walk while you're working. You don't walk fast; in fact, you go quite slow. They typically recommend that you walk between one and two miles per hour, which is about half of most people's normal walking speed. This speed allows you to function fairly normally. After just a few minutes, you can type and mouse normally. If it gets hard to type, you back off on the speed a little. It's not a race. It's not even exercise in the traditional sense.

I'm typing this blog post while walking on a treadmill.

The goal with this walking is not to break a sweat, but rather to just be in constant motion. You will want your office a touch cooler than normal, though, as even slow walking does raise your body temperature. Despite the low-key nature of the movement, a typical person burns an additional 100 - 130 calories per hour they're at their desk. For a typical person working an eight hour day, that's between 800 and 1040 calories per day. If you work longer hours or weigh more than the average person, it's even more calories. Now, think about that. You have to burn approximately 3500 calories to lose a pound of weight, so assuming you don't increase your caloric intake, that's about a pound every three to four days of work, or two pounds a week. For someone working a forty hour week, that's about five pounds a month, or sixty pounds a year without additional exercise or dieting. There's a lot of health benefits that go along with losing extra weight, also. Lower blood pressure, lower cholesterol, lower incidence of several types of cancer.

If you work more than forty hours a week, the benefits can be even greater, assuming you don't eat more to make up for the extra calories you burn.

I've talked to a number of people who are using treadmill desks, and the feedback was universally positive. Everybody lost weight – several of them a considerable amount – and all were in better health than when they started. And almost everyone said the following word-for-word phrase to me: "I would never go back to a normal desk".

After about the third person gave me the same basic story, I was sold. Sign me up! I can do this.

But there was a problem.

There are lots of plans for treadmill desks around the Internet and you can actually buy treadmill desks now. But, here's the thing: My primary machine is a Mac Pro with two 27" ACD monitors along with a crap-ton of accessories. I couldn't find any desk for under $5,000 that looked sturdy enough to safely and securely hold the weight of all my gear, and all the plans I found for building one seemed to assume the use of a laptop or small computer with small monitor.

Because of that big sheet of glass, Apple's monitors are heavy. Because of that big aluminum case, the Mac Pro is also very heavy. My computer and monitors alone weigh well over a hundred pounds, and I wasn't about to trust that much weight worth that much money to something that looked flimsy or was designed to hold a laptop.

I experimented for a week using a makeshift treadmill desk with my MacBook Air, and I found the walking and working quite easy to do, but also found myself constantly pining to move back to my desk to use my more powerful machine and bigger monitors. I usually abandoned the treadmill after about two hours when I'd start getting into more hardcore coding, not because of the treadmill, but because of the computer.

But, that week was enough to convince me that this was a good way to reverse the slow but persistent upward trend in my weight that's marked the last several years of my life. Unfortunately, it also convinced me that I could only make it work if I could find a way to use my computer while walking.

So, I decided to build my own desk. Building a sturdy desk this tall (over four feet tall in my case, since I'm 6'3" and will be standing on a treadmill desk that's about 6" high) turned out to be an interesting, but not-entirely-trivial engineering exercise. It took a couple of re-designs and a lot of swearing, but my desk is now done and I've been happily using it for a couple of days now.

Here's my rig on my desk (excuse the messy office):

(Yes, there's a beer bottle in the background. That was my reward for finishing the desk.)

After I've been using it for longer and am convinced the design is good, I'll share how I made the desk for anyone who might wish to build one for themselves.

So far, so good, though. The desk seems to be solid, has no perceptible wobble, and the monitors and computer don't seem to be putting any noticeable strain on it. Yesterday, I walked nearly nine miles at an average of 1.6 mile per hour and had a productive work day. Today's about half over and I've burned a little over 600 calories while fixing two pretty gnarly bugs in client apps. These two days have been enough to convince me that this is going to work.

By having my good computer on the treadmill desk and my MacBook Air at my regular desk, there's a built-in incentive for me to walk, or at least stand, rather than sit at my desk. I'm simply more productive when I have more screen real estate and a more powerful computer.

In a week or so, I'll put together a parts list and basic instructions, but the design is pretty basic. 1¼" galvanized pipe makes up the main frame of the desk with ⅛" wire rope and turnbuckles as guy wires to provide additional lateral stability.

This is the treadmill I use:

It's designed only for walking, will hold up to 400 pounds, and it's shorter than most treadmills, so it takes up less room. It's not cheap, but it's fairly reasonable for a treadmill at $400, and it can fold up out of the way if you need to. I've been very happy with it so far. While it's not whisper quiet, it's nowhere near as loud as most treadmills I've used, and it has a full set of controls on the handle where you can reach them easily while using it as part of a treadmill desk, which is much nicer than having to awkwardly reach over the desk to the treadmill's console.

The desk plans (when I post them them) are intended to work with this treadmill, you will probably need to make minor adjustments to use it with other models, as well as account for any height difference.

Comments Gone

2011-11-14T07:30:00.000-08:00

I regret to inform you that I've had to completely disable comments on the blog. I had to switch to moderation a while back since the spam detectors were failing to catch anything meaningful. Unfortunately, the rate of spam comments has been accelerating recently to the point where I simply don't have the time to search for the few actual and valid comments in the proverbial haystack of spam.

I wish I didn't have to do this. I like comments. I like hearing other peoples' takes on things and love it when somebody catches a mistake or proposes a better solution. But, comment moderation has been sucking away what little time I have for the block lately.

Maybe at some point I'll have the time to transition to software that can handle spam comments better, but I don't right now.

Sorry it had to be this way. It sucks that there are people in the world who do this shit and ruin things for everyone else.

Flash is Dead. No, Really this Time

2011-11-09T06:20:00.000-08:00

It appears that Adobe is going to cease development of mobile Flash.

I'm not ordinarily one to gloat or dwell on I-told-you-sos, but I'm going to make an exception in this one instance. I took an awful lot of heat for those blog rants backin 2009 for saying things like

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 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.

But before I get too smug, you know what? I missed a huge factor in the demise of Flash. I assumed the performance issues they were having back then were simply technical hurdles that would be overcome by Adobe's engineers before long. In the end, the lack of a monoculture was certainly a significant factor in the demise of mobile Flash, but the real nail in the coffin was that Adobe never even got mobile Flash working demonstrably well on a single model on a single platform, let alone working well on the "billions of mobile phones" they were shooting for with the Flash Consortium. I completely overestimated Adobe's ability to deliver, technically.

But all is not lost for Flash developers. Adobe has stated that they are going to "refocus" their efforts on allowing Flash to create HTML5 compliant web apps. What a brilliant idea!

If I may… one last quote from my much-reviled Flash rants:

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.

I said that back in August 2009 and, frankly, I was kind of stating the obvious. Maybe Adobe should have made me CEO. I doubt I would've done much worse than the current management given the recent layoff announcements.

I know people think of me as an Adobe hater. I'm not. More accurately, I'm a disgruntled fan. In the nineties I held Adobe in higher regard than I held Apple (at least Apple before Jobs' return). I adored Photoshop, which I had started using around version 1.5 and which enabled me to make a living for a couple of years. Somehow, in the span of fifteen years, Adobe went from being a company that made amazing things to being a company that made mediocre things that they marketed as amazing. A company that had no focus. A company that churned out new versions of software in order to generate new income, not to meet honest customer demand. I watched a great company become a company that didn't care about being great as long as quarterly profit sheets looked good.

I, for one, am hoping for a Phoenix-like rise from the ashes on the order of Apple's comeback. Hoping… but not expecting.

Objective-C 2.0 Compiler Directives

2011-10-20T08:26:00.001-07:00

Steffen Itterheim has posted a really nice list of all the Objective-C 2.0 compiler directives along with examples of how to use them.

Nice!

GLKit Examples

2011-10-19T10:32:00.001-07:00

I've added three new projects to my iOS OpenGL ES repository on GitHub. They are fairly simple examples of how to use GLKit and GLKBaseEffect. You can find them in the GLKit Stuff directory.

They're kind of rough, but they should be helpful to you if you're just getting started with GLKit and trying to figure out how to use it.

Thanks to Julián Oliver for tweeting the solution to a problem I was having getting textures to work with GLKBaseEffect.

CGAffineTransform Additions

2011-10-18T09:41:00.001-07:00

As you probably know, Apple provides a bunch of functionality for manipulating objects in 2D space using CGAffineTransform. Oddly, Apple doesn't provide you with a way to extract the scale, transform, and rotation information from a CGAffineTransform and they don't provide any shearing functionality at all.

Here are some additional inline functions that I use. This adds the ability to extract component values of the CGAffineTransform and also adds the ability to create and extract shear information.

As always, this code is free to use without restriction or limitation, but has no warranty whatsoever. If you fix a bug, feel free to let me know about the fix so I can incorporate the fix.

#ifndef __MCP_AFFINE_TRANSFORM_ADDITIONS__
#define __MCP_AFFINE_TRANSFORM_ADDITIONS__

#import <CoreGraphics/CoreGraphics.h>

#ifdef __cplusplus
extern "C" {
#endif

#define degreesToRadian(x) (M_PI * x / 180.0)
#define radiansToDegrees(x) (180.0 * x / M_PI)

static inline CGAffineTransform CGAffineTransformMakeShear(CGFloat shearX, CGFloat shearY)
{
    return CGAffineTransformMake(1.f, shearY, shearX, 1.f, 0.f, 0.f);
}
static inline CGAffineTransform CGAffineTransformShear(CGAffineTransform transform, CGFloat shearX, CGFloat shearY)
{
    CGAffineTransform sheared = CGAffineTransformMakeShear(shearX, shearY);
    return CGAffineTransformConcat(transform, sheared);
}
static inline CGFloat CGAffineTransformGetDeltaX(CGAffineTransform transform) {return transform.tx;};
static inline CGFloat CGAffineTransformGetDeltaY(CGAffineTransform transform) {return transform.ty;};
static inline CGFloat CGAffineTransformGetScaleX(CGAffineTransform transform) {return sqrtf( (transform.a * transform.a) + (transform.c * transform.c) );};
static inline CGFloat CGAffineTransformGetScaleY(CGAffineTransform transform) {return sqrtf( (transform.b * transform.b) + (transform.d * transform.d) );};
static inline CGFloat CGAffineTransformGetShearX(CGAffineTransform transform) {return transform.b;};
static inline CGFloat CGAffineTransformGetShearY(CGAffineTransform transform) {return transform.c;};
static inline CGFloat CGPointAngleBetweenPoints(CGPoint first, CGPoint second) 
{
    CGFloat dy = second.y - first.y;
    CGFloat dx = second.x - first.x;
    return atan2f(dy, dx);
}
static inline CGFloat CGAffineTransformGetRotation(CGAffineTransform transform)
{
    // No exact way to get rotation out without knowing order of all previous operations
    // So, we'll cheat. We'll apply the transformation to two points and then determine the
    // angle betwen those two points
    
    CGPoint testPoint1 = CGPointMake(-100.f, 0.f);
    CGPoint testPoint2 = CGPointMake(100.f, 0.f);
    CGPoint transformed1 = CGPointApplyAffineTransform(testPoint1, transform);
    CGPoint transformed2 = CGPointApplyAffineTransform(testPoint2, transform);
    return CGPointAngleBetweenPoints(transformed1, transformed2);
}
    
#ifdef __cplusplus
}
#endif
    
#endif

Long Live the King

2011-10-15T08:08:00.000-07:00

Jeff Atwood of Coding Horror has an interesting post today about being a developer for Apple's ecosystem. We'll leave aside for now the fact that Jeff isn't and has never been an Apple developer and is, in fact, a strong proponent of Microsoft's developer stack. Despite that flaw, I usually enjoy reading Coding Horror. I think Jeff's a smart guy with a lot to offer the world in terms of insight about software development.

But…

Jeff's premise today is that third party Apple developers "serve at the pleasure of the king", which is absolutely true. But, he finishes his post by saying he would never develop for Apple's app stores because of the chance of "being thrown under a bus" by Apple. Fair enough, we all have different tolerance levels for things, and his assumption here is essentially correct. Apple developers run a risk of having Apple compete directly with us if our product is successful enough. It happens, perhaps, to .01% of us, but it does happen.

I want to run with Jeff's metaphor a bit, but first, I need to address a couple of points in his article.

The first point I want to talk about is his claim that if Microsoft were to ever do something as audacious as release a product with the same features as one of their third party developers

…developers would be screaming bloody murder and rioting in the, er, blogs and web forums.

Wait… what? Excuse me? What the hell kind of fantasy world does one have to live in to think that Microsoft doesn't, wouldn't, and hasn't competed with their own third-party developers. Microsoft practically made a sport of it in the nineties, and has continued to do it since then, albeit less obnoxiously. I mean, have we forgotten that Microsoft was convicted by both the US and the EU of abusing their monopoly power to compete unfairly. Microsoft used to routinely use their market power to put smaller software companies out of business in order to gain control of a particular niche of the software industry.

And what were the third party Microsoft developers doing back then? Screaming bloody murder?

Nope.

They were defending Microsoft, and understandably so. The hand that feeds and all that. Those developers knew that being assimilated by Microsoft, or being unfairly competed against by Microsoft, were risks of doing business in that particular market and they deemed it worth the risk, much the way that iOS developers do today with Apple.

The second point that I think needs to be made is Atwood's implied assumption that because Marco Arment isn't up in arms over Safari's Reading List feature (which duplicates many of Instapaper's features), and isn't ranting to anybody who will listen, that it means he's "a loyal subject of the king". The implication being that Marco will put up with any treatment that Apple chooses to dish out, no matter how unfair, because he's a good whipping boy.

Which is a completely inaccurate characterization.

I don't know Marco personally, but he's one of the very few people I follow on the Internet who has consistently come across like a grown-up. Marco knew that getting sherlocked was a risk he faced by participating in Apple's ecosystem and decided that it was worth the risk. When that risk turned into reality, he accepted the consequences like a grown up. Anyone who could condemn a man for acting maturely should be called out for it, and that's exactly what Jeff is doing here. Marco's response to the Reading List feature was nothing less than admirable.

Virtual Geography

Now, back to Jeff's original metaphor of App ecosystems as countries. Let's talk a little bit about the Apple Kingdom and also about the neighboring countries where, as a merchant, you might choose to peddle your wares if the King's terms aren't acceptable to you.

The Apple Kingdom

As Atwood noted, the Apple Kingdom is a monarchy, ruled by a King. By Jeff's own admission, this king is a benign king, making decisions that he feels are best for his citizenry (consumers). He's not perfect, but generally his decisions have served the populace well, and they are happy and prosperous. The Apple Kingdom has beautiful paved roads and a great system of railways, and state-run stores within walking distance of every single citizen in the country. The king has invited even the smallest merchants to use this infrastructure to sell goods in exchange for a small percentage of their income and so long as those merchants follow some guidelines that the King has set (and, admittedly, may periodically change) in order to make sure his citizens have a good experience in his stores.

The Apple Kingdom is large, and its citizens are fairly affluent. They regularly shop at the King's stores and enjoy buying things there. Even tiny merchants are finding ways to make a comfortable living by being able to reach all the citizens of the country. Sure, not all merchants are succeeding. Even the best roads and stores aren't going to make a poorly run business profitable or get people to buy spoiled produce, but the opportunity is there for any one who wishes to sell goods to do so with minimal overhead and startup costs.

The King, however, is also something of a merchant himself, and sometimes he will sell at his own stores. He doesn't sell much, but when he does, sometimes he's selling the same types of products as some of the merchants in his kingdom. The King, of course, doesn't have to pay a percentage of his income to use the trains, roads, or stores, though. In even rarer cases, he'll find a product in the stores he likes so much that he wants to provide it to all of his citizens for free, which basically makes it impossible for the original merchant to sell that product any longer.

Now, the Apple Kingdom is not the only country in the world, and the King doesn't prevent anybody from emigrating or, in fact, even from exporting products to other countries. When deciding whether to pack up and go to another country, you need to make sure that your destination is going to be better than where you are now, so let's look at these other countries.

Androidistan

The largest neighboring country is an enormous country called Androidistan. Androidistan doesn't have a king, but instead has dozens of local and municipal governments of varying types and quality. Their national system of government is probably best described as anarchy. Androidistan's infrastructure varies greatly from province to province, with some roads and trains being free for anybody to use, and others requiring payment. Many provinces have their own stores where anybody can sell, but it's hard to find what you want and the quality of the goods is generally kind of poor, though there are exceptional products if you're willing to look for them. Unfortunately, there are also dangerous products sitting on the shelves as well. Poisoned produce and other deadly items disguised as legitimate goods.

Although there's a lot of people in Androidistan, most of them don't really like to buy goods at the government stores. They like to go in and make a meal of the free samples, but most don't really like to actually buy anything and shoplifting is rampant in these stores. In fact, it's often considerably easier to steal a product than to buy it legitimately because many of the stores aren't very well run.

Most merchants have found they can't make enough money selling their goods in Androidistan's markets, so they've tried placing stickers on their goods advertising other products. Some merchants are making a really good living doing this, but many more aren't even covering their costs.

Windowsland

On the other side of the Apple Kingdom is the relatively large country of Windowsland. Windowsland was once prosperous and has a huge amount of industry, but the country has been stagnating somewhat during the recent move toward smaller merchants. The government has recently started updating their infrastructure and building stores modeled after the ones in the Apple Kingdom. Windowsland has started a heavy advertising campaign trying to get merchants to sell their goods there.

Despite a great infrastructure and clean, brightly-lit stores, Windowsland has been having limited success in moving to the modern age of small merchants. Their large industry is still going strong, though, and in the long run, likely their stores will start to do a good business. Someday.

Oh, did we mention that Windowsland is also run by a King? He charges the same percent of income to use his railways, roads, and stores, but has placed fewer restrictions on his merchants in an attempt to lure them to sell in his country. Windowsland is a pleasant enough place, but there's just not all that many people going into their stores yet.

The Democratic Republic of WebOS

This small country had huge potential, but recent mismanagement and ineptitude have basically shut the government down. There are a few citizens roaming the streets still in a bit of a daze, but most have left for better-run countries.

The Blackberry Oligarchy

The Blackberry Oligarchy, which actually has two kings, has gone in one generation from prosperous world power to third world country due to its inability to change its ways. Citizens have been leaving this country at an alarming rate and the remaining citizens have little faith that their pair of kings will be able to fix the problems given the frequent power outages and decaying infrastructure.

There are several other small outlying countries in MobileWorld, but these five pretty much cover the major markets that merchants would want to sell into.

Epilogue

Metaphors are easy to stretch to a point that they become meaningless, and I probably crossed the line a few paragraphs back, but the point is this: all ecosystems have their benefits and their downsides. In the old days of boxed software, instead of a single benign king, you had to deal with a dozen tyrants (software chains) to get your goods on the shelf, and they took more than half the sale price in exchange. If you didn't want to deal with them, you could instead choose to work through a distributor who took another large chunk of your gross income in exchange for dealing with the tyrants on your behalf.

In every market at every time the risk of competition from a bigger, richer competitor has existed.

Part of Atwood's argument is that even good Monarchies can go bad. Sure they can. So can good democracies. Let's take what Apple might be someday off the table. We can't fault people for not staging a revolution before there's an actual reason to revolt.

Whether you do it explicitly or not, going into business means you're accepting certain risks in order to obtain certain rewards. When bad things happen in business — when risks (anticipated or otherwise) turn into actual problems — acting like a twelve year-old and whining to the Internets doesn't make things better. You buck up, find a way to fix it, or move on to something else.

So, yeah. We Apple developers serve at the pleasure of our King, and we know it. In exchange, we get access to millions of citizens who want to buy our products. A tiny percentage of us will end up competing directly with our king at times, but overall, life is pretty good in the Apple Kingdom for us merchants.

And, while we'd be glad to have you among our ranks, Jeff, you're more than welcome to pack up your gear and move to a neighboring country if you think life would be better for you there.

Disappointing

2011-10-10T08:26:00.001-07:00

So, like others, I was tempted to write a defense of the iPhone 4S after all the pundits and naysayers came out last week calling the iPhone 4S "disappointing". I'm glad I never found the time. As it turns out the iPhone 4s doesn't need anybody to stand up for it.

1,000,000 phones sold on the first day of pre-orders. That's 400,000 more than the iPhone 4.

And, that's not counting the number that will sell on October 14th when they arrive at the Apple Stores in 7 countries.

There's also a large batch of countries that don't get the phone until October 28, and a whopping 40 more countries (including China, where new Apple Stores have been shattering sales records lately) that won't get the iPhone 4s until some time in December.

Yeah. Disappointing. You guys in the media sure nailed that one.

Respect & Shame

2011-10-06T21:43:00.001-07:00

It's been fascinating seeing how many people have responded to the death of Steve Jobs exactly the way I did. It's truly amazing how many people who never met the man feel not just that the world has lost somebody significant but that they themselves have lost a friend.

Hearing others express exactly what I'm feeling? It helps. And, for the most part, the media has been right there with us, responding to Steve's death by focusing on his impact and the good he has done.

I really hope seeing how many peoples' lives he has touched is helping Steve's family and friends get through this.

But not all of the media has chosen to focus on the good. I won't link to any of the actual articles, but Gawker and the New York Times top a short list of media outlets that have chosen to focus on Steve's flaws and to stand up and shout out to anybody who will listen that Steve was… well… human. Imperfect. Flawed.

There's a custom in modern society that's often called "respect for the dead". It has nothing whatsoever to do with the dead. The dead don't care what you say about them. It's about the living who cared about the dead, and they do. It's because they care that mourning is such a difficult process. Painful. Sad. It's not a time when you want reminders of the flaws of the person whose absence you are trying to come to terms with.

No human with with a shred of empathy or decency chooses to publicly criticize the recently departed, famous or otherwise, regardless of how they felt about them. Doing so is an act of cruelty. It's hurtful. Little. It's kicking people hard when they are already as low as they can be.

For those, like me, who care, but didn't know Steve Jobs personally, people like this are an annoyance. They're just another crass, classless obnoxious Internet loudmouth that we have to make an effort to ignore.

But for Steve's family, friends, and coworkers… the people who really knew him, it's a hell of a lot more than that. It breaks my heart to think that they might read those articles.

Shame on you, New York Times. You're better than that. Shame on you, Gawker. You should be better than that.

Sad Mac

2011-10-05T18:16:00.001-07:00

I haven't had much time for blogging lately. I have about a half-dozen unfinished blog posts in my queue, but have been too busy to finish any of them.

One of the things keeping me busy right now is work for Apple through MartianCraft. This work, in many ways, is a dream come true for me, as I wanted to work for Apple for years and never managed it.

I started programming on an Apple ][+ in 1980 and Apple has been a part of my life ever since then. I don't need to look much further than the desk I'm sitting at to realize just how much my life has been impacted by this company called Apple started in a garage by two guys named Steve. I make a living using Apple's products and developing for Apple's products, but more importantly, my life is better because of their products.

I took a few hours away from my desk this evening and returned to the news of Steve Jobs' death. I came back to news that quite literally felt like a kick in the stomach. And I mean literally. My stomach hurts.

It seems odd to feel this way about a man I never met. I've only once been closer to Steve Jobs than the front section of Moscone West or North, and that was when I accidentally knocked into him on the show floor at MacWorld one year. But I feel like an old friend has died. I'm fighting back tears, and maybe I should be ashamed of that.

But I'm not.

Steve died far too young. I think a few tears are in order.

Online Session Code for Big Objects (Plus a Warning)

2011-08-12T06:55:00.000-07:00

In Chapter 9 of More iPhone Development, we wrote a set of classes that mimicked the behavior of GameKit's peer-to-peer connectivity, but for regular network connections (GameKit's only works with BlueTooth and local network connections). Basically, we wrote a class that lets you send and receive anything that can be packaged into an instance of NSData. Since it's relatively trivial to implement NSCoding for most classes, this means passing objects between two iOS apps (or an iOS and a Mac app) becomes pretty easy. You don't have to poll for the data, or worry about chunking out the data. You just make a method call and pass an NSData instance to send data, and then implement a delegate method for receiving data back from the other end. Life is good, right?

Hmm...

Maybe not. There's a pretty big limitation in the book's implementation. That implementation, designed for passing tiny packets of data (TicTacToe game moves), kept everything in memory. If you try to send a good size image to the other connection, likely you'd run out of memory fairly quickly.

A while back, I faced exactly that situation. For a kiosk app that MartianCraft was writing for a client, I needed to send large images shot with a DSLR camera from a Mac Cocoa program to an iPad program and also needed to send pictures taken with the iPad's camera back to the Mac Cocoa app. These images, compressed, ranged from about one to about five megs. I grabbed the OnlineSession class from More, figuring I had the network code basically done, and watched my application go down in a blaze of… well… not glory, that's for sure. Not only did the iPad run out of memory, it ran out of memory FAST… much faster than I expected. Even sending the smaller iPad camera images often caused low-memory crashes.

There were two basic problems with the OnlineSession class when you try to use it for sending larger volumes of data. First, as I said, was that it relied only on physical memory. Given that the physical limitations of the original iPad, this was problematic. But there was another, much bigger problem.

The second issue was that during the process of chunking up the data to send, the code kept making unnecessary copies of the data. Put simply, I made a n00b mistake. The mistake didn't impact the TicTacToe application because the game moves would easily fit into the send buffer, but it's a mistake I've made before and definitely should've known better.

So, what, specifically, was this mistake, you ask?

Using NSData's regular convenience constructor dataWithBytes:length: when creating the new NSData instance to store the portion of the image that won't fit into the send buffer. If you read the description of dataWithBytes:length:, it very clearly says that it makes a copy of the data you provide. So, every time a packet was sent, the code would create a new NSData instance to hold the remainder that wouldn't fit in the buffer, and it would copy all the remaining unsent data for every packet. Ouch.

So, as a simple example, if we were sending a 5 meg image, and the send buffer was set to 128k, the code would make a 4.825 meg copy after the first packet was sent, then a 4.75 meg copy after the second packet was sent, a 4.265 meg copy after the third packet, and so on. After every packet, another slightly smaller copy of the data was made. A descending progression that would eat up memory fast.

After a lot of swearing at myself, I made some modifications to the class to do two things.

First, I switched to using NSData's dataWithBytes:NoCopy:length:, which uses the provided data in place without making a copy. This kept the memory footprint a lot smaller. In some instances, because the DSLR images were so large and our app needed to send so many, I still hit memory problems. So, the second thing I did was to add filesystem caching of the outbound queue so that all the encoded objects waiting to be sent didn't have to fit in memory for the application to function properly.

The new version of the class functions exactly as the one from the book, so you should be able to just drop-in replace the OnlineSession from Chapter 9 with this one without making any changes to your application code.

You can download the new version right here.

Working for MartianCraft

2011-07-26T14:25:00.001-07:00

In case you missed my tweets earlier this week, MartianCraft is looking to add a few developers. We're looking for a couple of experienced developers, and are also thinking about bringing in one or two entry-level devs without significant experience to be trained up.

Initially, the work would be project-based contracting and would start in late August. Conversion to full-time employment is a possibility, but not right away.

If you're interested in being considered, send an e-mail with relevant work experience and/or résumé/CV to work@martiancraft.com.

Auto-Incrementing Build Numbers for Release Builds in Xcode

2011-07-14T06:16:00.000-07:00

I use the wonderful Test Flight to distribute builds. One thing that Test Flight is a little picky about is build numbers. When you upload a build, it uses the build number to see if you're uploading a replacement or a new build. It will let you create a new build even if you don't remember to increment the build number, but it's an extra manual step, and then you end up with two builds with the same build number.

Because I'm forgetful, I wanted to automated this process. Basically, I wanted to increment the version short string any time we do an Archive and increment the bundle build ID any time we do a Release configuration build, but leave the version numbers alone on Debug builds.

Unfortunately, several of our projects are ones that we inherited or took over, so not every project uses the same version numbering scheme. How we increment 1.0b5 is different from how we increment 1.0.12, or a simple build number like 1058.

The way I deal with this is a Run Script Build Phase in my application's executable target that runs the following Ruby script (make sure you set the "shell" field to /usr/bin/ruby, and make sure the script is the last build phase in the application). Feel free to use this script if you wish and modify it to meet your needs. If you improve it, I'd be glad to incorporate improvements back into it. One item of note: the way that I differentiate between Archive builds and other Release configuration builds might be a bit fragile since I'm relying on an undocumented naming pattern in an environment variable.

Note: I'm aware of agvtool. I avoided it for two reasons. First, I wanted more control over the numbering schemes, and second, I tried using agvtool in a build script a few years back, but at that time, there were issues when you bumped the version numbers of a project that was currently open. Those issues may have been resolved, but I didn't want to fight that battle again.

def get_file_as_string(filename)
    data = ''
    f = File.open(filename, "r") 
    f.each_line do |line|
        data += line
    end
    return data
end


def handle_alpha_beta(old_value, letter, infoplist, start_of_value, end_of_value)
    parts = old_value.split(letter)
    version_num = parts[0]
    alpha_num = parts[1].to_i

    alpha_num = alpha_num + 1
    new_version = version_num.to_s + letter + alpha_num.to_s
    print "Assigning new version: " + new_version + "\n"
    new_key = "<string>#{new_version}</string>"

    part_1 = infoplist[0, start_of_value - '<string>'.length];
    part_2 = new_key 
    part_3 = infoplist[end_of_value + "</string>".length, infoplist.length - (end_of_value - start_of_value + (new_key.length - 1))]    

    new_info_plist = part_1 + part_2 + part_3
    new_info_plist
end

def find_and_increment_version_number_with_key(key, infoplist)

    start_of_key = infoplist.index(key)
    start_of_value = infoplist.index("<string>", start_of_key) + "<string>".length
    end_of_value = infoplist.index("</string>", start_of_value)
    old_value = infoplist[start_of_value, end_of_value - start_of_value]

    print "Old version for " + key + ": " + old_value + "\n"
    print old_value.class.to_s + "\n"
    old_value_int = old_value.to_i
    print old_value_int.class.to_s + "\n"
    if (old_value.index("a") != nil) # alpha
        infoplist = handle_alpha_beta(old_value, "a", infoplist, start_of_value, end_of_value)
    elsif (old_value.index("b") != nil) # beta
        infoplist = handle_alpha_beta(old_value, "b", infoplist, start_of_value, end_of_value)
    elsif (old_value.index(".") != nil) # release dot version
        parts = old_value.split(".")
        last_part = parts.last.to_i
        last_part = last_part + 1
        parts.delete(parts.last)

        new_version = ""
        first = true
        parts.each do |one_part|
            if (first)
                first = false
            else
                new_version = new_version + "."
            end
            new_version = new_version + one_part
        end
        new_version = new_version.to_s + "." + last_part.to_s
        print "New version: " + new_version.to_s + "\n"
        new_key = "<string>#{new_version}</string>"
        infoplist = "#{infoplist[0, start_of_value - '<string>'.length]}#{new_key}#{infoplist[end_of_value + '</string>'.length, infoplist.length - (end_of_value+1)]}"
    elsif (old_value.to_i != nil) # straight integer build number
        new_version = old_value.to_i + 1
        print "New version: " + new_version.to_s + "\n"
        new_key = "<string>#{new_version}</string>"

        part_1 = infoplist[0, start_of_value - '<string>'.length]
        part_2 = new_key
        part_3 = infoplist[end_of_value + "</string>".length, infoplist.length - (end_of_value+1)]
        infoplist = part_1 + part_2 + part_3
    end 
    infoplist
end



config = ENV['CONFIGURATION'].upcase
config_build_dir = ENV['CONFIGURATION_BUILD_DIR']

archive_action = false
if (config_build_dir.include?("ArchiveIntermediates"))
    archive_action = true
end

print "Archive: " + archive_action.to_s + "\n"


print config

if (config == "RELEASE")
    print " incrementing build numbers\n"
    project_dir = ENV['PROJECT_DIR']
    infoplist_file = ENV['INFOPLIST_FILE']
    plist_filename = "#{project_dir}/#{infoplist_file}"

    infoplist = get_file_as_string(plist_filename)
    infoplist = find_and_increment_version_number_with_key("CFBundleVersion", infoplist)
    if (archive_action)
        infoplist = find_and_increment_version_number_with_key("CFBundleShortVersionString", infoplist)
    end
    File.open(plist_filename, 'w') {|f| f.write(infoplist) }
else
    print " not incrementing build numbers"
end

Happenings and Prospects

2011-07-07T10:08:00.000-07:00

I apologize for the relative dearth of posts here since WWDC. That week in San Francisco always tends to backlog me pretty badly (I returned from WWDC at inbox 1138 - and that's after spending the return flight answering e-mails), so I've been pretty much heads down on work-related stuff ever since. I've also, at the same time, been consciously trying to back away from the 12-15 hour days, 7 days a week schedule that I'd fallen into trying to help get MartianCraft off the ground. Those two have conspired to give me very little time for writing lately, but I think things are under control now.

I've got my semi-mythical OpenGL ES from the Ground Up 10th installment on skeletal animation nearly finished and hope to have it posted within the next couple of weeks, and it's bit of a doozy. My goal with this post is to make one of the more intimidating topics in graphics programming approachable. Fingers crossed, it's been a challenge making this topic approachable, but I think I'm getting there.

A few other bits of news.

First, work has officially started on Beginning iPhone 5 Development. Yes, I know it probably should be called Beginning iOS 5 Development, but as of right now, we're sticking with the naming sequence Apress established with the first book. Dave, Jack, and I have already started updating the book for Xcode 4, ARC, Storyboards, and all the other cool new stuff and are hoping to have the book ready to go to press when the GM version of iOS 5 ships this fall.

Second, I purchased a new domain today. There's nothing there yet, but OpenGLESBook.com is now mine, and I have big plans for it. Once Beginning iPhone 5 Development is in the can, I'm going to revisit my partially written OpenGL ES 2.0 book. I plan to revise it to use GLKit and to add material about the very cool new OpenGL ES tools we're getting with iOS 5.

As of right now, my plan is to self-publish. I'm still researching the exact process, tools, and services that I'll use, but my plan is to sell the book without DRM and at a reasonable price. I'd like to have an early access program, however since a lot of the material I'll be covering will be under NDA until iOS 5 goes GM, I can't promise that at this time.

Update on UpdateConf

2011-07-07T05:51:00.001-07:00

Just wanted to let you know that I'm speaking at another conference. I'll be speaking at the inaugural UpdateConf in Brighton, UK on September 5th.

As part of the conference, I'm also giving a two-day intensive workshop on OpenGL ES. The workshop assumes no prior experience with graphics program, but will be fairly fast-paced and will cover a lot of ground because there's a lot of new ground to cover. I'll be going over the new GLKit and the incredible new OpenGL debugger as well as the updated OpenGL ES Instruments templates.

Not interested in OpenGL ES? There are four other two-day workshops going on with some really awesome instructors. Marcus Zarra is doing a two-day workshop on Core Data, Drew McCormack is doing a workshop on Core Animation, Sarah Parmenter is doing one on iOS UI design, and Remy Sharp is doing one on HTML5 for mobile. The worst thing about giving this workshop is that doing so will prevent me from going to one of the other great workshops.

The conference proper has a number of speakers, including the workshop instructors and it's really shaping up to to be quite a conference, and also quite a steal at £99 for early bird tickets to the conference (the workshops are extra). You can sign up for the conference on EventBrite.

Hope to see you there!

On Being Excellent to Each Other

2011-06-04T04:16:00.000-07:00

Marcus Zarra has a somewhat depressing post today on the excellent Cocoa is My Girlfriend blog. It's about the release of The Daily. Because of all the secrecy around The Daily prior to its official launch, I think not a lot of people knew Marcus was not just involved with it, but was actually leading much of the development effort.

I knew.

I wasn't on the main development team for The Daily, but I did most of implementation work on a single component (the 360° panorama). I wasn't in NYC every day the way Marcus was, but I went down there enough to know the conditions under which the application was written. I saw the endless late nights (actually, it was usually early mornings) and the stress and difficulties under which the app was written.

A personal stake always makes it harder to watch negative publicity. The Daily's launch was especially hard because I was in a position where I couldn't really come to Marcus' team's defense, since my involvement with the project wasn't yet public knowledge. If it had been, I would have been written off as biased.

So, I had to just sit back and watch it the way you'd watch a trainwreck. It was painful watching the snark. It was painful watching Loren Brichter, a well-respected member of our community put together a carousel demo in a complete vacuum and post a video of it as if it proved something about performance in an incredibly large and complex application. It was even more painful seeing John Gruber link to that video, spreading a false impression to a far wider audience.

They both enough about software development that they should have known better. There's almost no part of The Daily that can't be re-implemented in a few hours as a standalone application using static data and with great performance.

Doing the same thing as part of a large development application developed by a large team, working with a larger management team and a huge content and production teams under an unreasonable deadline and constant pressure? That takes more than being a competent developer. A lot more. It takes patience and diplomacy and a very high tolerance for frustration. I don't think I would've survived in Marcus' shoes all those months. I would've walked out or been escorted out long before the launch ever happened. It was honestly that tough.

I'm not sure that our community is getting quite as bad as it appears to Marcus at the moment, but there is no doubt that we are capable of producing our share of snark. And let's be honest… I am capable of producing more than my individual share. I don't think we think about being mean when we fire off a smug comment. I think it's usually just a side effect of expressing a myopic, partially informed opinion. I'm sure Loren honestly believes he could have done better with the carousel had he been working on The Daily. But he's wrong. He just doesn't know enough about the situation to realize it.

But it's not my intention to point fingers here. I'm been just as guilty at times. Last year, during the WWDC keynote, I was extraordinarily snarky about the Farmville demo, completely forgetting that I know people who worked on it. I wasn't intending to shit on their work, but I did, and I'm sincerely sorry about it. There have been other examples. I hope there won't be more in the future, but only time will tell.

I think Marcus' post should be read and taken to heart by all of us. I think it should serve as a reminder that real people — very often our friends and colleagues — are behind the software and hardware that we express opinions on. We should keep in mind that a lot of work went into it. We should also keep in mind that in most cases, we have no idea the circumstances under which the application was written.

Being critical is not only fine, but a necessary part of driving each other to be better developers. But we should try and avoid being a dick about it. It can be done respectfully, and should be.

I promise to try if you will.

Thoughts on Unity3D

2011-06-03T12:26:00.000-07:00

As I stated in my previous post on 3D engines, I'm going to do four blog posts giving my thoughts on each of the four engines that I looked into using for a project recently. Those four engines are Unity3D, Sio2, Ogre3D, and Cocos3D. I'm starting with Unity3D, which we selected for one of our recent projects.

Now, let me state up front, that all four of these are competent engines and I could see situations where I would recommend three of the four engines for client projects and could easily imagine situations where all four of them would be good choices.These four do not make an exhaustive list; there are other engines out there, including some really good ones, but these were the four that we looked at for this specific project. As much as I like the UDK, for example, I don't like it enough to spend quality time in Windows, so that one is off the table for me until the fine folks at Epic decide to port their dev and content tools to the Mac.

Unity Overview

Unity3D actually predates the iPhone, and of the four engines, it's the one that feels the most mature and has the most robust developer tools. It also has one of the most active developer communities. Unity3D is a closed-source commercial product that you must pay for, which might be a turn-off for some, but it is worth every penny of the license fee.

Unity Pros

Unity is actually fairly easy to learn, yet has a feature set that is compares favorably to most other engines. Unity's asset pipeline is really robust and their tools give you the ability to very quickly make changes and test those changes.

One of the best things about Unity3D is the fact that it supports both Windows and Mac OS equally as development platforms. Regardless of which platform you develop on, you can generate games that runs on every platform Unity supports (assuming you're licensed for it). You can even have part of your team developing on Macs and the other part on Windows with no problems.

At the time I'm writing this, it is possible to generate games from Unity that run on Mac OS X and Windows (both native apps as well as games playable through a web plug-in), iOS, Android, Wii, Xbox 360, and PS3. The Unity folks are also actively working on adding Linux support. Console licenses are negotiated on an individual basis and are likely quite expensive, but it's nice to have the option to take a successful game to so many platforms without having to do a full port each time.

Having had to port OpenGL ES apps from iOS to Android more than once (which is no fun), I can honestly state that the Android support should be a huge selling point you're giving any thought to supporting both iOS and Android.

Unity Cons

The downsides to Unity3D are relatively few, actually.It is the most expensive of the engines I looked at, and the costs are completely front-loaded. You pay a flat per-developer license per platform up front, but then you can create as many games as you want for the platforms you're licensed for. For the basic iOS license, it's $400 per seat (one developer using up to two machines), for the Pro license, you're looking at $3,000 (because the $1,500 iOS Pro requires the $1,500 Unity Pro), which might sound like a lot of money, but it's really a pittance compared to the amount of development time it can save you. The "Basic" version of Unity, which allows you to generate Mac, Windows, and Web games (though excludes some of the more advanced features) is available completely free of charge.

The other potential downside in some situations is that the underlying C++ source code is not available. You work primarily in either JavaScript or C# (MonoScript) and at a higher level of abstraction. Unity supports a few other languages besides Javascript and C#, but only those two languages work for mobile development.

After about two weeks of spending my evenings with Unity, I actually came to the conclusion that not having access to the source isn't really much of a drawback, and for many developers, working this way will be better than working in C++. The engine takes care of almost all the low-level stuff you'd need to do, but even if it doesn't, Unity has a shader language that lets you write code that runs on the GPU and anything that needs to run on the CPU can be done by scripting inside Unity.

Although the programming in Unity3D is done with scripting languages, the scripts you write are actually compiled, so there's not a huge performance overhead to using them. In the exceedingly rare situation where C# or Javascript isn't sufficient, it is possible to send messages into and out of Unity from your application's C or Objective-C code.

Learning Curve

I found Unity surprisingly easy to learn. There are some really good resources out there, including lots of tutorials and instructional videos. I actually had a game functioning after about two hours of playing. It was ugly and the game mechanics were simple, but it was playable. Unity also has a fairly active developer community forum where you can go and get help when you get stuck.

If you don't already know something about graphics programming, you still don't need to be too scared or intimidated. Most of the gnarly stuff is squirreled away where you won't see it until you need it, and you can do a surprising amount by just configuring things in the development GUI. You can create, for example, a fairly full-featured physics simulations without ever writing a line of code. Want to stack up a bunch of crates and roll a ball into them and watch them all fall? You can do it without ever opening a text editor. Heck, you can even do that without opening a 3D program.

Complexity

I was scared of one thing going into learning Unity: I was concerned that because it was so easy (at least I had heard it was), that it was going to be a dumbed down game maker that sacrificed more advanced features for the sake of lowering the obstacles to entry. My fears were completely misplaced, though. That's not the case at all. The Unity folks have done a really great job of making their tools easy to use while still giving you the ability to do most anything you'd ever need to do. It's even possible (though the process is a bit convoluted) to integrate UIKit and Unity3D within the same application.

Asset Pipeline

The thing that actually impressed me most about Unity is what they call their "asset pipeline", which is the process by which you get 3d models, textures, and other assets into your game. If you've ever developed a game or game mod for the UDK, a Valve Source game, or other commercial engine, usually there's kind of a convoluted process you have to go through to get your game assets including characters, textures, props, and environments, into the game. You usually have to use separate applications to specify shaders and physics options, sometimes write a compile script or other text document to define certain trains, and then compile the object and package it all up into some kind of bundle or package. While developing a single mod, you typically iterate through this process many, many times. It can be a bit tedious and hard to learn and usually requires the use of multiple tools and lots of trial and error.

Unity bypasses almost all of this tedium. When you save your assets from your 3D program or Photoshop, you simply save them in your Unity project's Assets folder. When you launch Unity, or navigate back to it if it's already open, Unity detects the new file, or any changes you've made to an existing file. It imports it and adds it to the list of available assets.Anything you need to do that can't be done in your 3D program, such as specify a shader or identify the physics engine properties for the object, you do right in Unity, and most of that can be done without writing code (though everything you can configure without code can also be changed from code).

Which 3D program do you need to use? Pretty much any one you're comfortable with. Unity3D has direct import support for the native file formats from several programs including Blender , but any package that can export to Autodesk FBX or Collada can be used with full support for all features like bones, textures, animations, etc.It also supports native Photoshop files (.psd) for textures, flattening layers in a non-destructive manner when you build your app.Assets can even be given different characteristics for different platforms. You could have, for example, a 2048x2048 texture asset for the desktop version of your game but tell Unity to use a 1024x1024 version for game consoles and a 512x512 version on iOS and Android.

The Bottom Line

As I stated earlier, there are situations where I could see any of the four engines I looked at being a good choice, as could many of the other engines I didn't look at. But, honestly, if I had to make an engine decision without detailed information, Unity3D would be my first recommendation. The tools are solid, the company and community support is awesome, it supports many platforms, and getting assets into your game couldn't be easier. It's relatively easy to start using for both experienced developers and those who aren't.

A good, experienced graphics programmer working in mobile right now can easily ask $200 per hour or more because the demand far outstrips the supply. Figure it out. Unity's full iOS license is basically the equivalent of 15 hours of a graphics programmer's time. Yet, Unity will easily cut five times that many hours off of any decent size software game project's schedule, probably a lot more.

I'm giving Unity3D two big thumbs up. I'm using it on a project now and hope to use it on many more in the future because it's fun to use and removes much of the tedium associated with 3D programming without removing power.

1 Many of the more advanced features require the more expensive "Pro" license, however, and really cutting edge features from the latest games generally take a little while to show up in the tools

A Few Seats Left

2011-05-25T15:27:00.000-07:00

There are a few seats left for the afternoon trip to Cupertino on June 6th. If you're interested, go here.

As I write this, there are less than 15 seats, though, so if you want one, I suggest you hurry.

Bus Update

2011-05-21T09:52:00.001-07:00

Just to let you all know, we're down to eleven remaining available seats on the third and last bus, and they're about equally split between morning and afternoon. If you missed getting a seat on the first two buses, and haven't filled out the interest form for the third, there probably won't be a seat.So, go here now to tell us you're interested in one of the remaining seats. Speak now or forever hold your peace.

Pre-WWDC Schedule Update

2011-05-19T15:54:00.001-07:00

The good news:

The additional bus is a go! We'll be opening up payment for those seats this weekend to people who signed the interest form, and then opening it up to the public 24 hours later until seats are gone. The third bus will leave Moscone a bit later than the other two (11:30 and 3:45), but will not stop at SFO. If you're interested in the additional bus, but need to be picked up at SFO, drop me an e-mail (jeff at martiancraft dot com) or send me a tweet, and we'll see if we can find a way to accommodate you by shuffling a few seats. Update: The third bus will stop at SFO!.

The bad news:

There will not be another bus once we fill this one. We're already threatening to overflow both The Company Store and BJ's, a fourth bus would be overkill even if we were sure we could fill it, which I'm not at all sure we could do anyway.As of right now, there are approximately 25 spaces left on the third and final bus.

The interest form will remain open until we either run out of seats, or we open up the reservation payment again. People who signed up on interest form get dibs on the remaining seats.One final note: last year, we had some people show up without signing up in advance. Please don't do that this year. Simply put, we won't have any place to put you. The bus company won't let people stand while the bus is driving, so if you're interested in going, you've got to reverse a seat in advance.

Pre-WWDC 2011 Pilgrimage Additional Buses

2011-05-18T10:37:00.001-07:00

Okay, here's the deal folks. We're trying to find out from the bus company what are options are. In the meantime, we need to know how many of you are interested in a seat on the bus. If you want to go, and didn't get a seat, you need to go fill out this form right now.If we get enough interest to cover the cost of another bus, we'll then send you all information on how to pay for your seats. Spread the word, because we really don't want anybody to get left behind if at all possible.

Sold Out

2011-05-17T22:47:00.001-07:00

Okay, I'm just about to head to bed, but wanted to let you know that we've officially sold out all four bus trips for the June 5 pilgrimage. Scott and I are going to regroup in the morning and see what our options are for adding capacity.Because we have to pay for buses by the day and not per trip, we have to be sure we can fill two more bus trips in order to cover the cost of adding an additional bus. We're also going to see if adding a smaller bus is a possibility and how that would impact the per-seat price.Whatever we do, I'll post about it here and also tweet it. But not until tomorrow.G'night.

Pre-WWDC Pilgrimage 2011 Update

2011-05-17T13:46:00.001-07:00

If you signed the interest form, you should have received an e-mail telling you how to reserve seats on the pilgrimage buses. If you did sign the earlier form but didn't get an e-mail, let me know.If you didn't sign the interest sheet, don't worry, we'll be opening registration up to the public tomorrow. We thought it only fair to give the people who signed up in advance a bit of a head start.We should have enough room for everybody, as we're able to add additional buses if we need more capacity. We just have to make sure that we have enough additional people to cover the cost of another bus.Keep an eye here or follow me on twitter to find out when we open registration up to everyone else.

3D Game and Graphics Engines

2011-05-14T07:44:00.001-07:00

One thing that I get asked about a lot is whether you should use a game or graphics engine instead of learning OpenGL ES. Often, these emails are prefaced by a statement about how hard graphics programming. I've had to answer this question enough times now that it seems like a good topic for a blog post.

Honestly, I find it kind of hard to answer, because I don't see the "using an engine" and "learning graphics programming" as being distinct or mutually exclusive approaches. While a good game or graphics engine will handle a lot of the more gnarly programming tasks for you and shorten your development time, you still need to understand the underlying concepts to build anything of any complexity.

All of these engines are built on top of OpenGL (and/or DirectX if they support Windows), and are subject to the same limitations and strengths. Not understanding, at least at some level, how these lower-level graphics libraries work and the basic maths of 3D programming will eventually hold you back.

But… that doesn't necessarily mean you need to learn OpenGL before you can start using these tools effectively. You don't. It's just that some of the difficult, sticky math and concepts that might be scaring you away from OpenGL are still there (though better hidden), and you may well still have to deal with them at some point if you're doing the coding on the game (as opposed to just creating assets or doing level design).

Here's kind of a simple nutshell rule:

If you love graphics programming or are fascinated by it, then study OpenGL ES and the underlying maths and forget about using the engines at first (though studying their source is a great way to learn). There's always going to be work for good graphics programmers and you can't put a price tag on doing what you love.

If, on the other hand, your goal is to make a game or other graphics-heavy application, and graphics programming is just a means to that end, then use an engine, because it will shorten the amount of work you have to do tremendously, which inherently increases your chances of making money because time is money and there's never enough of it.

So, when shouldn't you use an existing engine if your goal is to make a game and not to try and be the next John Carmack? Almost never. Rolling your own game engine should be a labor of love. It's got to be an itch you can't scratch; the kind of desire that I probably couldn't talk you out of anyway. Otherwise, it's just a waste of your time.

What about when there just isn't an engine that works for what you want to do?

Honestly, that's not all that likely in this day and age, but even if it is, you're far better off starting with an existing engine and then modifying it to meet your needs.

From a business and financial perspective, it's almost never better to start from scratch. Even many of the AAA commercial game engines are derivatives of other engines. To give an example: Valve's Source Engine, is derived from their older Goldsource Engine, which itself was forked from the Quake Engine back around 1996.

Though there are quite a few game engines around, a very large percentage of high-end commercial games, both console and PC, are based on either the Unreal engine or the Quake engine or one of their derivatives. If you throw in a handful of other engines, like the CryEngine, you've probably covered all but a few outliers.

If it's not cost effective for large, multi-person development teams with multi-million dollar budgets to develop their own game engines, it's probably not the best choice for individual indie developers or small shops.

So, don't reinvent the wheel. Use an engine and stand on the shoulders of John Carmack and others like him. Don't spend your time trying to solve problems that are long-solved. Just be aware that using an engine can't completely eliminate the need to learn a little math or to understand the underlying concepts.

Engines

It just so happens that for a number of proposals I've done lately, I've been looking at game engines in some depth. I'm not going to do "reviews" per se, but over the next few weeks, I will try and post my thoughts about several of the engines available for iOS, including Unity3D, Sio2, Ogre3D, and Cocos3D.

I won't be discussing the UDK, even though it's a phenomenal engine, because it requires using Windows for many tasks, and I don't want to spend time in Windows. If you've got both a Mac and a Windows machine, however, and don't mind splitting time between OS X and Windows, you might want to check it out. A lot of time and brainpower has gone into getting the UDK to have incredible performance on iOS and the license terms have been changed to be much more friendly to small indie shops ($99 plus 25% of royalties after the first $50,000).

Empty OpenGL ES Application Xcode 4 Template

2011-05-04T11:18:00.001-07:00

Jacques De Schepper sent in an updated version of my old Empty OpenGL ES Application Template, updated to use Xcode 4's completely revamped templating mechanism. You can download the new Xcode 4 version of the template right here. I haven't had a chance yet to test this out, but once I do, I'll also add it to GitHub.Thanks, Jacques!

Bus Trip Update

2011-05-03T07:18:00.001-07:00

Just wanted to give you all an update on the bus pilgrimage to Cupertino on June 5th. We had a tremendous show of interest. Approximately 300 people expressed an interest, plus several people tweeted and e-mailed after the interest form was closed down. Last year, we took 100 people.

Scott Knaster is investigating bus options, including a possible bus directly from SFO to the Apple Store and then up to WWDC for people who wouldn't be able to get up to San Francisco in time for the bus.

We'll start the official signups the middle of this month, once all the arrangements are squared away and we know how many seats there will be. Once the arrangements are made, the seats will be made available on a first-come, first-served basis. If you filled out the interest form, you'll get an e-mail with details of how to reserve your seat and pay for it as soon as signup opens. If you didn't fill out the interest form, you probably want to follow me or Scott on Twitter, as we'll tweet when the signups start and then periodically re-tweet until the seats are gone.

I want to set expectations, especially for first timers. The only thing open at Apple HQ will be The Company Store, which is similar to an Apple Store, but with a lot of Apple schwag and paraphernalia (t-shirts, pens, mugs, sweatshirts, etc). Being not just a Sunday, but the Sunday before WWDC, don't expect to see many Apple employees coming and going, and you will definitely not be able to get into the quad (the inside portion of One Infinite Loop). There is no official Apple recognition of this trip, and we don't have any expectation that there will be.

In the parking lot near The Company Store, there is a restaurant called BJ's, affectionately referred to as "IL7" by Apple employees (the buildings at One Infinite Loop are named IL1 through IL6), which is fairly good for what it is. You can have lunch or a drink there, but if you do, I advise you to order quickly and have your check brought with your food. Since the same bus will be used for multiple trips, we won't be able to wait for stragglers. The bus will leave at the scheduled departure time with or without you. We didn't leave anybody behind last year, but we had one table that cut it awfully, awfully close. It's an awfully long damn walk back to San Francisco, and they get pretty busy on Sundays even without a bus full of additional customers.

Lastly, if you see Scott on Sunday, make sure to say a big thank you to him. Scott has done nearly all of the legwork again this year and the trip is happening very much because of him, so thanks Scott!

Appsterdam

2011-04-22T16:28:00.001-07:00

You may have been hearing some rumors and jokes around Twitter concerning something called "Appsterdam". If you've been wondering what that's all about, wonder no longer, Mike Lee lays it all out for you. It's an interesting idea, and I must admit I'm intrigued and would love to go. For a handful of personal reasons, I simply can't expatriate to Amsterdam at this point in my life, but I am seriously considering going over a few times per year to soak up the community, and if things take off, who knows? My reasons for not going are relatively temporary.

The nice thing about what we all do is that it really doesn't matter where we do it, so I can work from Amsterdam just as easily as from my house.

WWDC Mothership Pilgrimage 2011

2011-04-16T09:28:00.001-07:00

Okay, after telling many people I wasn't going to organize a trip to the Mothership on the Sunday before WWDC, I may have had a change of heart. Scott Knaster, who did most of the hard leg work on arranging the buses last year, has offered to take the same role this year, and a lot of people have expressed interest, so we're thinking about running the bus trip again this year.

If you're interested in taking the bus trip down to One Infinite Loop, go here and fill out the short form. This will help us gauge how many buses we'll need to arrange.

If anybody's interested in sponsoring all or part of the trip, do let me know.

MacBook Air 11" as Dev Machine

2011-04-12T09:37:00.001-07:00

I just got back home from Seattle, where I went to attend and speak at Voices that Matter. The VTM folks put on a great conference, as always, and I'll have more to say about that in future blog posts. But, I wanted to quickly address a question I've been asked numerous times this weekend both over Twitter and in real life. That question was "how productive were you able to be with just an 11" MacBook Air?"

If you follow me on Twitter, you know that after years of using Apple's biggest and most powerful laptops (17" MacBooks and 17" PowerBooks before that), I bought Apple's smallest, least powerful one. This weekend, I decided to experiment by traveling very light. Besides the MacBook Air, my computer bag had an iPad2, a Clear 4G+, the various cables and power cords for those devices, and a mechanical pencil, nothing more. My entire bag weighed 6 pounds, which was quite a change from the monstrosity I usually have with me when I travel to conferences. With a larger computer comes a larger bag with more room for storage that inevitably gets filled with things I might maybe possibly need.

So, how'd it work out?

Absolutely perfectly. Despite being considerably less powerful, the 11" MacBook Air rarely feels slow thanks to the SSD. Certain things take noticeably longer (compiling large applications), but the vast majority of day-to-day tasks feel downright snappy.

The screen is small, but it's a pretty high pixel density, so it's not quite as confining as you might expect. With a few changes to my coding habits, which included going from Menlo-10 to Menlo-9 as my coding font, and committing the Xcode key commands to to hide and show panes to memory, I quickly settled into a workflow that worked really, really well for me.

There may have been a very slight hit to productivity, but it wasn't bad, and it was more than offset by the fact that I could use the laptop anywhere, even sitting in coach. My 17" MacBook Pro is basically unusable in coach if the person in front of me reclines their seat. And the person in front of me always reclines their seat. I got a solid 4 or 5 hours of coding in yesterday that I wouldn't have gotten with my bigger laptop.

So, yeah. It worked out great.

A couple of times this weekend, I was also asked a related question, which is "could you use it as your main development machine?".

The answer to that is "I could, but probably wouldn't want to". However, that's because of factors that probably don't impact most developers. The nature of several of our clients (sorry I can't be more specific than that) means that a lot of our mockups and images come to us as very, very, very large Photoshop files with lots of layers. I regularly have to deal with Photoshop files that are a gigabyte in size or larger.

If it weren't for that, and my occasional dabbling in 3D graphics programming, I definitely could use this machine full time. In fact, an 11" MacBook Air with a 27" Apple display, would be a very capable iPhone dev machine for most developers, though I would definitely buy the "ultimate configuration" if you are looking at getting one.

Blender 2.57 Objective-C Export Script

2011-04-05T11:42:00.001-07:00

A few days ago, the Blender Foundation put out the first release candidate of Blender 2.5. This release unexpectedly broke compatibility with most existing 2.5 python scripts, including my Objective-C header Export Script.

Which was great timing, since I needed to use the script today. I could've just gone back to an older version of Blender, but decided instead to re-write the script to work. I just added to GitHub, the new 2.57 compatible version of the export script. This version is back to being an add-on that you can add through the User Preferences.

I've also added a few options that you can select when exporting (they're on the left side of the file selection screen, underneath the volumes and recently visited locations). You can see the new options in the following screen grab:

The first option lets you specify whether modifiers are applied before exporting the mesh. If you uncheck this, the script will strip the modifiers before exporting, otherwise, it will apply them to the mesh before exporting.

The second option will rotate the object 90° along the X axis, which converts the object from Blender's Z-up coordinate space to OpenGL's Y-up coordinate space. I've made this the default, but I could foresee situations where people would want to skip the conversion.

The final option will move the export the object using its world space coordinates rather than exporting it using object space coordinates. This option will, for example, preserve relative distance between multiple objects exported from the same file into different headers. Or, to put it another way, objects exported will normally have use their coordinates as they relate to the object's origin, regardless of where the object is in the Blender scene. If this is checked, the vertex coordinates will be exported relative to the scene's origin.

NB: There was a problem with the triangulation code in the version posted earlier. If you're having problems, pull again from GitHub.

App Store Review Times by Shiny Development

2011-04-05T09:53:00.001-07:00

Dave Verwer of Shiny Development has created a web bot that trolls Twitter for tweets about App Store review times and maintains a running average of both iOS and Mac review times. The results are continuously available at this website. The more people who contribute, the better the data will be, so if you want to contribute, just tweet your review time using the #iosreviewtime or #macreviewtime hash tags like the example tweet.

Voices that Matter Seattle

2011-04-03T07:04:00.001-07:00

This is just a reminder that Voices that Matter Seattle is this coming weekend. I'll be presenting on iOS Multitasking on Sunday morning. I'm really looking forward to it. It looks like there's still space available if you're free this weekend.

Briefs is Dead, Long Live the Briefs

2011-03-29T07:00:00.001-07:00

Rob, one of my MartianCraft partners-in-crime, decided to throw in the towel last night on Briefs.app. After a solid year of fighting with Apple's app review team, implementing changes that were suggested might clear the path for getting Briefs.app on the App Store, and trying to just get a straight answer from Apple about what the real problem was, he's finally decided it's just not worth the hassle any more.

There were several lights at the end of the tunnel over the course of the year, each one a bigger and faster freight train. Despite the changes to the license agreement that seemed to imply Apple was going to become more reasonable on this subject, they continued to insist that Briefs allowed users to download and run executable code and is dangerous.

I don't like that answer, but if that was the answer, they should have manned up and told him that a year ago rather than stringing him along, giving him false hope, and enticing him to invest more time he doesn't have on a fruitless endeavor.

This was no way to treat a third party dev, and Rob has been way too nice about the whole damn situation.

On WWDC Now Being "Broken"

2011-03-28T19:32:00.001-07:00

Over at TUAW, fellow author Erica Sadun opines that WWDC is broken because it sold out fast. And she's right. It's so horribly broken that more people want to attend than they've got room for. Th… wait, what? Where I come from, that's called "success", and it usually indicates that you're doing something right. It's not usually a big red flag that you need to make a complete about face in your approach.

But that's exactly what Erica is suggesting Apple do.

I used to work in the Enterprise software world and know all about these large conferences that Erica is referencing. I was a developer at PeopleSoft (now part of Oracle), and I've been to (and have even spoken at) mega Enterprise conferences like the old PeopleSoft conferences (20k attendees at its peak) and OracleWorld (which is now, I guess, called Oracle OpenWorld because Oracle is so… open).

Making WWDC more like these giant, soulless, "enterprise" conferences is not the answer. Scaling WWDC to 10k, 20k or 40k is fixing the problem by shooting the golden goose. Trying to scale up WWDC like that would utterly destroy everything that is wonderful about it.

WWDC is community. WWDC is actually being able to talk with the engineers who wrote the software you're having problems using. WWDC is a chance to get on a first name basis with people in our community, including (if you're lucky) some of the awesome people who make the APIs we use to make our living. It's a time for learning, absolutely, but it's also for making friendships, making business connections, and looking for future employees/employers/subcontractors. The current size of WWDC is part of what makes it great and is part of why so many people want to attend. In fact, the past few years, it's bordered on being too big, with lab slots becoming harder to get and many sessions having long lines and being standing room only.

What WWDC is, is not what giant corporate conferences like OracleWorld are. If anything, they're the polar opposite. Which is not to knock what those big conferences are - they serve a particular market, and they serve it well, but we are not their market and our needs cannot be met by adopting their model. Conferences like Oracle World are places where groups of people from the same large company or government entity go together, hang out together, and then leave together. They're places that people go because their employer is paying for them to go and has instructed them to go. They're places where people wander through large convention halls picking up swag they don't really want while being sold on the merits of various products their employers don't really need. They're vendor fair as much as a place to learn. In fact, they're usually more like one big fucking advertisement that your company pays for you to attend.

They are not events (by and large) that people save up and do without in order to attend. They're not events that people make sacrifices in order to find a way to go.

But that's exactly what WWDC is. WWDC is a conference that people want to go to even if they have to pay money out of their own pocket. It's something people look forward to attending and talk about having attended for months afterwards. It's a conference where a great many people pay their own way to attend and are thrilled to do so.

Monstrous mega-conferences don't develop community. That's simply not what they're there for. Forty thousand people isn't a community: It's a city. Forty thousand people is so far beyond anybody's monkeysphere as to make the concept of "community" meaningless. Wandering around conferences like OpenWorld no more engenders a sense of community than does walking through Times Square.

I don't want WWDC to become that. You don't want WWDC to become that. I honestly don't even think Erica really wants WWDC to become that. I think what she wants is a perfectly egalitarian world where everybody gets what they want. But that only exists in fiction. In real life, everything involves tradeoffs, and the tradeoffs with her suggested solution would be disastrous for our community.

Scarcity always increases value. Apple could have chosen to jack up the WWDC ticket price until they stopped selling out, but they didn't do that. In fact, the price hasn't increased in years. Yes, they did get rid of the early-bird pricing and group rates, but the base ticket price for WWDC has remained unchanged for quite some time (8 years maybe? Anyone know?). Apple could gouge us and many of us would pay the inflated price happily. But they don't do that. In fact, they charge us less than the early bird prices at big mega-conferences like Oracle OpenWorld, Tech Ed, and PDC, despite the fact that WWDC has no sponsors or advertisers and no vendor floor.

The simple fact of the matter is that any mechanism that Apple might implement to "level the playing field" for tickets would result in somebody feeling like they didn't get a fair chance to purchase. The more complex the scheme and the more advance notice Apple were to give, the more opportunities there would be for people to game the system and create true inequity in the process.

What Apple did do was put WWDC tickets on sale without advance notice and sold them on a first come, first served basis. That's not perfect, but it is about as close to a level playing field as you can get. Yes, some people were on planes, and some people were sleeping (including people in Silicon Valley, it should be noted), and some just weren't paying attention to the Internet when the tickets went on sale. But those tickets were available for over ten hours and everybody should have known they were going to sell out quickly. Yes, people got left out, and it sucks. That's the nature of scarcity.

This is not an artificial scarcity, however. WWDC tickets are like money, you can't just solve the scarcity by printing more tickets. Every additional ticket reduces the value of the conference to the rest of the attendees. Letting everybody have what they want means nobody gets what they really want, or need.

I'll take scarcity and a once-a-year scramble to buy tickets before they sell out over a soulless commodity conference like OpenWorld any day, thank you.

WWDC 2011 is Sold Out.

2011-03-28T15:55:00.001-07:00

I told you they'd go fast.

WWDC First Timer's Survival Guide, 2011 Edition

2011-03-28T07:49:00.001-07:00

Today, WWDC was announced. This is the earliest they've announced WWDC during the iPhone epoch, so there's a little more time to prepare than we've had the last few years. Given how popular it's been the past few years, I thought it was worth updating and re-posting my WWDC First Time Guide from last year and the previous year.

Again, WWDC is different every year, so don't take anything written here as gospel, but hopefully these hints and suggestions will help some of you.

Arrive on Sunday or Earlier. Registration is usually open most of the day on Sunday. You really, really want to get your badge and related swag (bag, shirt, jacket, etc) on Sunday. The line for the keynote will start forming many hours before the doors to Moscone West open up on Monday (the past three years, people started lining up before midnight Sunday). If you do not have your badge when you get to Moscone on Monday morning, you will almost certainly end up in an overflow room for the Keynote and may even miss part of it. Even if you don't care about being in the main room, there's still a lot going on on Sunday and it's a good time to meet new people and catch up with old friends. You really don't want to deal with the badge process on Monday.

Do not lose your badge. If you lose it, you are done. You will spend your time crying on the short steps in front of Moscone West while you watch everyone else go in to get schooled. Sure, you'll still be able to attend the unofficial after-hours goings-on (but not the Thursday night party, which is usually a blast), but you'll miss out on the really important stuff. No amount of begging or pleading will get you a replacement badge, and since they're likely to sell out, no amount of money will get you another one, either. And that would suck. Treat it like gold. When I'm not in Moscone West or somewhere else where I need the badge, I put it in my backpack, clipped to my backpack's keyper (the little hook designed to hold your keys so they don't get lost in the bottom of your bag). Yes, there have been isolated stories of people managing to convince a sympathetic conference worker to print them a new badge, but don't expect it, those are exceptions. The employees are not supposed to print new badges, and most won't.

Eat your fill. They will feed you two meals a day; you're on your own for dinner. Breakfast starts a half-hour before the first session, and it's most likely going to be a continental breakfast - fruit, pastries, juice, coffee, donuts, toast, and those round dinner rolls that Californians think are bagels, but really aren't. If you're diabetic, need to eat gluten-free, or are an early riser, you'll probably want to eat before-hand. Lunch used to be (IIRC) a hot lunch, but three or four years ago they switched to boxed lunches. They are pretty good as far as boxed lunches go, but they are boxed lunches. A lot of people complain (loudly) about them and choose to go to a nearby restaurant during the lunch break, which is pretty long - at least 90 minutes.

Party hard (not that you have a choice). There are lots of official and unofficial events in the evening. There's often a CocoaHeads meeting at the Apple Store. It fills up crazy fast, so go early if you go. It's usually competing with several other parties, but it starts earlier than most events and finishes early enough for people to go to other parties when it's done. Best bet is to follow as many iPhone and Mac devs on Twitter that you can - the unofficial gatherings happen at various places downtown, often starting with a few "seed crystal" developers stopping for a drink and tweeting their whereabouts. The unofficial, spontaneous gatherings can be really fun and a great opportunity. The parties often start before WWDC - there are usually a few on Sunday, and there have been ones as early as Saturday before. Pretty much any other bar within stumbling distance of Moscone West will be used for planned and informal gatherings. As we get closer, there will be lists and calendars devoted to all the events and parties. Some are invite-only, but many are first-come, first-serve. Although there's a lot of drinking going on, these are worth attending even if you don't drink. Great people, great conversations... good times.

At some point, one or more lists will pop up to track the official parties, gatherings, meet-ups, and BOF (birds of a feather meetings - meet-ups for people interested in a particular subject).

Take good notes. You are going to be drinking knowledge from a firehose there. The information will come at you fast and furious. As an attendee, you will get all the session videos on ADC on iTunes. It used to take some time before the videos were available, but hopefully they'll continue to get them out quickly. Even so, make sure you write down the information you need immediately.

Collaborative note taking A few years ago, people started taking communal notes using SubEthaEdit and Panic's Coda (they are compatible with each other). That worked out really, really well. My notes from the past few years are ten times better than from previous years. With SubEthaEdit, you don't have to type fast enough to catch every detail. Instead, the audience works as a team and everybody gets great notes. The license fee pays for itself in one WWDC, especially considering you can see notes being taken in other sessions, not just your own.

Labs rule. If you're having a problem, find an appropriate lab. One of the concierges at any of the labs can tell you exactly which teams and/or which Apple employees will be at which labs when. If you're having an audio problem, you can easily stalk the Core Audio team until they beat the information into your skull, for example. It's unstructured, hands-on time with the people who write the frameworks and applications we use every day. People start remembering the labs later in the week it seems, but early on, you can often get an engineer all to yourself, though people have started to catch on. Every year the labs fill up earlier in the week.

Buddy up, divide and conquer There will be at least a few times when you want to be at more than one presentation at the same time. Find someone who's attending one and go to the other (Twitter is a good way to find people), then share your notes.

Make sure to sleep on the plane. You won't get many other chances once you get there. Everybody is ragged by Friday, some of us even earlier. Everyone remains surprisingly polite given how sleep-deprived and/or hungover people are.

Thank your hosts. The folks at Apple - the engineers and evangelists who give the presentations and staff the labs, kill themselves for months to make WWDC such a great event. So, do your mother proud and remember your manners. Say thank you when someone helps you, or even if they try and don't. And if you see one of them at an after hours event, it's quite alright to buy them a beer to say thanks.

Remember you're under NDA. This one is hard, especially for me. We see so much exciting amazing stuff that week that it's natural to want to tweet it, blog it, or even tell the guy handing out advertisements for strip joints on the corner all about it. Don't. Everything, from morning to night except the Keynote and the Thursday night party are under NDA.

Brown Bag it. Most days there are "brown bag" sessions. These are speakers not from Apple who give entertaining, enlightening, or inspiring talks at lunchtime. Check the schedule, some of them are bound to be well worth your time.

Monday, Monday I don't know what to say about Monday. The last few years, people started lining up before midnight the night before. I'm typically on East coast time and usually walk over around 4:15 to see what's going on. I've done the line, and I've done the have-a-leisurely-breakfast route, and both have their merits. If you straggle too much, they may start before you get in the room, however (happened to me two years ago).

Waiting in line is not really my thing, but you do get to talk to a lot of very cool people while waiting in line, and there is a sense of camaraderie that develops when you do something silly with other people like that. Some people probably want me to suggest what time to get in line. I have no idea. Most people will get into the main room to see the Keynote. There will be some people diverted to an overflow room, but because the number of attendees is relatively low and the Presidio (the keynote room) is so big, it's a tiny percentage who have to go to the overflow rooms (maybe the last 1,000 to 1,500 or so, depending on number of VIPs in attendance). On the other hand, you'll actually get a better view in the overflow rooms unless you get in line crazy early - you'll get to watch it in real time on huge screens and you'll get to see what's happening better than the people at the back of the Presidio. So, go when you want to. If you want to get up early and go be one of the "crazy ones", cool! If you want to get up later, you'll still get to see the keynote sitting in a comfy room with other geeks.

Turn off your MiFi/Clear/other wireless router. I'm so totally not kidding on this one. People will punch you if they find out you've got one on. Last year, so many people had MiFis and other mobile hotspots running during the keynote that it interfered with the conference center's (very good) WiFi network and disrupted some of the tech demos. Once you're in the building, you don't need it. They have crazy fast pipe in the building, so just use the provided WiFi and turn your wireless router off. Seriously.

Park it once in a while There will be time between sessions, and maybe even one or two slots that have nothing you're interested in. Or, you might find yourself just too tired to take in the inner workings of some technology. In that case, there are several lounges around where you can crash in a bean bag chair, comfy chair, moderately-comfy chair, or patch of floor. There is good wi-fi throughout the building and crazy-fast wired connections and outlets in various spots on all floors. So, find a spot, tweet your location, and zone out for a little while or do some coding. You never know who you might end up talking with. If you move around too much, well, let's just say a moving target is harder to hit than a stationary one.

Twitter is invaluable, but don't expect it to stay up during the keynote. There's really no better way to hook up with people you didn't travel with than Twitter. Two years ago, we completely overwhelmed twitter during the keynote. Last year it fared okay, though there were some delays and hiccups.

It's okay to leave. Don't worry if a few minutes into a session you decide that you've made a horrible mistake and it's too boring/advanced/simple/etc, or you're just too hungover. Just get up and leave quietly and wander to a different session. Nobody is going to be offended if you leave politely and without causing a disturbance.

Bring proof of age on Thursday night. The official party is always on Thursday night, and it's always a blast. There's good food, good drink, great company, and usually a pretty good band. The last three years featured OK, Go, Cake, and the Bare Naked Ladies. They are pretty strict about making sure only people who are over 21 get alcohol. So, if you want to have a drink or five on Thursday, don't leave your license or passport in your hotel room, even if you're 70 years old.

It's okay to take breaks. Your first time, you're going to be tempted to go to every session you possibly can. Somewhere around Wednesday or Thursday, though, that effort combined with lack of sleep, is going to take its toll on you. If you're too tired or overwhelmed to process information, it's okay to hole up on a couch or at a table instead of going to a session, or even to go back to your hotel (you did get a close one, right?). In fact, it's a darn good idea to map out a few "sacrificial" time slots that won't feel bad about missing just in case you need a break. You don't want to burn out and then miss something you are really interested in. And some of the best, more advanced sessions fall at the end of the week, so don't shoot your wad early in the week.

Get a close hotel If at all possible, try and get a hotel within two blocks and definitely not more than five blocks from Moscone West. Five blocks doesn't seem like a lot, but it can become quite a hassle, especially if you're North of Moscone West because you'll be climbing up a pretty decent hill in one direction.

Official Evening Events In addition to the Thursday night Beer Bash, there are other official activities in the evening that are very entertaining and usually happen in the early evening before the parties really get going. The two stalwarts are the Apple Design Awards and Stump the Chumps (it's actually called "Stump the Experts", but most of the participants refer to it as "Stump the Chumps"). Stump the Experts is an Apple trivia game-show like event with notable tech luminaries and former Apple employees. Lots of sharp wits and deep knowledge of Apple make for some good entertainment. There used to also be a Monday night reception and cocktail hour, but if memory serves, it hasn't happened in a few years.

Take the BART If you're flying into either SFO or OAK and are staying near Moscone West (or near any BART station) there's really no reason to bother with renting a car or taking a cab from the airport. Just take BART and get off at the Powell Street station and walk up 4th street (South). Moscone West will be about four blocks on your right.

Bring a Sweatshirt or Jacket A lot of first-timers assume that it's California in the summer so it's going to be hot. Well, it could be, during the middle of the day, but look up Mark Twain's quote about San Francisco in the summer. It can be downright cool in San Francisco in the summer time, especially in the evenings and early morning. Bring a sweatshirt or light jacket, and wear layers because the temperature differential over the course of the day can be forty or fifty degrees.

Sample Code Many sessions will have sample code, usually downloadable from the schedule or class descriptions web pages. The sample code will stay up for a while, but may not stay around forever, so it's a good idea to download any code samples you want as soon as you can. Edit: It looks like starting with 2009, you can get to the old source code for years you attended by logging in to ADC on iTunes, however I always save off a copy just in case.

Get a Battery Pack You might want to consider a battery pack for your iPhone. You'll be in for some very long days, and it's not uncommon for your phone to be bone dry by early evening if you don't remember to charge it during the day. AT&T reception in San Francisco is notoriously bad, and that takes a toll on battery life.

Don't Sound Like a N00b It's technically called the "World Wide Developer's Conference", so logically, you'd expect people to refer to it as "the WWDC" (e.g. "I'm going to head over to the WWDC")… only nobody does. It's just "WWDC" ("are you gong to WWDC this year?). Less commonly, it's also called the "Dubdub", with or without the "the": ("Man, what an awesome Dubdub that was", or "What time are you heading over to the Dubdub?").

Have more suggestions for first-timers? Add them to the comments.

WWDC 2011 Announced

2011-03-28T06:31:00.001-07:00

June 6-10 at Moscone West. You should go. If you're going to go, don't wait, they will sell out.

Attributed Strings in iOS

2011-03-10T15:11:00.001-08:00

Ten months ago when the original iPad shipped, Apple released iOS 3.2, and for the first time, iOS developers had access to NSAttributedString and NSMutableAttributedString, objects designed to hold strings along with font, paragraph, and style information. We no longer had to resort to using heavy UIWebViews or complex Core Graphics calls to draw styled text.

Well, sort of…

On the Mac side of things, NSAttributedString and its counterpart NSMutableAttributedString have been around for a long, long time, as part of Foundation. But, there's also been, for nearly as long, categories on both of these classes in App Kit called the Application Kit Additions which have all sorts of useful additional methods.

These categories provide ways to create attributed strings from various sorts of formatted text documents (RTF, HTML), to create attributed strings by specifying multiple specified attributes, to tweak existing attributes, to draw the attributed string, and to determine the size of an attributed string if it were to be drawn.

In fact, most of the really useful methods for these two classes are contained in these App Kit categories and not in the base classes. Unfortunately, we don't have those categories in the iOS SDK, or even a scaled back version of them. We just have the base classes. That means we have a whopping thirteen methods on NSAttributedString, and another thirteen on NSMutableAttributedString.

Cocoa has luxury-brand attributed strings; Cocoa touch has store-brand generic ones.

Even weirder, NSAttributedString has an init method that takes a dictionary of string attributes, but the key constants for using that method aren't even included in iOS in either the public headers or the documentation. The description of the methods that take these attributes state that the constants are in the Overview section of the documentation, but that's actually only true in the Mac OS X documentation, not the iOS documentation.

In other words, you can't create an NSAttributedString or NSMutableAttributedString using initWithString:attributes: because you don't have the constants you need in order to specify the various attributes. That's not entirely true; you actually are able to use the Core Text counterparts of the NSAttributedString constants , such as kCTForegroundColorAttributeName in place of NSForegroundColorAttributeName, however this isn't actually documented anywhere, and there isn't an exact 1:1 correlation between the NS and CT string attributes (though it's close).

This situation is really odd. Apple went through great efforts to give us all the low-level pieces need to do complex text rendering, but didn't give us higher-level objects to handle most that functionality elegantly. We have the lion's share of all of the low-level Core Text and Core Graphics calls that are available on Mac OS X (still no Core Image, though). Yet, we have to write low-level Core Text and Core Graphics code to do the bulk of even the most common typesetting tasks using attributed strings.

Fortunately, NSAttributedString and NSMutableAttributedString are both toll-free bridged to their Core Foundation counterparts CFAttributedStringRef and CFMutableAttributedStringRef respectively. That means you can create, for example, a CFAttributedStringRef and simply cast it to an NSAttributedString pointer, and then calling NSAttributedString methods on it will work.

Mostly.

There's one gotcha here. On iOS, UIFont and CTFont are not toll-free bridged, even though NSFont and CTFont on the Mac are. You cannot pass a UIFont into a function that expects a CTFont and vice versa.

To get a CTFont from a UIFont, you can do this:

CTFontRef CTFontCreateFromUIFont(UIFont *font)
{
    CTFontRef ctFont = CTFontCreateWithName((CFStringRef)font.fontName, 
                                            font.pointSize, 
                                            NULL);
    return ctFont;
}

Notice the name of this method - the word "create" in the function name indicates that the returned CTFont object has been retained for you, and you are responsible for calling CFRelease() on it when you're done with it, to avoid leaking.

Going the other way, from a CTFont to a UIFont is only a little more involved. Here's a category method on UIFont that will create an instance of UIFont based on a CTFontRef pointer

@implementation UIFont(MCUtilities)
+ (id)fontWithCTFont:(CTFontRef)ctFont
{
    CFStringRef fontName = CTFontCopyFullName(ctFont);
    CGFloat fontSize = CTFontGetSize(ctFont);
    
    UIFont *ret = [UIFont fontWithName:(NSString *)fontName size:fontSize];
    CFRelease(fontName);
    return ret;
}
@end

Once you have the ability to convert the two font objects into each other, creating attributed strings really isn't that bad. Here's an example category method on NSMutableAttributedString that will create an instance by taking an NSString plus a font, a font size, and a constant representing the desired text justification. It will return an autoreleased attributed string with the text attributes applied to the entire string:

+ (id)mutableAttributedStringWithString:(NSString *)string font:(UIFont *)font color:(UIColor *)color alignment:(CTTextAlignment)alignment

{
    CFMutableAttributedStringRef attrString = CFAttributedStringCreateMutable(kCFAllocatorDefault, 0);
    
    if (string != nil)
        CFAttributedStringReplaceString (attrString, CFRangeMake(0, 0), (CFStringRef)string);
    
    CFAttributedStringSetAttribute(attrString, CFRangeMake(0, CFAttributedStringGetLength(attrString)), kCTForegroundColorAttributeName, color.CGColor);
    CTFontRef theFont = CTFontCreateFromUIFont(font);
    CFAttributedStringSetAttribute(attrString, CFRangeMake(0, CFAttributedStringGetLength(attrString)), kCTFontAttributeName, theFont);
    CFRelease(theFont);
    
    CTParagraphStyleSetting settings[] = {kCTParagraphStyleSpecifierAlignment, sizeof(alignment), &alignment};
    CTParagraphStyleRef paragraphStyle = CTParagraphStyleCreate(settings, sizeof(settings) / sizeof(settings[0]));
    CFAttributedStringSetAttribute(attrString, CFRangeMake(0, CFAttributedStringGetLength(attrString)), kCTParagraphStyleAttributeName, paragraphStyle);    
    CFRelease(paragraphStyle);

    
    NSMutableAttributedString *ret = (NSMutableAttributedString *)attrString;
    
    return [ret autorelease];
}

What about calculating the space needed to draw an attributable string? That's a little more involved, but it can be done. Here are two category methods on NSAttributedStringthat will tell you how much space an attributed string will require when drawn at a specified width or height, which is a useful thing to know when laying out text:

NB(1): This is a new version that's both shorter, and fixes a bug with the original version.

NB(2): A couple of people on Twitter have commented that you should save a reference to your CTFrameSetterRef when calculating height or width and re-use it, because the framesetter will cache those calculations. If you use a new one, you not only have the overhead of a new object, you will also be doing the size calculation twice. I'm planning a future post where I show how to draw attributed strings, and I need to give some thought about how to re-architect the code for that post based on that feedback.

- (CGFloat)boundingWidthForHeight:(CGFloat)inHeight
{
    CTFramesetterRef framesetter = CTFramesetterCreateWithAttributedString( (CFMutableAttributedStringRef) self); 
    CGSize suggestedSize = CTFramesetterSuggestFrameSizeWithConstraints(framesetter, CFRangeMake(0, 0), NULL, CGSizeMake(CGFLOAT_MAX, inHeight), NULL);
    CFRelease(framesetter);
    return suggestedSize.width;   
}
- (CGFloat)boundingHeightForWidth:(CGFloat)inWidth
{
    CTFramesetterRef framesetter = CTFramesetterCreateWithAttributedString( (CFMutableAttributedStringRef) self); 
    CGSize suggestedSize = CTFramesetterSuggestFrameSizeWithConstraints(framesetter, CFRangeMake(0, 0), NULL, CGSizeMake(inWidth, CGFLOAT_MAX), NULL);
    CFRelease(framesetter);
    return suggestedSize.height;
}

I assume it's only a matter of time before Apple gives us the NSAttributedString UIKit Additions category, or some similar higher-level functionality. In the meantime, any time you have to deal with attributed strings, the best bet is to figure out how to do what you need to do in Core Text and/or Core Graphics (Apple's Programming Guides actually show exactly how to do the most common tasks using both of these frameworks), then wrap a generic version of that code into a category method on NSAttributedString or NSMutableAttributableString.

Building for the MAS

2011-03-10T05:54:00.001-08:00

If you have any thought of making the jump from iOS to the Mac App Store, bookmark this post by Craig Hockenberry right now. It's a brilliant and detailed guide to everything you need to do to get your application on the Mac App Store from somebody who's been there.

Design Then Code

2011-03-07T10:41:00.001-08:00

Mike Rundle just put up a really nice beginner's tutorial on program iOS SDK applications from scratch. Although I disagree with him pretty violently about whether you should use Interface Builder (no, really, you should use it), it's otherwise a brilliant introduction; one of the best I've seen on the web for beginners.

The iPad 2 Rant

2011-03-04T14:02:00.001-08:00

MartianCraft has a fair amount of Android work right now. Personally, I try to focus on the iOS work whenever possible, but we're a small company, so nobody gets to play the primadonna. As a result, I spend a good chunk of my time on Android projects and have to stay abreast of both the Android and iOS worlds from both a hardware and a software perspective.

Last week, I found myself grudgingly admitting to myself that the Motorola Xoom is not a bad tablet. It feels incomplete in many ways. It has rough edges, some definite hardware and software CBBs¹, and a general dearth of good, native-resolution apps. But, it had potential and I definitely saw how certain demographics might be attracted to it over the iPad. I saw a tablet that normal people could use with some frustration, but not an insurmountable amount… much like Windows, post Windows-95.

The thing that I haven't seen in any of the Android tablets, however, is a compelling reason to buy them instead of the iPad. The only people I know who've bought Android tablets also own iPads. Other than a strong aversion to Apple's products or Apple as a company, what would compel somebody to pay $800 for a Xoom or Tab rather than going out and getting an iPad? Maybe there's a reason, but I can't see it. While both the Xoom and Tab had some specs that were better than the original iPad, neither offered a comparable experience let alone a better one, and neither could do anything that the iPad can't², despite higher price tags.

Then came yesterday.

Two days ago, the Xoom looked like a decent, almost finished and slightly overpriced tablet. Two days ago, it had a couple of quantifiable advantages, including native CDMA support and a better GPU. Two days ago, you could make the Xoom look better than the iPad on paper. Though marketing based on tech specs hasn't proven to be a very effective strategy in mobile computing space, at least they did have that for them. They had grounds for claiming you should buy the Xoom instead of an iPad. The arguments were thin, but two days ago they existed.

Today, simply put: The Xoom is fucked. So, I suspect, is the unreleased Samsung Tab 10.1 and the RIM Playbook. I can only imagine the discussions that are going on inside those companies today.

Only the staunchest Apple haters and self-deluded "openness" ideologues are going to pony up that kind of dough for a tablet that can't offer a comparable experience and doesn't have better tech specs. The Xoom doesn't even have the advantage of working with a carrier that Apple's tablet doesn't. In seven days, there will be both native CDMA and GSM models of the iPad 2.

Think about this: yesterday when I checked, the Android Marketplace had sixteen Honeycomb tablet-resolution apps. Sixteen. And you know what's not included in that sixteen? That space game that they show the guy playing in the Xoom commercials. In other words, they had to put a fake game in the commercial. Would they have done that if they had even one compelling application that could make the Xoom look better than the iPad?

As a tablet platform, Android has two big challenges.

First, it has a chicken-and-egg problem with software. Developers are waiting for people to buy Android tablets in sufficient quantity to support the platform, and many consumers are waiting for good apps to buy Android. In the phone world, Android seems to be past that hump. While the app situation is nowhere near as good as on iOS yet, there are apps — including some good ones — for the platform.

But, even if the Xoom were every bit as amazing of a piece of hardware as the iPad 2, it would still have the problem that it does less cool things. There's nothing comparable to Garage Band or iMovies, or any of the hundreds of jaw-dropping iPad apps that have been created in the last year like Infinity Blade, The Elements, or Alice. There's just no "wow" app you can put on your Xoom and show people that's going to make them want to run out and buy one. There's nothing you can do and confidently say "your iPad can't do that shit right there, bitch".

The second, and much larger problem is simply one of price. I see people constantly comparing the Android/iOS situation to the Windows/Mac situation of the eighties and nineties. I usually see this claim by people laughably arguing that Apple's failure is imminent.

In the nineties, Apple kept insane profit margins on their products while dozens of manufacturers created inexpensive commodity PCs running Windows. There was a margin war on the PC side, and PCs became noticeably cheaper (despite paying hefty licensing fees to Microsoft), and that price difference, combined with Microsoft closing some of the usability gap with the Mac, is what lead to the dominance of Wintel machines. In the nineties, Macs simply cost more. You could argue that Macs were cheaper based on TOC or employee efficiency, but in the quantifiable terms that bean counters understand, the Mac was a lot more expensive and didn't do noticeably more, especially once Adobe jumped ship and become cross-platform.

That's not where things are now, however. For typical consumers - people who don't have a dog in the technology race, so to speak, are going to buy based largely on price, Apple's mobile "post-PC devices" aren't just better than their competitors, they're cheaper than comparable competitors.

We don't have a situation where commodity resellers can easily assemble components into a working, desirable mobile device. Mobile devices are all about form factor, design, and ease of use. They don't sit on a desk, they go where you go. They need to be well engineered, light, get good battery life, and be easy to use. They can't require IT support staff, an instruction manual, or training. A large beige box on a desk is one thing, but in your pocket it's another thing altogether.

Why is this the case, though? Why can't these companies compete with Apple on price in the tablet space?

The prices Apple can offer is a result of two things. First, is plain and simple buying power. Apple sells a lot of devices, so they buy a lot of screens, flash memory, etc. As a result, they can get quantity discounts. Apple got to the 10 inch form factor first and cornered the market, driving up the price for 10" screen components for any competitors coming after them.

The second, however, is that they have gobs of cash on hand. A lot of market watchers say Apple is foolhardy to keep so much cash on hand. On the contrary! Apple understands psychology, and not just consumer psychology. When they go to a vendor or hardware partner and ask for exclusive arrangements, priority fulfillment, or better prices, do you know what bargaining chip they have that few other companies have?

The corporate equivalent of a suitcase full of cash.

When a vendor needs to retool for a new manufacturing process Apple has developed or needs to increase their output capacity, Apple shows up with a wad of cash in hand. They don't have to liquidate any assets or get a loan or seek permission of shareholders. They just play Daddy Warbucks and pull out a wad of million dollar bills. Apple's partners, in addition to getting large-volume contracts, can get working capital as part of their arrangment with Apple without taking out loans. A definite part of the reason you were able to buy an iPad for only $499 is because Apple didn't follow conventional wisdom about cash on hand.

Arguing that Apple would be doing better by doing what everybody else is doing isn't usually very convincing to me.

Motorola and Samsung… they're both large companies with a lot of buying power and strong brand recognition. The problem is, they don't understand the game that Apple's playing in the mobile space, so they're playing it wrong. They're so caught up in catching up that they're not even trying to innovate in this space. Maybe HP or Rim will figure it out, but I'm not going to hold my breath.

Which is unfortunate. If Apple's doing this kind of amazing stuff without any viable competition, can you imagine what they'd be doing with strong, viable competitors nipping at their heels?

1 "Could Be Betters"
2 From a consumer perspective, not from the perspective of a geek who likes to take things apart and put them back together. The Xoom, with its more powerful processor and GPU had the potential to do things the original iPad couldn't, but didn't ship with any application that proved it. Consumers believe what they see, not what the tech specs say.

QuickBoot

2011-02-24T18:36:00.001-08:00

If you're going to install the 10.7 preview on a separate hard drive or partition, it's definitely worth knowing about Buttered Cat Software's QuickBoot, which allows you to change startup disks and reboot from your menu bar.

Lion in the House

2011-02-24T07:52:00.001-08:00

Today, Apple released a preview version of Mac OS X Lion, but only for registered Mac developers. This is a big release, not just in terms of front-end experience, but also under the hood. A lot of the changes are influenced by UIKit and iOS, hence the moniker "Back to the Mac", but there's also a fair amount of completely new goodness, some of which will likely roll down to iOS at some point.

If you're an iOS developer, but not a Mac developer, it's probably worth $99 to get access to ~~Tiger~~ Lion. It'll give you a better idea of where Apple is taking things.

Plus, there's just a lot of really cool stuff in there.

Interestingly, the OS preview is being delivered via the Mac App Store, which might be a hint at how paid OS upgrades will be handled in the future.

Members of the Mac developer program can log into the Mac Developer site to download Lion, the release notes, and a new version of Xcode 4.

Voices that Matter Seattle

2011-02-23T09:11:00.001-08:00

So far, 2011 has been pretty light for me in terms of speaking. I do, however, have one speaking engagement lined up for this year: I'll be speaking at Voices that Matter in ~~the land of Mordor~~ Seattle on April 9th and 10th. If you're interested in going, early bird pricing ends on February 25.

You can use the speaker code SEASPK2 to get $100 off.

There's a great speaker lineup for this conference, including Andy Ihnatko.

Blender 2.5 beta 6 Objective-C Export

2011-02-22T11:16:00.001-08:00

A kind reader updated my Objective-C export script for Blender to work with the 2.5 beta 6 version of Blender. You can find the new version on GitHub.

On a related note, if you make a change to your clone of any of my public repositories on Github, you can send me a pull request. I'm happy to take additions, bug fixes, and other updates back into the master repository.

Thanks to John Becker for updating the script!

Apple Outsider on the Subscription "Hubbub"

2011-02-22T11:10:00.001-08:00

I have a very short list of "must-read" blogs. While I have a much bigger list of blogs I read as time permits, the list of ones that I check every morning before I buckle down to work consists of only about a half-dozen blogs by people in our industry who really know their stuff. One of those blogs is Apple Outside, written by former Apple Evangelist, Cocoa Guru, and all-around nice guy Matt Drance (not to be confused with the more intimidating BatDrance who is most definitely not Matt's alter-ego).

I've been keeping my head low on the whole subscription kerfuffle that's been happening in the iOS dev world. Partially that's just because I'm busy and don't have time to pen a long blog-rant, but it's also because it's a complex situation on which I don't have a fully-formed opinion yet. Matt's even-handed take on the situation does a great job of articulating the situation and is well worth reading.

A Couple CGAffineTransform Goodies

2011-02-15T17:52:00.001-08:00

Thanks to Core Animation, we iOS programmers tend to use affine transformations (by way of CGAffineTransform) a lot. By being able to combine multiple 2D transformations into a single matrix, we have the ability to do a lot of cool animation effects with only a few lines of code.

Take the following example, which is fairly typical:

    CGAffineTransform transform = CGAffineTransformMakeTranslation(0, -translation);
    transform = CGAffineTransformScale(transform, scaleFactor, scaleFactor);
    view.transform = transform;

Not bad, right? In just three lines of code, we're able to both scale and translate a view or layer. But in reality, there's actually quite a few operations going on behind these three lines of code. The CGAffineTransformScale() function calls CGAffineTransformConcat() to perform a matrix multiplication operation between two affine matrices. But, as you probably know, you can't multiply a 2x3 matrix by another 2x3 matrix. To multiply affine transformations, they have to be converted back to 3x3 vector matrices first.

On today's devices (even mobile devices), this all takes a trivial amount of processing power. But sometimes, when you're doing a lot of these transformations — say thousand or tens of thousands a second — it can be valuable to be able to avoid that conversion and matrix multiplication.

It just so happens that with certain commonly used CGAffineTransforms, you can cheat. Certain matrices can be joined together without performing matrix multiplication. For example, here are the matrices created by CGAffineTransformMakeScale() and CGAffineTransformMakeTranslation(), respectively:

Go ahead and multiply those two together. Plug in any number for tx, ty, sx, and sy and run the numbers. I'll wait. Okay, you don't have to. This is what you'll get:

So, if that's the result we're going to get, why bother going through the matrix multiplication in the first place? Why not just populate the matrix with both the scale and translate values right from the get-go? Well, we can. We can also do the same thing with translate and rotate.

This is all there is to it:

static inline CGAffineTransform CGAffineTransformMakeRotateTranslate(CGFloat angle, CGFloat dx, CGFloat dy)
{
    return CGAffineTransformMake(cosf(angle), sinf(angle), -sinf(angle), cosf(angle), dx, dy);
}
static inline CGAffineTransform CGAffineTransformMakeScaleTranslate(CGFloat sx, CGFloat sy, CGFloat dx, CGFloat dy)
{
    return CGAffineTransformMake(sx, 0.f, 0.f, sy, dx, dy);
}

That's it. It only saves you two lines of code:

    view.transform = CGAffineTransformMakeScaleTranslate(scaleFactor, scaleFactor, 0, -translation);

But, your stack allocation is considerably smaller (one CGAffineTransform instead of two CGAffineTransforms and an intermediate 3x3 array. It also saves you eighteen floating point multiplications and nine floating point additions. 99.9% of the time, that number of operations is going to have no noticeable affect on your application - it's a trivial amount of both memory and FLOPS under most normal situations.

But… if you're doing a lot per second, they can add up and it's nice to know there's a way that you can save yourself a little overhead in some situations.

Xcode 4 Icons

2011-02-13T11:22:00.001-08:00

Well, now that Xcode 4 is GM, it has the same icon as Xcode 3.25. Ordinarily, this wouldn't be an issue, since a GM release means you can throw out the old one and use it full-time.

Only, you may not be able to with all of your projects. Xcode 4 GM has a few issues that make it hard to go full-time with it, including a linker error that can only be worked around by turning some level of code optimization, a change that makes it hard to debug. A few of these problems impact projects I'm working on, so as a result, I have to grudgingly use Xcode 3.25 for some tasks.

Despite a small handful of problems, though, Xcode 4 is where I want to be whenever possible. Having multiple identical icons in your Dock can be a bit of a pain.

Unfortunately, I didn't save the old Xcode 4 installers. If I had, I would have just gone and stolen the old preview icon and continued using that. Since I didn't, I did the same thing I did for beta iOS releases and made a customized version of the app icon for Xcode 4. If you want to use it, you can download it here. To install, you just copy the .icns file into Xcode 4's app bundle, replacing the existing one. And, no, replacing the icon file with a new one doesn't cause problems with Xcode 4 due to code signing, though I feared it might.

This is what it looks like:

MC3D - Platform Agnostic 3D Foundation

2011-02-08T09:42:00.001-08:00

Sorry for the lack of posts recently. Things have been, well… you know. Same old story. Super busy. Which is good, but it's murder on blog post frequency.

I've recently had to port some OpenGL ES work I did from iOS to Android. It used to be that doing so would have been insanely painful (as opposed to just painful). I would have had to convert the Objective-C code to Java, and then maintain completely distinct sets of code that do the same exact thing. Fortunately, the Android NDK (Native Development Kit) allows you to write code for Android in C/C++. The version of the NDK supported on 2.2 still requires part of the Activity (Android's counterpart to an iOS view controller) to be written in Java, but does allow you to call C/C++ code using JNI. In 2.3 and 3.0, you can do entire activities in C or C++.

This is a huge step forward for Android for those of us who do performance-critical work on multiple platforms, but it's not without some pain. Debugging across the JNI bridge is… less than easy. But, being able to share code across platforms is a huge win, and being able to get native speeds in the process is teh awseome.

During these projects, I've been taking a lot of my 3D-related code and creating a new set of platform-agnostic C functions and types. I've been cleaning up and making names consistent, and placing appropriate pre-compiler macros to make sure the code compiles correctly everywhere. On iOS, the library will take advantage of the Accelerate Framework in places, but doesn't require Accelerate to function.

I've chosen C because I don't like mixing C++ and Objective-C. The object models are too different for my tastes. But I've also made sure to include proper ifdef'd extern statements so that you can import the MC3D header files from C++ without hassle.

I've dubbed this set of functions MC3D, and I'm making it open source under a simplified version of the simplified BSD license (simplified simplified BSD license?). I've taken out the attribution requirement, so the only requirement is that if you re-distribute the source code, you have to leave the copyright and license text intact. That's it. Otherwise, you can use it for free in any project, commercial or otherwise, without paying anything, without attributing, and without asking (no really, you don't need to ask).

MC3D is still very much a work in progress, and I'm only adding code to the repository that I feel is ready for public consumption. Much of what's in MC3D has been posted here before, sometimes with different names or in slightly different form.

I have other code that I plan to add in the future, including higher-level functionality like model loading, scene management, and skeletal animation, but I won't add anything until its both solid and platform agnostic.

Currently, documentation is very sparse, and I currently can't offer any support or help with using it, so caveat emptor! I will gladly accept contributions, bug fixes, and new functionality back into the MC3D codeline.

MC3D on GitHub.

Link fixed, sorry about that

Complete Friday Q&A

2011-01-27T17:14:00.001-08:00

Mike Ash just announced the availability of his Complete Friday Q&A book. Mike's weekly blog posting is a must read for any Cocoa developer. Mike's knowledge of the language and system internals is amazing, and having all his weekly posts available in one place formatted like a book is a great resource. Go check it out on iTunes or Amazon.

Garage Games

2011-01-27T08:40:00.001-08:00

I noticed that Garage Games, the makers of the Torque game engine have recently had a near-death experience. As of the end of last year, it looked like they were shutting down operations. However, they appear to be in the midst of a phoenix-like return to life with, perhaps, some changes in focus and priority. The bad news for iOS folks, is that they've removed the mobile version of their 3D engine from their product list. I don't know if this means it's abandoned, or that they're just not ready to announce/release it. They are actively hiring developers and designers, and from the job descriptions they've posted, it sounds to me like they've got their sights set firmly on mobile.

To celebrate their revival, they're having a sale on all their products - you can get any of their engines, including a full source license for $99.

Now, I honestly don't know how Torque compares to, say, Unity, Sio2, or the UDK in terms of features or ease of development, but there have been a lot of very solid games created with Torque over the years and the demos show the engine is versatile and fairly powerful.

What I do know that $99 is a hell of a price for a source license to a game engine of this size and complexity. For me, it's worth that much money to get to peek around their code. There's a lot to be learned from looking at other people's code.

No word on how long the sale is for, but you can check it out here.

Note: I had an e-mail conversation with Garage Games' community manager about iTorque 3D. Unfortunately, right now the official word is that the product is off their roadmap. They have no announced plans to release it, so if you're targeting the iPhone or mobile devices in general, you're out of luck for now and should probably look at another engine.

That being said, they didn't rule out the possibility of re-introducing iTorque 3D at some future point. Frankly, if you're interested in writing games, I still think it's well worth dropping $99 for a license to be able to see the choices they've made in designing their engine as well as how they've implemented them. It's a pretty good example of a complex cross-platform project.

I have to say, I like the new public face of Garage Games. Their responses to my questions were prompt and candid. I think the new management knows exactly what they want to do and I'm looking forward to seeing where they take things.

On Seven Inches

2010-12-31T06:55:00.001-08:00

Tim Bray has a year-end blog post up that's worth a read. In case you don't know, Tim Bray is Google's Android Evangelist. As you might expect from someone who would take that job, he's as enthusiastic about the Android platform as I am about iOS. Although his perspective colors his view (as does mine), his analysis is usually pretty good.

He's got one assertion in this most recent post, however, that doesn't seem to ring true to my ear.

Apple will totally do a 7" device. Anyone who’s spent quality time reading books or playing games on the Galaxy Tab knows; there’s a great big hole in the ecosystem that needs something bigger than a handset but that still fits in one hand and you can use for four hours in a row sitting up. This argument is over.

John Gruber seems similarly skeptical, opining yesterday that:

The problem is that it’s nice, for certain tasks, to be able to hold a tablet in one hand, but you can’t do that with the current iPad. I think Bray’s mistake is assuming that using a 7-inch display is the only way to solve that problem.

The argument is far from over, and it's silly to even make the assertion. I have, within arm's reach, the very 7" tablet Tim refers to - a Samsung Galaxy Tab. I have spent quality time with the Tab, and think I definitely count as part of the set known as "anyone", yet I don't see this glaring hole that Tim thinks is so obvious. Personally, I found the Tab awkward for text reading, though part of that is due to Android's abysmal text rendering engine. The only way the Tab is better than the iPad for reading is that it's lighter and more portable. As for games, I'll admit that the Tab's form factor is pretty much ideal for driving games. All other types of games I've tried, it's either no better or worse than the iPad and, of course, there's no comparison in the selection of available games yet.

The Tab is a 16:9 tablet running Android 2.2. For watching 16:9 video content like movies and HD television shows, the end result is that you get roughly the same size image video as you do on the iPad in a package that's lighter and easier to hold, which sounds like a winner, right? There are downsides, however. The smaller form factor means less room for batteries and thus shorter battery life. The energy requirements for a 7" tablet are not considerably less than those of a 10" device, but there's a lot less room for batteries. As a result, while battery life is almost never an issue on my iPad, it's often one on the Tab. If you've seen the inside of an iPad, you know that most of the heft of the iPad comes from batteries. Apple made the design decision that they'd rather have a slightly heavier device that could run all day long on a single charge with normal usage. Based on sales and reviews, I think it's safe to say that was a good decision.

Batteries are getting more efficient every year, as are processors, so at some point, a 7" device with iPad-like battery life is completely feasible, however when that happens, a 10" device will have even better battery life. But battery life is far from the only downside to this form factor.

With the exception of video, some types of games (e.g. car driving games), and likely a handful of other tasks, the smaller form factor is simply not as good as the iPad for most things you'd want to do. It sits in an uncomfortable middle ground between phone-size devices and 10" tablets like the iPad and the… well, like the iPad. The Tab does nothing considerably better than either an iPhone or an iPad. It's "as good" at a handful of tasks.

What it boils down to is that the main advantage of the 7" form factor is that it's easier to carry around with you and is lighter to hold. I'm just unconvinced that's enough of a reason to make a 7" iPad inevitable.

Personally, If I were going to buy something to fit between my iPhone 4 and my iPad, I'd buy a Kindle, and recent sales numbers seem to indicate that many people are making that choice. The Kindle does less than the Tab, but it's even lighter and it does do something better than the iPad, iPhone, and Tab: it's a better ebook reader. It gets great battery life, it's easy on your eyes, has nice text, it's easy to carry, can be held comfortably in one hand, and it's much, much cheaper.

When Apple introduced the iPad, it looked like it was going to compete, and probably kill, the burgeoning ebook reader market. Instead, it pushed those special-purpose devices into a lower price bracket where they no longer compete directly with the iPad. Looking at how the sales numbers have jumped recently, the iPad may just be the best thing that ever happened to the Kindle. The Kindle and Nook are almost down into the "impulse buy" category, and as a result, they're selling like hotcakes, often to people who already own iPads.

But where does a seven inch tablet fit into the market? What would compel someone who owns an iPad to buy one, or would compel someone to buy one instead of an iPad? There isn't really a huge unmet demand for this product to fill. There's no pressing, burning need that would cause people to buy yet another device. A seven inch tablet has to compete with products that are already on the market and that are well-established. It can't compete with the Kindle on price, size, weight, or as an ebook reader. It's not noticeably cheaper than the iPad, yet has shorter batter life. It doesn't do anything that the iPad or iPhone can't. It's only compelling advantages are that it's lighter and smaller. Well, for a small segment of the market, it has another advantage: it's not from Apple.

The Galaxy Tab has been selling pretty well, but it's got novelty working for it, and it's really the only viable non-Apple tablet on the market right now. That will not be the case for long, however. The way the iPad has sold, you can expect every computer hardware manufacturer to try to claim a piece of the tablet market. Microsoft has already announced that, for them, CES would be about "slates" yet again this year (oh, boy!).

For seven inch tablets to gain traction in the long run, they will have to provide a compelling advantage over the iPad, the iPhone, and the Kindle. If they're not going to compete on price, maybe there's some feature or ability where seven inch tablets can distinguish themselves and establish a long-term foothold, but I haven't thought of it yet, and apparently neither have the current tablet manufacturers like Samsung.

The only way Apple will release a 7" tablet is if they think of some compelling reason for such a product to exist. It's possible that the reason would be price - making a more affordable and smaller iPad available to people who can't afford a $500+ device but want something bigger than an iPod touch. That's not impossible given Apple's drive for competitive pricing in their consumer products the last few years, but it's far from a foregone conclusion.

More Animation Curves than You Can Shake a Stick at

2010-12-22T11:07:00.001-08:00

Core Animation is awesome. It makes doing a lot of complex, fancy animations downright easy. One of the really nice built-in features of Core Animation is the ability to use animation curves. These curves let you specify whether the animation happens linearly (at the same pace throughout the animation), or whether the animation eases in, eases out, or does both.

When you have to go closer to the metal and use OpenGL ES, you're not so lucky. We don't have animation curves provided for us in OpenGL ES. We have to interpolate ourselves. Fortunately, the math behind animation curves is straightforward. Plus, there are far more curves than just the four Apple offers.

I haven't run across a good library for generating animation curves, so I've decided to release my animation curve functions as public domain (no attribute required, no rights reserved). Here is a graph of all the different animation curves I'm releasing:

Here is the original Numbers.app document that generated the graph, and here is the Xcode project that generated the data. The project also contains all the functions needed to plot these curves.

Apple doesn't document which calculations they use for easing, but my guess is that they're quadratic. I'm not sure, though, since many of the curves yield similar results.

All of the interpolation functions included in the Xcode project above take three inputs and return a GLfloat containing the interpolated value. The first parameter, t, is the percent of the way through the animation you want a value calculated for. This is a clamped float that should be in the range 0.0 to 1.0. Values above 1.0 will be treated as 1.0 and values below 0.0 are treated as 0.0. The second parameter, start, is the value when the animation starts. The third parameter, end, is the final value to be animated toward.

If you want to apply a curve to a CGPoint or Vector3D, you have to call the function multiple times for each component (x/y or x/y/z).

Have fun!

Here are the functions included in the project above:

#include <OpenGLES/ES2/gl.h>
#include <OpenGLES/ES2/glext.h>
#include <math.h>

#define BoundsCheck(t, start, end) \
if (t <= 0.f) return start;        \
else if (t >= 1.f) return end;

GLfloat LinearInterpolation(GLclampf t, GLfloat start, GLfloat end)
{
    BoundsCheck(t, start, end);
    return t * end + (1.f - t) * start;
}
#pragma mark -
#pragma mark Quadratic
GLfloat QuadraticEaseOut(GLclampf t, GLfloat start, GLfloat end)
{
    BoundsCheck(t, start, end);
    return   -end * t * (t - 2.f) -1.f;
}
GLfloat QuadraticEaseIn(GLclampf t, GLfloat start, GLfloat end)
{
    BoundsCheck(t, start, end);
    return end * t * t + start - 1.f;
}
GLfloat QuadraticEaseInOut(GLclampf t, GLfloat start, GLfloat end)
{
    BoundsCheck(t, start, end);
    t *= 2.f;
    if (t < 1.f) return end/2.f * t * t + start - 1.f;
    t--;
    return -end/2.f * (t*(t-2) - 1) + start - 1.f;
}
#pragma mark -
#pragma mark Cubic
GLfloat CubicEaseOut(GLclampf t, GLfloat start, GLfloat end)
{
    BoundsCheck(t, start, end);
    t--;
    return end*(t * t * t + 1.f) + start - 1.f;
}
GLfloat CubicEaseIn(GLclampf t, GLfloat start, GLfloat end)
{
    BoundsCheck(t, start, end);
    return end * t * t * t+ start - 1.f;
}
GLfloat CubicEaseInOut(GLclampf t, GLfloat start, GLfloat end)
{
    BoundsCheck(t, start, end);
    t *= 2.;
    if (t < 1.) return end/2 * t * t * t + start - 1.f;
    t -= 2;
    return end/2*(t * t * t + 2) + start - 1.f;
}
#pragma mark -
#pragma mark Quintic
GLfloat QuarticEaseOut(GLclampf t, GLfloat start, GLfloat end)
{
    BoundsCheck(t, start, end);
    t--;
    return -end * (t * t * t * t - 1) + start - 1.f;
}
GLfloat QuarticEaseIn(GLclampf t, GLfloat start, GLfloat end)
{
    BoundsCheck(t, start, end);
    return end * t * t * t * t + start;
}
GLfloat QuarticEaseInOut(GLclampf t, GLfloat start, GLfloat end)
{
    BoundsCheck(t, start, end);
    t *= 2.f;
    if (t < 1.f) 
        return end/2.f * t * t * t * t + start - 1.f;
    t -= 2.f;
    return -end/2.f * (t * t * t * t - 2.f) + start - 1.f;
}
#pragma mark -
#pragma mark Quintic
GLfloat QuinticEaseOut(GLclampf t, GLfloat start, GLfloat end)
{
    BoundsCheck(t, start, end);
    t--;
    return end * (t * t * t * t * t + 1) + start - 1.f;
}
GLfloat QuinticEaseIn(GLclampf t, GLfloat start, GLfloat end)
{
    BoundsCheck(t, start, end);
    return end * t * t * t * t * t + start - 1.f;
}
GLfloat QuinticEaseInOut(GLclampf t, GLfloat start, GLfloat end)
{
    BoundsCheck(t, start, end);
    t *= 2.f;
    if (t < 1.f) 
        return end/2 * t * t * t * t * t + start - 1.f;
    t -= 2;
    return end/2 * ( t * t * t * t * t + 2) + start - 1.f;
}
#pragma mark -
#pragma mark Sinusoidal
GLfloat SinusoidalEaseOut(GLclampf t, GLfloat start, GLfloat end)
{
    BoundsCheck(t, start, end);
    return end * sinf(t * (M_PI/2)) + start - 1.f;
}
GLfloat SinusoidalEaseIn(GLclampf t, GLfloat start, GLfloat end)
{
    BoundsCheck(t, start, end);
    return -end * cosf(t * (M_PI/2)) + end + start - 1.f;
}
GLfloat SinusoidalEaseInOut(GLclampf t, GLfloat start, GLfloat end)
{
    BoundsCheck(t, start, end);
    return -end/2.f * (cosf(M_PI*t) - 1.f) + start - 1.f;
}
#pragma mark -
#pragma mark Exponential
GLfloat ExponentialEaseOut(GLclampf t, GLfloat start, GLfloat end)
{
    BoundsCheck(t, start, end);
    return end * (-powf(2.f, -10.f * t) + 1.f ) + start - 1.f;
}
GLfloat ExponentialEaseIn(GLclampf t, GLfloat start, GLfloat end)
{
    BoundsCheck(t, start, end);
    return end * powf(2.f, 10.f * (t - 1.f) ) + start - 1.f;
}
GLfloat ExponentialEaseInOut(GLclampf t, GLfloat start, GLfloat end)
{
    BoundsCheck(t, start, end);
    t *= 2.f;
    if (t < 1.f) 
        return end/2.f * powf(2.f, 10.f * (t - 1.f) ) + start - 1.f;
    t--;
    return end/2.f * ( -powf(2.f, -10.f * t) + 2.f ) + start - 1.f;
}
#pragma mark -
#pragma mark Circular
GLfloat CircularEaseOut(GLclampf t, GLfloat start, GLfloat end)
{
    BoundsCheck(t, start, end);
    t--;
    return end * sqrtf(1.f - t * t) + start - 1.f;
}
GLfloat CircularEaseIn(GLclampf t, GLfloat start, GLfloat end)
{
    BoundsCheck(t, start, end);
    return -end * (sqrtf(1.f - t * t) - 1.f) + start - 1.f;
}
GLfloat CircularEaseInOut(GLclampf t, GLfloat start, GLfloat end)
{
    BoundsCheck(t, start, end);
    t *= 2.f;
    if (t < 1.f) 
        return -end/2.f * (sqrtf(1.f - t * t) - 1.f) + start - 1.f;
    t -= 2.f;
    return end/2.f * (sqrtf(1.f - t * t) + 1.f) + start - 1.f;
}

The Little Grashopper Blog

2010-12-21T13:55:00.001-08:00

Well, I'm not sure how I never ran across it before, but Philip Rideout, author of O'Reilly's iPhone 3D (a book I recommended last week), has a hell of a blog for people interested in OpenGL. A lot of the posts are specific to desktop OpenGL (and recent versions of OpenGL at that!), but there's tons of great information that applies to OpenGL ES as well. It's a veritable treasure trove of advanced graphics goodness from a guy who's been doing it for years.

More Math Resources

2010-12-21T13:37:00.001-08:00

After posting about the free Linear Algebra book, I was told about another resource for learning math via Twitter. The Khan Academy is a not-for-profit website providing online video courses on a number of topics. They don't just cover math, but they do cover math extensively. They have well over 100 video lessons on linear algebra alone. Definitely a great resource I'm happy to pass along!

Non-Deterministic Problems aka Finding Talent

2010-12-21T10:21:00.001-08:00

As programmers, we usually deal with deterministic systems. To state it simplistically, deterministic systems are systems where the same inputs always results in the same output. Unless we intentionally introduce randomness¹ or have a relatively rare kind of bug in our code, the same inputs to our programs will always yield the same output. It could very well be the wrong result if our algorithm is bad, but it should be the same wrong result every time, which is a trait we rely on heavily.

In the real world, most things we encounter are non-deterministic. There are always factors we can't control or measure, and most systems have a human element. We are at the mercy of whim and emotion, and that's hard for a lot of programmers to deal with. Our fellow humans's decisions are decidedly non-deterministic and hard to predict, as are ours (though we usually don't notice this trait quite as much in ourselves).

You may have noticed that I haven't had much time to write lately. I've been exceedingly busy of late, even by my own standards. Although a lot of my time is being spent writing and debugging software, I've also been involved with some very non-deterministic problems as a result of my involvement with some large, complex development projects.

Probably the biggest non-programming problem that I've had to deal with lately, which most of my industry peers and nearly all of our clients are dealing with also, is finding good, experienced, reliable developers to staff projects. In short, there aren't enough experienced mobile software developers to go around. There simply aren't as many developers with multiple successful projects under their belt as there are companies who need the services of such people. I know of one large company that currently has ten open requisitions for mobile developers - five iOS and five Android - and no viable prospects at the moment. I helped one client recently bring aboard a good iOS developer, which took several months, and then I very quickly regretted it, because MartianCraft could really use that developer's services now.

Yet, on the other hand, whenever I blog about just how much work there is right now, I inevitably get several e-mails or comments from developers wanting to know how to find all this work. I make it sound like it's raining work, and they're not getting wet.

Given that, I thought it worth a few minutes to write about both sides of the equation: how to find developers, and how to find work as a developer. This isn't an exhaustive treatment, just a summary of recent observations.

For Developers: Finding Work

Unfortunately, I've got no silver bullet for aspiring developers. Overnight success is often indistinguishable from years of hard work. There are countless issues around getting that are not mobile development-specific that I'm not going to touch, such as a willingness to relocate ("go where the work is").

As with any industry, a large part of finding work is establishing a reputation and getting to know as many people in the industry as you can. Though it's expensive, you really need to go to WWDC, and probably a couple other conferences as well. About half, maybe even more, of MartianCraft work has come directly or indirectly as a result of one of us attending a conference. Conferences are where we meet our peers and where we develop and maintain our relationships with them. You should also attend CocoaHeads and/or NSCoder Night if you have one near you. This is where you can meet and get to know local iOS and Mac developers. On the Android side, there are similar meet-ups that you can attend.

When going to hire or subcontract a developer, most people I know will automatically prefer someone they've met, talked with, and maybe shared a drink with over a stranger, no matter how good the stranger's resume looks. Confidence in someone's ability to get a job done comes more rapidly from personal interaction. Resumes are sterile, but sitting down and working through a tough bug with somebody gives you a real feel for the other person's character and technical chops in a way you can never get from a resume.

At conferences, don't worry about going to every session. Everybody tries to at their first DubDub, but don't. Really. Pace yourself so you can socialize in the evenings. That may sound like bad, or even frivolous advice - as if I'm telling you to play hooky, but the information in the sessions can be found again. Most conferences videotape their sessions, and usually some of the attendees do joint note-taking using SubEthaEdit and make those notes available. But socializing with industry peers is vital if you want to do this full time, especially as an Indie. These are the people who can give you work (and accept work when you're too busy to take on new work yourself), and they are the people who can help you when you're stuck on a gnarly technical problem. These are the people who can give you a different perspective on something you've been staring at for far too long and are the people who can help you become a smarter, better developer.

Though not perfect, the iOS and Mac developer community is incredibly giving and helpful. It's not uncommon for direct competitors to help each other out and consider each other friends. Most of us realize that it's not a zero-sum game, and helping out others in our community usually comes back with interest. Scratch that. Not usually. Always.

Getting ongoing work requires more than being liked by other developers, however. You have to give people a reason to have confidence in your abilities. Creating or contributing to open source projects can show huge (if not immediate) returns. In the early days of iOS, before Core Data was available, my SQLitePersistentObjects project brought me nearly as much recognition as having my name on the cover of iPhone programming books.

Regular blogging is also a huge opportunity. Not only does it give people an idea of the depth of your knowledge, it gives you a chance to learn and improve. I don't think I've posted more than a couple technical blog posts where there wasn't either a correction or improvement sent to me by a reader, and often there were many. Just remember not to get defensive or depressed when it happens. You don't stop making mistakes until you stop living, but if you keep learning, you can avoid making the same mistake too many times. Readers who care enough to point out your mistakes are valuable beyond belief. Tame your ego and cherish them. Nobody's going to think less of you as a developer for occasional mistakes or less-than-perfect code.

But, no matter how much of the above you do, there is one absolute prerequisite to getting work on an ongoing basis: you have to have the technical chops. This is probably the hardest thing to figure out. I've met many great developers who lacked confidence in their abilities and I've met some who've had far too much confidence in them. It's really hard to gauge your own ability and it's almost always sobering to revisit older code you've written. No matter how good you get, there's always room to get better and if you're doing it right, you will. As developers, we're paid as much for our ability to quickly assimilate new knowledge as we are for the things we already know.

Don't worry too much about your whether you have a specific degree, or a college degree at all. You don't have to have a computer science or computer engineering degree to be a good programmer. There are many, many great programmers (including inside Apple) without those degrees and, in fact, without degrees at all. College is one way to get the information and some of the experience you need to be a good programmer, but it's not the only way, and it's possible (though probably not common) to get through school with a CS or CE degree and completely suck. Some of the worst iOS programmers I've encountered have both degrees and programming experience. Objective-C is a bit of a weird beast, and overconfidence is a big problem for experienced developers coming from C++, Java, and C# background. They look at Objective-C, see familiar aspects, and think they know what they're doing, sometimes completely oblivious to the differences between a static, strongly-typed language and a dynamic, weakly-typed one or the differences between a garbage-collected language and a reference-counted one.

In a perfect world, nobody would ever be able to offer their services as an iOS developer without perfectly understanding the rules around memory management. I'm not suggesting you should, but everything else, you could learn on the job, but you have to really grok the way retain counting and memory management work to be a professional iOS developer. You can really fuck up a code base trying to fix EXC_BAD_ACCESS bugs if you don't know what you're doing and can create an awful lot of work for somebody else in the process. You can also get away with an awful lot of leaks if you're developing on the simulator that will cause significant problems later. The stakes get much higher when you're working on the same code at the same time other developers are.

One thing to seriously consider, even if you have a few apps under your belt, is to take a class or workshop. There are some excellent ones out there, including (but certainly not limited to) the Big Nerd Ranch and the Pragmatic Studio. A few thousand dollars may seem like a lot of money, but it's a hell of an investment given the work opportunities available right now. A good workshop will beat into your head the important stuff. They'll strap a firehose of information onto your face and open the spout. They will make your brain hurt, but you will come out knowing memory management and the fundamentals, and that will put you in the running.

Another key skill is debugging. Being able to fix your bugs and those you find in other people's code is vital. Plus, the more bugs you encounter, the more things you know not to do in the future. Want to test yourself? Try downloading this. It's an Xcode project — a modified version of one of the Beginning iPhone 3 Development projects — that has a number of common bugs introduced into it. You should be able to get this to compile clean (no errors or warnings), then be able to navigate into every view in the application without it crashing and with something being displayed on every view. Once you've done that, you should then be able to fix any leaks in the app using Instruments. How long it takes is going to depend on a lot of factors, but I'd say that a typical, experienced, professional iOS developer should be able to fix this in between a half hour and an hour and a half. Regardless of how long it takes, if you can fix them all without help, you've gone a long way down the path to becoming a great developer.

Don't worry if you can't find them all that quickly. The first time you encounter a particular class of bug, it takes more time. Persistence is as important as speed, and debugging this project is a good exercise. Once you see a type of bug once, it's much easier to find and fix it when you encounter it again.

If I find time over the holiday, I might do a screencast showing how to find and fix all the bugs in the project. I can't promise I'll find the time to do that given my current workload, but if I can, I will.

Lastly, if you're looking for full-time iOS or Android employment, or for contract development work, send me your resume. MartianCraft isn't hiring full-time employees at the moment, but we do often need subs, and I know of many, many open requisitions for full-time jobs and I'm always happy to pass resumes along to hiring managers.

For Companies: Finding Mobile Developers

The other side of the equation is, how do you staff a mobile development project right now? Many experienced mobile developers were attracted to the space because it offered them the ability to make a living creating what they want to create. Mobile, and especially iOS development offer opportunities for small teams without a lot of funding to make a decent living. Many of those indie developers are doing exactly what they want to be doing and it's going to be hard, if not impossible, to attract them away from that life, if they're good at what they do.

Hell, many contract developers have app ideas they'd love to be working on themselves. A friend of mine who owns a development shop stated the problem fairly succinctly recently by saying: "We've got several app ideas we'd like to build, but clients keep throwing money at us."

I don't know exactly how many contract iOS developers there are with Objective-C experience that pre-dates the release of the iPhone SDK and/or who have several successful projects under their belt, but it's less than are needed. Big businesses are finally catching on to the importance of mobile and that's making a shallow talent pool even shallower. The situation for Android is similar. Though there are more people who already know the underlying language (Java), the platform has only relatively recently hit critical mass, so there aren't a lot of people who have been involved with successful Android software projects yet compared to the work available, and even less who have successfully shipped multiple Android projects.

In all reality, you're either going to need to offer crazy rates to lure the cream of the crop to your project (and that is no guarantee you're going to get the cream) or you're going to need to invest time and money into developing internal talent. I would advise at least having one really good, experienced tech lead on any decent size project, though. As many App Store success stories can attest, it is absolutely possible to ship good software using only inexperienced developers. But, doing so increases your risk substantially. Having at least one mentor who can guide and help and solve the really icky problems is gold.

In most places, you can train developers more cheaply and more quickly than you can find existing ones, at least if you're looking for full-time employees. It's not a perfect plan - your newly trained people will be learning on the job and making mistakes and may, at times, hit problems that are beyond their ken. But, with the proper training and support, they can handle the bulk of the work, and over time, will gain the experience to handle anything. Of course, you'll have to take steps to keep them from leaving. Arming an employee with a highly marketable skill always incurs a risk of losing that employee.

You can deal with that using contract terms requiring payback of training expenses or other similar ideas, but it's far more effective (albeit harder) to create an environment where people want to work. Job satisfaction is a bigger motivator for many developers than the size of their paycheck, assuming they're making enough to be comfortable and to feel valued. We're one of the few growth industries in this economy, and there's always another paycheck somewhere if you have these skills, so if you're create a hostile environment, no amount of money is going to keep the good people around long term.

There's another option you might be considering: offshoring. Go ahead. I mean, anything I say against the practice is going to seem biased given what I do for a living, and it's true that you can get considerably lower rates by doing it. I've seen shops in other countries offering iOS development services for about what you can make working at Burger King here in the states. And there are actually success stories from offshoring to cheap development body shops. Unfortunately, there are even more horror stories. In the few cases where I've been brought in to fix² projects of this nature, it's always been a waste of time and we ended up just throwing out the old code and starting over. Let me tell you, "start over" is a suggestion that strikes fear into the hearts of project managers.

To put it as fairly as possible: Offshoring increases risk. If you're comfortable with more risk, then it might be a good choice for you. There's a chance you'll come in way under budget and be a hero. Just recognize that there's a larger chance you'll end up six months down the line starting over completely. Any way you cut it, you're likely to have language barriers, cultural differences, and a hard time enforcing accountability. The simple fact of the matter is, even in countries with considerably lower cost of living, opportunities for good mobile developers are legion, so the only way those shops can maintain those excessively low rates is with a constant stream of new, inexperienced bodies. Call me crazy, but it seems to me, that if you're going to have inexperienced bodies working on your project, you'd be better off with ones closer to home that you can train and guide and have some idea of what they're doing.

I'll be blunt. If you're looking to build a team of iOS or Android developers in-house, you've got a tough road ahead of you at the moment. At some point, we'll hit equilibrium and it will get easier, but right now, it's hard. Just as I suggested to aspiring developers, I'd encourage you to get involved with the community. Send somebody, preferably somebody with some authority to hire developers and whose day-to-day job is working with the technology, to conferences, CocoaHeads meetings, and NSCoder Nights, or the Android equivalents (Meetup.com is a good place to find both iOS and Android groups in your area).

I'm always happy to hear from companies that need iOS or Android development resources. I'm thrilled to refer potential employees your way if you're looking for in-house talent, and MartianCraft is always open to talking with with you about your development needs, whether it's for a little strategic consulting and guidance, or to fully staff a development project. And if MartianCraft isn't a good fit for your situation or doesn't have the resources available to do a great job, there's a pretty good chance we know somebody who is and does. If we do, we'll connect you with them.

1 Technically speaking, without external input of some sort, computers are not capable of true randomness, and using a pseudorandom function doesn't make a computer non-deterministic. Pseudorandomness does make the computer pretend to be non-deterministic, though, and you will appear to get different output from the same input on successive runs of the program.
2 The term that we professionals in the industry use to refer to this process is "unfucking". Surprisingly, most dictionaries have not picked up this term yet.

Free Course in Linear Algebra

2010-12-20T19:14:00.001-08:00

Computer graphics programming uses linear algebra so heavily, you could basically say it's based on it. Yet, many people — perhaps most — who develop an interest in graphics programming don't have a background in Linear Algebra. At most universities, it is taught as an upper-level (300 or 400) mathematics course, which means that the majority of students who aren't majoring or minoring in math or certain hard sciences, typically don't take them. Even if you have studied it, if you've gone a period of time without using it, you very likely have forgotten it.

Yet, if you want to go beyond a certain level in graphics programming, you need to understand it.

Today, I stumbled across a free course in Linear Algebra, and it looks to be quite good. It's dense but, hey, this is higher math we're talking about here, so there's not much that can be done to simplify it without making it incorrect. But the price is right, the content is good, and what's even better is that the course doesn't assume much in the way of specific prior knowledge.

Make no bones about it, this is hard stuff to learn, but if you've got a reason to learn it (like a drive to create computer graphics), it helps a lot. Linear algebra in the classroom taught in an abstract manner bored me to tears. Having a real reason and being able to do things with it makes it much more rewarding and fun.

OpenGL ES Book Recommendation

2010-12-12T14:28:00.001-08:00

Since canceling my OpenGL ES 2.0 for iOS 4 book, I've had several people request book recommendations to use instead of my book. Honestly, I didn't really have one to give before today, partially because I intentionally avoided reading competing books while working on mine.

Today, while stuck on a train, I checked out Philip Rideout's iPhone 3D Programming by O'Reilly. Now, it's never easy to give an objective opinion on a book that competes with one you're writing, and even though my book is currently not on a production schedule and I have no time to work on it, I tend to still think of myself as working on an OpenGL ES book. Although there are several things that I would have done differently, I also know it's unfair to judge a book that way. Deciding what to include and what not to include in a book is a horribly difficult thing with an expansive topic like OpenGL ES and no two authors are going to make the same exact decision in that regard, so I'm not going to criticize Philip Rideout for, well, for not being me. Hell, normally not being me is taken as a bit of a compliment anyway.

Yet, though it's not the book I would have written, I can wholeheartedly recommend it. The information is solid and useful and it's presented in a way that doesn't assume or require a Ph.D in math. One thing that Rideout does do that I opted not to even attempt, is to give both the OpenGL ES 1.1 and OpenGL ES 2.0 approach to tasks that can be done in both environments, which is actually interesting on multiple grounds. One, it's a great transition for people who know 1.1 but not 2.0, but also, it shows the interesting ways people have figured out to work around the limitations of the fixed pipeline. These kinds of solutions fascinate me because they're the result of people refusing to accept technical limitations.

Much (all?) of the material from this book is available free online, but I'd recommend buying the book, which gives you access to the book's source code and also will also help an angel get his wings. Well, I'm not 100% sure on the latter, but it seems likely this time of year.

If you're floundering a bit with OpenGL ES, this book is well worth your time.

Drawing Part of a UIImage

2010-11-29T14:16:00.001-08:00

Happy Thanksgiving, and sorry for the relative lack of posts here lately. Things are crazier than ever and it's been a challenge finding time to shower, let alone blog.

I do have something to share, today, though. No, it's not the next chapter of OpenGL ES 2.0 for iOS. It's a category that some of you may find useful: a method that allows you to draw only part of a UIImage rather than the entire thing.

On the Mac, NSImage has a handy instance method called drawInRect:fromRect:operation:fraction: that lets you specify exactly which part of an image to draw. On UIImage, we've only got the ability to draw the entire image either unless we drop down to Core Graphics calls. We don't have a nice, easy, convenient way using just UIImage to draw a portion of the image it represents.

I needed this ability in an application I'm working on, so I hacked out the following category. At first glance, this may look to be inefficient, since we're making a copy of the instance's backing CGImage in order to create the sub-image, however I believe that CGImageCreateWithImageInRect() references the original image's bitmap data. I haven't confirmed that it doesn't make a copy of the bitmap data, but the documentation certainly seems to imply it. Anyone know?

Anyway, here is the category; I've even commented the code more pedantically than is normal for me in case anyone might be confused about what's going on. Improvements and bug fixes are, as always, welcome.

@implementation UIImage(MCDrawSubImage)
- (void)drawInRect:(CGRect)drawRect fromRect:(CGRect)fromRect blendMode:(CGBlendMode)blendMode alpha:(CGFloat)alpha
{
    CGImageRef drawImage = CGImageCreateWithImageInRect(self.CGImage, fromRect); 
    if (drawImage != NULL)
    {
        CGContextRef context = UIGraphicsGetCurrentContext();
        
        // Push current graphics state so we can restore later
        CGContextSaveGState(context);   
        
        // Set the alpha and blend based on passed in settings
        CGContextSetBlendMode(context, blendMode);
        CGContextSetAlpha(context, alpha);
        
        // Take care of Y-axis inversion problem by translating the context on the y axis
        CGContextTranslateCTM(context, 0, drawRect.origin.y + fromRect.size.height);  
        
        // Scaling -1.0 on y-axis to flip
        CGContextScaleCTM(context, 1.0, -1.0);
        
        // Then accommodate the translate by adjusting the draw rect
        drawRect.origin.y = 0.0f;
        
        // Draw the image
        CGContextDrawImage(context, drawRect, drawImage);
        
        // Clean up memory and restore previous state
        CGImageRelease(drawImage);
        
        // Restore previous graphics state to what it was before we tweaked it
        CGContextRestoreGState(context); 
    }
}
@end

OpenGL ES Course on iTunes University

2010-11-19T08:53:00.001-08:00

Those of you waiting for the next chapter of OpenGL ES 2.0 for iOS can do yourselves a favor by checking out this course on iTunes University. It's an Advanced iOS Development course taught by Brad Larsson at the Madison Area Technical College, and the most recent lesson is on OpenGL ES. You can also find the course notes here.

OpenGL ES Update

2010-11-17T12:18:00.001-08:00

Sorry for the silence around here lately.

Unfortunately, the next chapter of OpenGL ES 2.0 I plan to release contains detailed, step-by-step instructions based on Xcode 4 (mostly written around the time of DP2) which is still under NDA. As a result, this chapter is going to take a little longer to scrub, and I haven't had much time to scrub lately.

In the meantime, I realized that I've never linked to the PowerVR Insider SDK, so I'm rectifying that. The company that makes the GPU in all iOS devices has an SDK you can download - in fact, they have several versions of it for different platforms, including iOS. Most of the code is fairly generic C++ with just enough Objective-C around them to work, but there's a metric buttload of good code there for doing all sorts of things. Definitely worth signing and downloading, because they show you how to do a lot of common tasks. It's not very beginner-friendly, granted, but still a great resource you should know about. Most of the code is general OpenGL ES and not actually specific to their hardware, though some of the texture-related tools and optimizations are designed for best performance on their hardware and in some cases use vendor-specific extensions. If you're an iOS-only dev, that's not a problem at all unless Apple changes their GPU vendor.