Startlingly, the webkit-based browser on the iPhone supports the HTML 5 client-side storage standard. Alas, you can't write properly off-line apps because there's no local HTML/file cache on the phone you can keep files in. You could use the bookmarklet trick I suppose, but I don't like that one - it's nasty, and makes development annoying - you have to keep re-syncing things, it's not terribly easy to upgrade, etc.

I do, however, want to write local apps in a language that's a little higher-level than Objective-C. It's nice and all, but I prefer things to be more flexible. The iPhone SDK agreement means that I can't write my code in a high-level language and ship an interpreter, alas - no iPhone pyobjc for me. But (and this is speculative, I'm not a lawyer, etc etc) as I read the iPhone SDK user agreement, I think you could probably write a pure HTML/JavaScript application, using the webkit local storage engine, and run it in an embedded webkit view as a local iPhone application.

3.3.2. [..] No interpreted code may be downloaded and used in an Application except for code that is interpreted and run by Apple's Published APIs and built-in interpreter(s).

(emphasis mine)

This means I can have a shippable application, with local storage, but with large bits of logic written in JavaScript. I may even be able to intercept requests for urls and call API functions from Objective-C space, so I can expose location data to the application, for instance.

There are obviously huge disadvantages to writing an app in HTML, but I'd like to try it if only as both a rapid prototying environment for local apps, and a way of giving apps that are already HTML-based some local storage and the ability to be run when away from network.

Unfortunately, I feel that I can see where this could get taken. The spirit of the SDK agreement is clearly that Apple don't want any way of distributing applications except through the App Store. This exception is in the SDK only because you can't have an embeddable web browser widget without saying 'stuff the web browser does is ok'. But if this loophole actually is a loophole, I don't see what stops me writing a front-end that can download more HTML into the local storage area.

Well, no, actually, I see

3.3.3 Without Apple’s prior written approval, an Application may not provide, unlock or enable additional features or functionality through distribution mechanisms other than the App Store.

..which might cover that one. Maybe I'll write something like this as an experiment anyway.

Here's another thought. If I can intercept requests and call Objective-C functions, why do I need the HTML-displaying part of this at all? How introspectable is Obj-C anyway, and can I ship an Objective-JavaScript bridge in my app?

The video everyone is watching, apparently. Also, there are lasers! But I like the little QR code machined into the inside of the body. Awwwww.

http://www.apple.com/macbook/#designvideo

Hurrah for throwing random ideas around - Simon Wistow has implemented my wouldn't it be nice.. message queue idea. Regrettably, it's written in Perl, which means it won't get any 'cool kid' traction and be lost to the mists of history. But good effort anyway, eh?

Though Paul's comment on that post raises a good point. This stuff belongs in the frameworks nowadays. Sure, there are add-ons. But frankly I want to consider it like the ORM - you can swap out another one if you want, but look, here's a perfectly good message passing abstraction built right in!

Wait! More ideas! This one has been stewing for longer. It's a pain writing message handlers in Rails. I want to send email. Or IMs. Or do something useful. But these things are almost always implemented as methods on models, and in the model I'm not supposed to know about the outside world. In rails, models don't know how to generate urls, for instance (whereas in Django, models are responsible for knowing what their authoritative representation URL is. This is alternately great and weird to me. How do I have a different URL for the object on the mobile site?).

The interface I really want is the standard MVC model, where in this case, the View is the message transport layer, and my message handling code is in the Controller. I want access to my url helpers, so if I proxy incoming Jabber messages to queue messages (which is probably a good idea) I can reply to these messages and link to web pages. I want a session abstraction, tied to the transport layer, so I can fake a long-running conversation, and I want it to look like the web session abstraction. Sure, I can do the session stuff myself, but it belongs in the transport layer abstraction - noone would seriously suggest you write your own web session handler nowadays, would they? The 'web' interface to my app shouldn't be 'special' like this.

Image by bartmaguire

There's been a new release of Byline, my favourite iPhone app, and it's great. It syncs my folders, so I no longer get swamped when my economist feed grows 90 items, and I can add notes from the phone, which is not something I had realised I needed till I got it. I haven't used the new version in anger yet, but it's making me happy already.

Apart from the look. What's with this faux-wood effect? Ewwww.

It also no longer shells out to Safari to read news items when I tap on an URL. This seems wrong, but because the iPhone won't multi-task, it saves me app-switching time. I'm torn on this one - while I think that web browsing should be done by the system web browser, it's so easy to embed a web view that's just as good as Safari that I'm not losing out on anything here. I can't bookmark things, I guess. But I can open the page in Safari from Byline if I want to do that. So I guess 'embedded web browser' wins on convenience over abstract theoretical goodness. Just like the iPhone itself.

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

I don't normally get much traffic...

http://daringfireball.net/linked/2008/10/08/contacts-and-...

Right. Here's an idea I want someone else to build, because I'm too lazy/busy. I want a Stomp interface to mysql.

Let me explain. There are lots of reasons you might want a message queue architecture in your new web application. You want long-running background processes, or you want to fan out changes to lots of users without tying up the web server process. Or you want to make calls to an API somewhere, again without tying up an expensive web server process. It's a lot easier to build this stuff in from the beginning than to try to work out later which bits of your application flow don't need to happen before the web page is returned to the user.

At the same time, it's a tiny new web site. You don't want to have to run a message queue just yet, so you want to fake it - write tasks into a database table, and have a long-running daemon loop forever, pulling out rows in order and doing them. Almost as good as a real message queue for small volumes of messages, and a lot cheaper. So what I want is a way of doing this that has the same API as a real message queue, so that when you cut over, you don't have to change any code, everything just gets more responsive. Yay!

Right. Now someone do it. Let me know when you're done.

Apps on the iPhone can ship a 'default.png' in their bundle. When you start the app, it'll first show this image, then load the rest of the app. The idea is, you can ship a picture of the start state of your app, and it'll appear to have started very quickly. This is why some apps are unresponsive just after they start - they're not actually started, you're just looking at a picture. Other apps misuse this feature to display a splash screen. Urgh, splash screens.

Anyway, I digress. I have noticed that both the Contacts and Maps applications can change their default.png files. On start they both show you the state of the application as it was when you last saw it, rather than a simple default start image (most apps that I've seen ship an image of their basic layout, with the content removed, so it looks like the content loads a second after the app).

This is easiest to see in the Maps application. Search for a business, then touch the blue chevron to see details of that business. Quit Maps back to the home screen, and run something else (unlike 3rd party apps, Maps will stay running till forced out by some other app). Run Maps again. It will start up with the same view, but be briefly unresponsive till the app proper has started up. You may see the small map in the top-left redraw.

It's a lot harder to get Contacts.app to do this, but the effects are far more obvious. The best way is to change the contents of your address list without using the application - sync in a new contact, or remove a contact. The first time you run the app, you'll see the old list for a moment, then the new list. I first noticed this when I synced my iPod touch to another computer, changing all the contacts. Running address book showed me the old list of contacts for a second, then switched completely to the new list.

3rd party apps can't do this - altering bundle files will change the app, and break the signing. Another thing that Apple apps can do and 3rd party apps can't (though not all Apple apps to it. The Clock app is a perfect example of how I'd expect apps to start up). It's subtle, but it means that Apple apps will appear to start faster, and record state better, than my apps. It a level playing field too much to ask for?

Update, 13th October: I was rude about splash screens. Craig points out that he doesn't have anything better he could possibly display at startup. Anything that looks like the app running will just feel like an unresponsive start state, and will be wrong anyway. A blank screen is just entirely wrong. Splash screens might be the best of a bad lot.

Back in the mists of history, web links were supposed to be 2-way. The site being linked to would also know who was linking to it. This might have been a good idea, I don't know. I do know that it didn't actually happen. In the interests of worse is better links ended up being simple one-way connections from the linking page to the linked page.

Then people started bookmarking things. And actually using links and expecting them to work. Which is reasonable. But the buggers also expected them to still work 6 months later, which meant that suddenly pages weren't able to move any more! Oh the humanity.

It's ok, though. If you really needed to move a page, you could. Just use a 301 Moved Permanently response to the client, and everything would keep working. The really smart clients could even update their bookmarks if the server claimed that the bookmark was somewhere else.

This is no longer good enough. Pages really have to stay where they're put. And they also really really have to have a single canonical url. None of that 'optional trailing slash' stuff. And really none of this 'more than one valid hostname' awfulness.

This is primarily the fault of delicious, which associates comments with pages based on the MD5 hash of their url. Add a trailing slash and the hash changes. Change the hostname, and the hash changes. (Of course, delicious just changed their hostname and thus broke all meta-commentary. Sigh.)

Recently we also have Disqus which, by default, uses the address of the page it's embedded on to associate that page with its comments. I change the address of the page, I lose all the comments. Same principle. This one is fixable, up to a point - you can tell Disqus what they should consider the page permalink, so that if you move a page, all you have to do is remember where it used to be and tell Disqus that. And put a redirect in, so that when people come from Disqus to the old page url, they still get to where the comments live.

We seem to have bi-directional permalinks back again. With none of the advantages - delicious doesn't tell me when someone bookmarks one of my pages, for instance, I'd have to ask them about every single url on my site - and all the disadvantages, in that I can't ever change urls now, even if I use redirects.

But we knew that already.