Navigating a mobile app can be slow, especially on long pages and slow scrolling phones. Fortunately the xhtml mobile profile markup language supported by mobile phones provides a solution to finding links and starting phone calls inside the mobile browser.

accesskey

Adding the accesskey attribute to link a lets users “click” on that link by simply pressing a number on their phone’s keypad. Valid values for accesskey can be 0-9,#, and * (all of the keys on a standard phone keypad). Displaying which key will activate a link is up to the application as most phones won’t tell the user that a link has an access key. Web site designers currently need to decide on a consistent way to inform users that an access key is associated with a given link. Most apps will use ordered lists where the order of the links corresponds with the access keys. Putting the number in brackets inside or next to the link is another way to denote the accesskey.

(more…)

Today, I was eating lunch alone at a restaurant and reading some news via my iPhone’s EDGE connection. Suddenly, Surfin’ Safari - Blog Archive » Optimizing Page Loading in the Web Browser made even more sense.

Apple has been putting actual dollars into making Safari and the underlying open source WebKit really, really fast. Safari 3 is significantly faster than Safari 2. There was another big speed boost after Safari 3.0.

(more…)

Mobile application development has many challenges. The announcement of Google Gears on Mobile Devices will help solve the problems of network connectivity, network latency, and limited bandwidth. On the desktop, a lot of the focus on Gears was its ability to allow applications to function when your computer was not connected to the network. In addition to building mobile web apps here at SitePen, we released Dojo Offline, which integrates the Dojo Toolkit with Gears to make building disconnected web applications even easier. As we all know, mobile devices lose connectivity with the network on a regular basis. Gears’ ability to keep the data that users need stored on the phone will be key to keeping mobile applications running even when networks fail to keep phones connected.

(more…)

Google released the first preview of Android today. It is chock full of features and a great emulator, but there was one interesting omission.

Beyond what has been covered elsewhere, there are many attention grabbing features for mobile app developers:

• XMPP in the application stack, giving applications access to low-latency event driven messaging
• Location data (via GPS or cell-tower triangulation) accessible by applications
• SQLite for local data storage
• Applications can provide services to other applications… no need for 10 different photo taking apps

(more…)

I recently had the opportunity to speak about Dojo on the iPhone at AjaxWorld West. The session was a straightforward, if not colorful, review of the current state of app development for the iPhone.

In preparing for the presentation, I needed to install several native applications in order to create high quality screenshots for my slides. As a result, I presented the audience with an overview of this information because there are a variety of useful development tools that require installation.

Because Christopher Allen gave a talk just prior to mine with an iPhone and iPod Touch Ajax overview, I dove right into specifics about the current issues and problems with iPhone development for Dojo developers. I wrapped things up by walking through a few working examples of Dojo-based applications, some optimized for the iPhone and others not. At the end of the talk, I promised a forthcoming, iPhone-optimized Dojo build that removes features and code for items not supported on the iPhone. We hope to have that ready in time for the 1.0 release of Dojo on October 31.

The press seems to have enjoyed the session, with Network World running a fairly lengthy article titled Unauthorized iPhone Apps Market Flourishes. I should make it clear that my talk focused mainly on pitfalls and frustrations that developers face, but the iPhone is by far the best mobile, open web, development solution on the market today.

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.

(more…)

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(e.target.value); }, 0);
  }

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.

(more…)

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.

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.