iPad Applications

With the iPad about to launch I've been doing some thinking about the sorts of apps we'll see on the device. I think iPad-specific apps will be a completely different beast than iPhone apps. The iPhone has pretty limited screen real-estate (320x480 or transpose if rotated) and while the iPad is "only" 1024x768, it comparatively allows a significantly larger amount of stuff to be slapped onto the screen. A lot of iPhone apps are made by single people without a designer behind them. The bad bunch of these (and there's a lot of them) have either extremely basic or straight-up-shitty UI design.

With all the extra space on the iPad screen, I think the quality of apps will have to go up. With iPhone you can make a minimal or relatively shitty UI because there just isn't that much of it on the screen at any given time. Most of the iPhone screen is dedicated to showing content, so if the UI sucks it doesn't always detract from the overall experience too badly. That just won't be the case with the iPad. Poorly laid out components, tons of whitespace, crappy art assets, etc. - all these things will stand out even more on the iPad.

There are tons - TONS - of simple news aggregators on the App Store. 20 apps that could have been combined into 1 (like sports apps which follow University X basketball, baseball, football, etc. 1 app for each sport) which have almost no UI at all. It works because they show whatever data and it fits and looks nice. But what happens when you up the res on that? A totally blank screen. I just don't think that will fly anymore on iPad. Perhaps I'm wrong - but it will be interesting to see what comes after the first round of (probably polished) apps.

Progress Report

I forgot to say how the game was doing!

It's going great! Game development is strange, I look forward to getting better at it. After coming from the UI-centric world of HTML/CSS/JS, it's very different to care about sprites and physics engines, and a bunch of other stuff the user only perceives indirectly.

Now I'm stuck on how to combine OpenGL primitives with Cocos2d draw calls. Cocos seems to want to stomp my polys no matter what I do :(

Good job Google App Engine

After my complaining previously, Google has fixed one of my complaints! Now you can store images as blobs and retrieve them as such instead of awkwardly storing them in your database. No more arbitrary image size limits!

Also bonus feature, task queues! Now you can actually have web apps do something when a user isn't specifically requesting it. Pretty neat.

Now if only they would fix the other six problems, that would be great!

No, you can't break it into sections

Pretty much everyone who read my previous entry said "hey, can't you break the image into sections?"

No, you can't break it into sections.

The whole point of the algorithm is that it turns multiple images into one high quality image. To do this, it has to align images precisely. If you sacrifice any part of the image during alignment, you will not get a precise match.

super... project abandon!

Well, I have abandoned yet another project. Yay!

This time it was a super-resolution app. The idea was: you take several photos with your iPhone camera, it processes them, and returns one really high-quality photo. Turns out there is no way in hell that you will have enough ram to complete that task. Just allocating the floating point array to process photos took 36mb out of an allowed 24.

If someone is super interested, I still have the code laying around.

Time to work on the simplest game I can so I can finally get a project out.

Apple and Naming Conventions

For those not familiar with Cocoa (Mac OS, iPhone) development, Apple has strict naming schemes for their libraries. They actually have an entire document dedicated to this (seen here). Methods that return a boolean are "shouldPerformAction", actions which are about to happen will look like "willDoSomething", actions that just completed will look like "didDoSomething", etc. A lot of Cocoa criticism comes from the fact that this causes a lot of the method / variable names to be extremely verbose. "Can row x in a table be selected?" becomes

(NSIndexPath *)tableView:(UITableView *)tableView willSelectRowAtIndexPath:(NSIndexPath *)indexPath

"Trim this string" becomes:

[string stringByTrimmingCharactersInSet:[NSCharacterSet whitespaceAndNewlineCharacterSet]]

I initially disliked this when first starting iPhone dev, however after a number of months it's really grown on me. Yeah some of the lengthy stuff is annoying, but it really makes a lot of the code REALLY CLEAR on what's happening and that is extremely valuable.

Anyways, sometimes this naming scheme breaks down and that's what I'm here to complain about. When the user taps a row on a table (like in the email or iPod app) the following method is called:

- (void)tableView:(UITableView *)tableView didSelectRowAtIndexPath:(NSIndexPath *)indexPath

There's also others that follow this:

- (void)tableView:(UITableView *)tableView didDeselectRowAtIndexPath:(NSIndexPath *)indexPath
- (void)tableView:(UITableView *)tableView didEndEditingRowAtIndexPath:(NSIndexPath *)indexPath

Some cells have a little blue circle with a > inside of it, this is called a UITableViewCellAccessoryTypeDetailDisclosureIndicator (yeah). When tapped, the view slides over to a more detailed view of the data. For example you tap a row in the Recent Calls list and it calls the number back, tap the blue circle and it brings up contact information for that person. So what method is called when this is tapped?

- (void)tableView:(UITableView *)tableView accessoryButtonTappedForRowWithIndexPath:(NSIndexPath *)indexPath

Huh? Not at all what you'd expect. I figured I'd be looking for "didTapAccessoryButtonForRowAtIndexPath". There's no "did" in this. Instead of "...RowAtIndexPath..." we have "...RowWithIndexPath...". Why is this so different? I know this sounds like a tiny nitpicky thing, but Apple has put literally thousands of man hours into standardizing this shit. It makes no sense that this single method name is so different from the others.

Now, it didn't take me more than a few seconds to find the method name I was looking for, so I'm not complaining about it destroying my productivity or anything, but it just doesn't make any sense for this to be so deviant.

new idea

I had an idea today:

Mechanical Turk is a great way to take a little bit of thinking from a lot of people and apply it to one big project. But what about *really* boring stuff, like recognizing whether a photo is of a mouse or not?

I give you Mousewheel v1.0. It features massive arrays of lab mice, tv screens, and buttons that dispense treats. Three mice are shown an image and trained to respond a certain way to it. For example: if we are searching for mice in photos, they push "yes" if there's a mouse, and "no" if not. The majority gets a food pellet each. Mice with low accuracy are ground up and fed to the other mice in order to serve them better.

The cost of running a single mousenode is far cheaper than a mechanical turker. Watch out Amazon, I'm coming for you!

+0600

We're saving multiple images, woo!

I am amazed at how complicated I made this problem. I had to keep track of some files, and what project they belong to. I realized I could just use folders, and just name everything the timestamp of when it was created. I guess I was so caught up in database-think, I thought everything had to have a magical uniqueid.

Things I have learned

It is hard to debug UI issues, because you can never tell if that white screen you're looking at is really the widget you think it is, or maybe it didn't load and that's the background, or maybe it loaded and it's just colored entirely white, or maybe something white is on top of it, or maybe your code is in an infinite loop and it erased the last UI element, but hasn't loaded the new one.

Argh.

I got the phone taking a picture without any of the camera interface crap, and saved it to memory. Now to take a million photos and save them all.