Skip navigation

It may seem like I haven’t done much recently, but in reality I’ve been feverishly working (read: limping along in a sickly fashion) on creating the widget version of Subsume. It’s mostly there, with many lessons learned, but I’ll still be tweaking and debugging until at least the Apple event next week. With any luck, that will mark the release of a WiFiPod, or what is essentially an iPhone without being encumbered by the cell phone bits (and hopefully an 80+GB hard drive). The iPod is definitely in need of an update using the new technology, and sooner is better than later if they want to hit the back-to-school and holiday buying crowds.

But back to the topic of turning web apps into widgets. It’s definitely a troublesome task if you didn’t start with the plan of making a widget. It also looks like it would be just as painful to create a web app from a widget if you didn’t begin with that intention. You’d think Apple would make it easier, what with them having both Dashboard and the iPhone, but maybe it makes sense somehow to keep a bit of distance between the two technologies. So, for the curious, here is a list of a few best practices when approaching generic Web 2.0 development:

  1. Pages are good/bad
    The natural interaction on web pages is to navigate to another page, but widgets (at least with Apple’s Dashboard; other engines might vary) jam everything into a single page. You have to endure the pain of hiding and showing various blocks in that HTML file, and for complex layout like Subsume has, it can be a pain to edit the thing. We also used a standard form to configure the game initially, but with widgets you’re going to have to manage all your server interaction with XMLHttpRequest calls, so plan on using that from the start.
  2. Proprietary is good/bad
    Widgets often have their own interface elements you need to use to have them work right, but you can’t really count on any of them being available for the web version. To keep things portable, it’s best not to get sucked in to making things too fancy, and keep in mind how to get results that work in both cases. For example, I added a portable layer that allows the game configuration to be read from either the widget preferences or the web URL.
  3. Objects are good/bad
    One big plus I found is that my JavaScript game objects are virtually unchanged in implementing the widget version. As always, it’s in your best interest to decouple things as much as you can so that you can take advantage of OO reuse. My object model is nowhere near perfect, but people writing spaghetti code are really in for a world of hurt if they put the above-noted proprietary technology too deep in their own code.

I think Apple really dropped the ball by not supporting at least widget installation on the iPhone. Not only has it made my job more difficult, it doesn’t really reinforce Apple’s brand or technologies. I can let it slide and make due for this first version of a new product, but they would be smart to quickly unify their “nano-app” development with a common vision across product lines.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: