Sep 4

The iPhone Screenshot Quest

By on September 4, 2007 11:10 pm

I speak at a number of conferences and am giving a couple of talks later this year about Dojo on the iPhone. Of course, giving a talk without being able to show demos is frustrating, but giving a talk without having high-quality screenshots is silly. There wasn’t a solution known outside of Apple until recently, and it is still a bit of a process, or I daresay a bit of a quest. These instructions are for Mac users… I’m sure the steps are pretty similar for Windows users as well.

Aug 2

Safari on the iPhone: 2 Steps Forward, 1 Step Back

By on August 2, 2007 10:03 pm

I’ve been following John Gruber on Twitter, who just noticed that the iPhone update (1.0.1) now updates Safari with the ability to send key events. Fantastic! 2 steps forward.

But, onkeyup is broken. You see, the onkeyup event is supposed to be called after a key event has officially propagated through the page. This is very important, because by the time onkeyup gets called, the page should have adjusted itself for this newly inserted character. For example, in a text input box, when you press a key it doesn’t show up in that input box until after onkeydown and onkeypress have been called, but does show up before onkeyup is called. Pretty much the whole reason that onkeyup hook exists at all, is so that you can be notified after this change has happened. The iPhone sends onkeyup before the page has been updated. 1 step back.

What this means is that sites that rely on using the onkeyup event to tell what is in their text entry box will break. There is a simple solution though! (other than having to find the key value in the event object) Just use setTimeout, with a timeout of 0 and you’ll be able to see the proper value. For example:

  input.onkeyup = function(e){
    setTimeout(function(){ alert(; }, 0);
Jul 12

Filling the iPhone Chat Gap

By on July 12, 2007 8:37 pm

iphone_chat.png Many people are perplexed by the absence of instant messaging on the iPhone. Apple has done great things for SMS with their ichat styled interface. Unfortunately they stopped short of providing a seamless IM experience. Hopefully Apple will add these features in a future software update.

The iPhoneDevCamp in San Francisco last weekend saw several groups working to fill the IM gap by building iPhone compatible IM web applications. I spent part of my time there revising the existing cometd chat app to work well on the the iPhone. Comet’s long-running http connections are ideally suited for chat apps as it provides very low latency. We had already tested cometd on the iPhone, so I was encouraged about the ease of porting the existing chat demo.

Jul 5

Messing around with the iPhone

By on July 5, 2007 12:50 am

Well, the plan was to go through every type of input object, button, and image in Safari on my shiny new iPhone and make notes about what functions were available, how event handling works, and any other fun little goodies that came along. I started out with the good old text input box, and after an hour or two of executing functions in all sorts of different orders and being seriously freaked out a couple of times, I’m worried about the pretty severe limitations of one of the most basic widgets of the web browser:

  • When the input does not have “virtual keyboard” focus, calling its focus function calls its onfocus function, but does not give the input “virtual keyboard” focus
  • When the input does not have “virtual keyboard” focus, but you’ve called its focus function, calling its blur function will call its onblur function. When the input does have “virtual keyboard” focus, calling its blur function does absolutely nothing (which breaks some scripts that prevent input by blurring on focus).
  • When the input does not have “virtual keyboard” focus, calling its select function does nothing, until you scroll or zoom in on the page, at which point it calls both its onfocus and onblur functions. When the input does have “virtual keyboard” focus, calling its select function does absolutely nothing.
  • Calling its click function calls its onclick function as expected.
  • Selecting an input box fires: onfocus, onmouseover, onmousedown, onmouseup, onclick, and sometimes onmousemove
  • Selecting the next item on the page fires: onblur, and (conditionally) onchange, but still no key events.
  • Clicking the “Done” button in the “virtual keyboard” fires: onblur, and (conditionally) onchange, but still no key events.
  • The only key that registers any key events is the return key.
Jul 4

Thinking outside the (browser) box

By on July 4, 2007 3:13 am

Apple’s iPhone web application development tips are yet the latest example of blurring the lines between the power of the web and the desktop. The example that drives this point home the most is Google Maps:

Google maps links open a built-in Google client rather than making a connection through the public website.

On the desktop, we’re seeing Dojo Offline and Google Gears, as well as more proprietary offerings such as Adobe’s AIR and Microsoft’s Silverlight. One interesting thing coming from Apple that has not received much mention is WebKit and Cocoa bindings, including JavaScript bindings. Soon we’ll be able to use open web standards to create native Mac apps!

The proliferation of JavaScript, HTML, and CSS is rapidly spreading to every area of software development, because open web standards are powerful and relatively easy to comprehend.

Jul 3

SVG missing on the iPhone

By on July 3, 2007 4:02 am

Safari on the iPhone does not currently have support for SVG. Safari 3 beta on Mac and Windows is currently the best browser on the planet for SVG performance, so this is a somewhat disappointing omission. We are hopeful that by the end of the year, the iPhone will receive the Safari 3 upgrade, and along with that native support for SVG. For now, we’ll have to wait on dynamic charting and drawing tools due to no SVG and the lack of mousemove event handlers.

Jul 2

Cometd on the iPhone

By on July 2, 2007 2:20 am

It’s been widely reported that Drag-n-drop on the JavaScript layer is going to be a significant challenge. The canonical fun with magnets demo for Cometd relies on Drag-n-Drop for moving magnets around, so that part of the demo is currently a no-op. That said, the rest of the app seems to work pretty well, with the built in version of Safari not skipping a beat in receiving events and moving items on the screen in response to those events. The speed performance is obviously much better with the wifi connection, but we are still having success over the EDGE network as well. Bottom line: Cometd appears to work out of the box on the iPhone!

P.S.: Does anyone know how to take a screenshot with the iPhone itself rather than using a digital camera?

Update: There’s now screenshot utility for the iPhone.

Jun 6

An Insider’s look at Google Mobile Apps

By on June 6, 2007 1:37 am

Google has posted many of the talks from Google Devloper Day 2007 on YouTube. Gummi Hafsteinsson, a Google Mobile Applications Product Manager, gave an excellent overview on building for the mobile web. Key points in the presentation include:

  • Keep it simple–get your site working on a single basic device first
  • Focus on features your users will need while they are away from their desk
  • Resize images so they are just big enough for the device to save the users time and money
  • Be careful of simulators. Many apps will work on the simulator but look bad or crash the real phone
  • Entry level phones are a large chunk of the market but are very limited and your app may crash them

So how does Google stack up against their own criteria for building better mobile web sites? Let’s take a look at mobile gmail.

Apr 24

Mobile Web Apps: Apple iPhone to Wurfl

By on April 24, 2007 2:24 am

Apple’s iPhone has sparked a great deal of interest and excitement in mobile web application development. The iPhone significantly raises the bar for the capabilities of mobile devices. Its large screen and advanced browser will allow for the development of applications never before seen on mobile devices. That said the iPhone will be one device in a vast ocean of mobile users. Developers of mobile web applications will need to provide a version of their app that supports in some way those other devices.

One of the largest problems facing prospective mobile developers is adapting content to the numerous sizes and styles of mobile devices. Screen size, network speed, image format and markup language support are just a few of the variables to consider. Even the iPhone when on the carrier network, is limited to the dial-up speed GPRS network. To compound the problem mobile carriers and handset manufactures are releasing new phones daily in an attempt to one-up their competitors. If you are planning on creating a mobile version of your web app there are open-source tools available that will make your job a little easier.

Sep 30

Mobile Ajax: Hype, Reality, and SitePen

By on September 30, 2006 1:58 pm

It’s been a little quiet around here lately, but as Dylan’s last post points out, it’s because we’ve been so busy on working on the technologies we need to push the web forward. While Comet, cross-domain services, and native vector graphics are nearly “here”, “Mobile Ajax” is clearly a term in search of a definition.

I’m going to spend a little time recapping my recent excursions into the world of mobile web app development to share a little of what we’ve learned and where SitePen will be focusing its resources with respect to mobile web apps.

Recently, we’ve been hearing more and more about “Mobile Ajax”, mostly in vague terms. I suspect this stems mostly from no one knowing really what it means. Those who are clued into the size of the mobile phone market are, like me, scratching their heads as to why mobile web apps still suck. Mobile phone browsers have traditionally been under-powered to the extent that they can’t really support applications, but Moore’s Law solves that problem eventually. Coupled with significantly improved bandwidth to phones, you’d think that we’d be in a golden area of invention around mobile web apps. It hasn’t happened yet. Significant impedance mismatches between web app developers and the constraints of mobile phones still remain, and despite the high-end of the phone market being “there”, the platform as a whole isn’t. Here’s why:

  • Latency
  • Developer (mis)training
  • Browser issues
  • Carrier slow-wittedness and delusions of competence

All of these factors have contributed to a situation in which web apps on phones, nevermind ajax apps, generally suck. And it’s not for lack of trying. Using google or yahoo on a mobile device today is generally about as good as it gets, and they’re not bad. Unfortunately the text bias that’s built into the fabric of the “desktop web” hurts even these sites which have entire teams dedicated to figuring out how to reduce steps to action.

All of this matters to us at SitePen because it’s our goal to help push the web forward (and this case, outward). Through talks like the one I gave at EuroOSCON (and will give again at AjaxWorld) we’re starting to share the raw data that’s been available but not yet widely distributed. At the end of the day, a couple of things have become pretty obvious out of our research:

  • Ajax on mobile devices isn’t worth doing yet
  • Mobile browsers need to evolve before apps can really take off
  • Developers need to stop expecting to get text from clients
  • Developers need to start thinking about “stacking” interfaces instead of scrolling
  • Most big web properties are already “on it”, leaving smaller firms at a disadvantage in both experience and motivation

All of this generally means that the term “Mobile Ajax” is likely to be a code word for “snake oil” for the foreseeable future. Ajax isn’t the right answer for mobile devices. Other techniques will evolve to improve the utility web apps for mobile devices, and here at SitePen we’re already working to test out some of our hunches about how we can solve the existing UI problems.

If you’d like to learn more about what we’re working on in this area and how our expertise and perspective might improve your mobile apps, drop us a line.