You can’t verify that a level map is ‘correct’ – it’s largely subjective and involves more art than science. A game level needs to be visually appealing and needs to be challenging enough to maintain interest while still being possible to win.

I’ll admit, it was a brilliant feature and I bought the app while it was still available. If you weren’t lucky enough to get Handy Light, iProxy is available at github, which will do exactly the same thing without masquerading as a flashlight app.

As a result of this deception, Apple seems to be a lot more cautious and taking more time to review apps, as reported by several developers on Twitter and the iPhone SDK mailing list. I only submitted Removr yesterday, but it’s still “waiting for review” 24 hours later. Most of the time it was less than an hour waiting for review before it changed to “In Review”.

During beta testing, I had a feature in Removr which checked my server for updated level maps. I was doing very careful version & timestamp checking and could either run SQL code to insert or modify levels or replace the entire level database. I removed that feature for the release version because I was afraid Apple would reject it if they discovered it.

This is exactly the case with Removr. Game levels are defined by an object that specifies the background image and a bitmap of the layout of pieces on the screen. Although Core Data could easily fetch the object as needed in Removr, it would be very difficult for an external level editor to create those objects and update the persistent store.

My level object happens to be very simple and can easily be mapped to a database structure.

// Level.h
@interface Level : NSObject {
    NSData * _map;
    NSString * _background;
    NSNumber * _index;
}

@property (nonatomic, retain) NSData * map;
@property (nonatomic, retain) NSString * background;
@property (nonatomic, retain) NSNumber * index;

@end

// Level.m
#import "Level.h"

@implementation Level
@synthesize map = _map, background = _background, index = _index;

- (void)dealloc
{
    self.map = nil;
    self.background = nil;
    self.index = nil;
    [super dealloc];
}
@end

The corresponding database structure looks like this:

CREATE TABLE levels (
	ix integer NOT NULL PRIMARY KEY AUTOINCREMENT UNIQUE,
	background text,
	map blob NOT NULL
);

Fetching the objects from sqlite takes more code than using Core Data but isn’t too difficult. I need to deal with two different SQLite3 objects for the database connection and the prepared query. Rather than interpreting the SQL query every time you execute it, you will prepare the query once and execute it as many times as you want.

A good introduction to the SQLite3 C interface is available here.

Here is my level manager. My init method opens the database connection and prepares the query that will be used later. Note that the query includes a ‘?’ for variable substitution.

The GetLevel method is where the interesting stuff happens. The function sqlite3_bind_int() tells it which level number we’re looking for and sqlite3_step() actually executes the query. In this case, I’m only interested in a single row, but in many cases it will be called repeatedly as long as it returns SQLITE_ROW. I then use the sqlite3_column functions to extract data from the result row and populate my Level object. Finally, calling sqlite3_reset() will allow the prepared statement to be reused.

// LevelManager.h
@interface LevelManager : NSObject {

    NSString *_dbpath;

    sqlite3 * db;
    sqlite3_stmt * query;
}

@property (retain,nonatomic) NSString *dbpath;

@end

// LevelManager.m
#import "LevelManager.h"
#import "Level.m"

@implementation LevelManager

@synthesize dbpath = _dbpath;

- (id) init
{
    if ((self = [super init])) {
        self.dbpath = [[NSBundle mainBundle] pathForResource:@"levels" ofType:@"sqlite3"];
        sqlite3_open([self.dbpath UTF8String] , &db);

		// this query will be used to obtain a level from the database.
		// The '?' will be replaced with the level number when we perform the query
        sqlite3_prepare_v2(db, "SELECT * FROM levels WHERE ix=?", -1, &query, NULL);

    }
    return self;
}

- (void)dealloc
{
    sqlite3_finalize(query);
    sqlite3_close(db);

    self.dbpath = nil;

    [super dealloc];
}

- (Level*)GetLevel: (int)number
{
    Level *lvl = nil;

	// specify the level number we want for the query
    sqlite3_bind_int(query, 1, number);

	// request a row from the query result
    if (sqlite3_step(query) == SQLITE_ROW) {
        void *blob;
        int nbytes;

		// first, create a new level object
        lvl = [[Level alloc] init];

		// integer columns are easy
        lvl.index = [NSNumber numberWithInt: sqlite3_column_int(query, 0)];

		// string columns are a bit more complex since we need to convert a C string to a NSString
        lvl.background = [NSString stringWithCString:(char*)sqlite3_column_text(query, 1)
                                                                 encoding:NSUTF8StringEncoding];

		// BLOB columns require two calls to obtain the actual data and the length
        blob = (void*)sqlite3_column_blob(query,2);
        nbytes = sqlite3_column_bytes(query,2);

		// we use the bytes & length to create a NSData
        if (blob && (nbytes > 0)) {
            lvl.map = [NSData dataWithBytes:blob length:nbytes];
        }
    }

	// get ready to reuse the query
    sqlite3_reset(query);

	// we should return an autoreleased object
    return [lvl autorelease];
}

@end

Previously, I was loading the thumbnail directly from my table data source’s cellForRowAtIndexPath: method.

- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath {
    static NSString *CellIdentifier = @"tvCell";

    UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:CellIdentifier];
    if (cell == nil) {
        [[NSBundle mainBundle] loadNibNamed:@"tvCell" owner:self options:nil];
        cell = tvCell;
        self.tvCell = nil;
    }
    NSString *url = [picUrls objectAtIndex: indexPath.row];
    UIImageView *img = (UIImageView*)[cell viewWithTag: 2];
    img.image = [UIImage imageWithData: [NSData dataWithContentsOfURL:[NSURL URLWithString: url]]];
}

If you don’t have too many rows, a NSMutableDictionary makes a quick & easy image cache. I simply added one method to implement image caching:

NSMutableDictonary *imageCache;

- (UIImage *)getCachedImage: (NSString*)url
{
    UIImage* theImage = [imageCache objectForKey:url];
    if ((nil != theImage) && [theImage isKindOfClass:[UIImage class]]) {
        return theImage;
    }
    else {
        theImage = [UIImage imageWithData: [NSData dataWithContentsOfURL:[NSURL URLWithString: url]]];
        [imageCache setObject:theImage forKey:url];
        return theImage;
    }
}

When I load my table, I now call getCachedImage rather than fetching the image directly.

    img.image = [self getCachedImage: url];

The result can be seen below:

The Yazzem team has been working on an API which will allow developers to build applications that interact with Yazzem. It will be featured at the Hacker dojo API hackathon tomorrow.

Read the Yazzem team’s API announcement here. The API is documented at api.yazzem.com.

For Mac & iPhone developers, I’ve created a Cocoa wrapper class with both Mac & iPhone demo applications, available at http://github.com/mike3k/Cocoa-Yazzem.

I was already planning to make I Can Has Cheezburger 2.0 require firmware 3.x, since Three20 requires it. This makes my decision a lot easier.

Adding the following tags to your <HEAD> will make your application open in full screen and hide Safari’s toolbars. In addition, if you add it to your home screen, it will appear to open without Safari and no page will be added to Safari.

<meta name="viewport" id="viewport" content="width=device-width,user-scalable=no,minimum-scale=1.0,maximum-scale=1.0" />
<meta name="apple-mobile-web-app-capable" content="yes" />
<meta name="apple-mobile-web-app-status-bar-style" content="black" />

The following tags, which should also be added to <HEAD>, will provide an icon for the home screen and a splash screen to be displayed when it opens.

<link rel="apple-touch-icon" href="http://example.com/webclip.png" />
<link rel="apple-touch-startup-image" href="http://example.com/startup.png" />

The first application I’ve seen which uses this trick is Fever.

Our application uses a ‘scraped’ feed generated from the site content rather than the site’s own RSS feed. We do this because the standard RSS feed only has a limited number of items and must be loaded in its entirety. By scraping the site, we can create multiple pages with unlimited items, which load a lot faster since it only loads 10 or fewer items at a time.

The feed scraper was originally developed by the folks at ICHC for their dashboard widget. I later modified it to support all of their sites and change the output from JSON to simplified XML. Unfortunately that feed scraper has a major flaw. It uses regex pattern matching to parse the HTML, which is a Very Bad Thing. The script can easily get confused by changes to the site and often produces invalid data. It also hasn’t included videos since a format change at the site broke it.

Last night I started hacking at it with PHP’s XML parser and DOM commands and came up with a much more robust script that uses element classes to identify valid items and to avoid outputting bad data that could crash the application. I’m also hosting it on my own server at DreamHost, so I can easily fix it myself instead of having to go back and forth for fixes as we do now.

Unfortunately a few Viddler movies still won’t play, since they must be explicitly enabled for downloading on the site.

plasmacutter writes “The Video Lan dev team has recently come forward with a notice that the number of active developers for the project’s MacOS X releases has dropped to zero, prompting a halt in the release schedule. There is now a disturbing possibility that support for Mac will be dropped as of 1.1.0. As the most versatile and user-friendly solution for bridging the video compatibility gap between OS X and windows, this will be a terrible loss for the mac community. There is still hope, however, if the right volunteers come forward.”

VLC is one of my favorite applications, so I’d hate to see it die. Unfortunately I have too many other things going to take on another project, especially an unpaid one, or I would get involved.

The crashes seem to occur when restoring the last viewed item results in an index out of range. We use a scraped feed (which is hosted on one of ICHC’s servers) that returns pages of 10 items each, to reduce the load time. I’ve seen a few instances where items, usually videos, are missing from the scraped feed, and in that case it returns a page of fewer than 10 items. If you happen to have been viewing item 10 the last time you quit and the next time you end up with only 9 items, it will crash.

I’ve put in some error handling for that case, but if you’re experiencing that crash, I’d like to have you test it before I submit the update, so email me your device ID and I’ll add you to my beta list. Note that Apple can take several weeks to approve an update, so even if I submit it right away, it may be a while before the update becomes available.

This will be the last update to this version. I’m doing a major rewrite for version 2.0 using Three20, the framework used in the FaceBook app. This will be a free upgrade.

Before I do much on v2.0, I’m finishing a new application I plan to release first. More about that in the next few weeks.