jerakeen.org

by Tom Insam

notes☴

code☷

links☲

photos☵

SPACE DEADBEEF

SPACE DEADBEEF

created 15 December 2008 in links tagged free, games, iphone, rez and touch.

It’s a tech demo in terms of length and content. But this tiny thing is a beautifully execyuted side-scrolling shooter, and certainly the closest thing to Rez I’ve seen on the iPhone so far. It’s also a really nice use of the touch screen - sweep a finger over the enemies to target, release to fire - whereas most apps I see are tending to treat the touch as merely a way of faking traditional controls. No! Look at Zelda on the DS for how touch should work. It’s also free. Go play it.

http://itunes.apple.com/WebObjects/MZStore.woa/wa/viewSof...

Trivial iPhone / iPod Touch delicious front end

created 23 January 2008 in blog tagged ajax, delicious, iphone, ipod, javascript, software and touch.

I’ve been looking for an excuse to play with IUI for a while now, and finally I found one. I wanted a way of getting at things that I and my friends have saved in del.icio.us, and the native web interface isn’t very usable on the iPod touch. So let’s implement a delicious client using IUI! Also, let’s implement it in pure client-side JavaScript, so I don’t have to run a server anywhere!

So, here’s a trivial implementation. It’s hard-coded to look at my links and friends, but that’s not hard to fix, I just don’t care. The thing I’m happiest with is the way it’s entirely client-side, and pulls in things from the delicious JSON api as it needs them. And it’s pretty small, too..

iPhone web application behaviour

created 21 January 2008 in blog tagged apple, development, iphone, ipod, sdk and touch.

The ‘state of the art’ for iPhone apps is a single URL, serving a static page with lots of JavaScript and Ajax. Clicking (touching, whatever) things loads in fragments and changes the page. IUI works like this, Hahlo works like this, the Facebook app works like this (hence IUI‘s behaviour).

To preserve state, normal usage is to use the URL fragment to add bookmarkability and history. And sometimes, this actually works. But given that the point is to pretend to be a native iPhone application, it’s wrong. You should be storing state in cookies.

Justification: Native iPhone apps act like you never quit them. Even if they get closed by the system at some point, they’ll come back to the state you left them in. Bookmarking a rich web application should act the same - I want to bookmark the application, and have it open in the state that I left it, not the state that I bookmarked it in. So you should update the ‘current state’ in a local cookie every time to navigate somewhere, and respect that state when you next visit the application. Combine this with the 1.1.3 firmware’s webclips thing and you can almost pretend to be native.

Which is why I expect the much-anticipated iPhone SDK to be nothing more than ‘local web applications’. Give developers a little bit of local storage (you know, like webkit just got), a way of promoting a bookmark to the home screen (we have that one now) and a way of storing some HTML and JS on the phone, and Jobs can claim he’s given us an SDK. And he’ll be right.

Me? I’d be happy with that. It solves all the sandboxing, security, ‘bring down the network’, etc problems. And it will keep people from jailbreaking the phone trivially. The only alternative I can see is installation of signed apps only, with the iTunes Media Store as the single point of installation. Which would suck more. But there will be howls of outrage.