80
Using iUI for web apps
Creating web apps with the WebKit gives you a lot of power and allows for a lot of
diversity. But it doesn’t address a real concern: what if you want to create web apps
that have the same look and feel as native applications on the iPhone?
The reasons for doing so are obvious. You can take advantage of lessons that
users have already learned by using Apple’s standard iPhone user interfaces. The
question of how to do so, however, is slightly more complex.
Certainly you could do so using the WebKit’s extensions atop
HTML, and we’re
going to give you the opportunity to do so here by dissecting what makes up the
iPhone interface. Unless you have specific needs, however, creating your own inter-
face is probably overkill.
Fortunately, we have another solution to this problem: a third-party library
exists that you can use to model the iPhone interface. It’s called i
UI, and it’ll be the
focus of much of this chapter. But before we get into iUI, let’s see what the iPhone
interface looks like.
This chapter covers
■
Outlining iPhone web app paradigms
■
Using iUI to make web apps
■
Applying tips and tricks to iUI apps
81Creating your own iPhone UI
5.1 Creating your own iPhone UI
The iPhone UI has quite a few
unique (and distinctive) features.
If you want to model its UI inside a
web app, you must consider all of

senting a consistent
UI, but some of the other programs look slightly different.
You’ll ultimately need to decide how much of the look and feel you want to
model, and how much you want to change it to match your own site’s branding,
a topic we’ll return to toward the end of this chapter.
■
Use chrome —It’s most important to match the iPhone’s chrome. Put navigation
and control bars to the top and the bottom of your App’s web pages. You might
want to match the iPhone’s gray coloring, or you might want to match the col-
ors of the rest of your site.
Action Button
Back Button
Chrome
Separated
Choices
Figure 5.1 The iPhone has a unique look and feel
that should be emulated in iPhone web apps.
82 CHAPTER 5 Using iUI for web apps
■
Put action buttons in your chrome —In the chrome, it’s not just the navigation
that’s important, but the action buttons as well. For example, several applica-
tions put a “+” action in their chrome to generate new content. Safari also
includes search and bookmark actions.
■
Create sliding menus —Menus of options should typically be display on subpages,
not as a part of your web app’s main display. You might click an action button to
pop up a menu. Alternatively, a list of options that fills the screen might each
have a > symbol that leads to its own subpage, as with the iPod’s “more” pages.
Though we call these sliding menus, for the way they animate on the iPhone, you
probably won’t mimic that aspect in your web app (unless you use i

term is also used to refer to individual objects, or subviews, within a page).
Many web apps will be built using the same concept, allowing pages to call up other
pages using tab bars, navigational controllers, and other means. As you’ll see, the
view model is well supported by various tools that you might use when creating
iPhone web apps. iUI (which we’ll discuss in this chapter) supports it as part of its
navigational methods, and Dashcode (which we’ll talk about in the next chapter) sup-
ports it using a
stackLayout
object.
We’ll see even more complex view hierarchies when we begin using the SDK, which
is the ultimate model that these other libraries are imitating.
83Creating your own iPhone UI
This advice is crucial for putting together an iPhone-UI web app, but it’s also primarily
visual. When creating iPhone web apps, it’s important to think about the base para-
digm that underlies your web development.
5.1.2 The iPhone data paradigm
We’ve already talked quite a bit about how the iPhone is technically different from
last-generation mobile phones. We also believe that a core difference exists in the
methods that people use to access information on the iPhone.
The desktop internet centers on the paradigm of browsing. Although users will
sometimes go to a specific page for certain information, a lot of internet usage instead
centers around idle viewing of interesting sites. Because browsing is so important,
desktop-centric websites often center on immediately dumping unsorted piles of con-
tent on users, hoping to draw them further down into a site.
We believe that these priorities are reversed on the iPhone. You are less likely to
attract casual browsers and more likely to attract users who already know what your
site is and are visiting it to retrieve specific information. This more data-centric view of
web usage has already been verified by the huge jumps that Google saw in iPhone
searches. Likewise, some of our sample sites already reflect this paradigm, such as
Facebook, which removed most of the information from their iPhone login page.

■
Location awareness can’t be accessed from a web app.
■
Orientation awareness is a topic we covered in chapter 4, when looking at the
WebKit.
■
Input was also covered in chapter 4. If you want, you can continue to use the
WebKit’s orientation and gesture support as part of your iPhone-
UI web apps.
■
Output is the last of the design elements. One of the cool things about the
iPhone’s Safari output is that it scales, but as we’ve already suggested, that’s
something you might want to omit in an iPhone-
UI web app.
By now you might have some great ideas for how to turn your website into an iPhone web
app, but the idea of coding everything to look like and work like the iPhone can seem
daunting. Unlike our discussions of Canvas and the WebKit, there isn’t an Apple library
that we can point you to (though one is in process, from what we hear). But if you don’t
mind using third-party libraries, you can use a free software package called i
UI.
5.2 Getting ready for iUI
iUI is a library of JavaScript and CSS that is intended to mimic the look and feel of the
iPhone in web pages. In other words, it’s precisely what you need to make an iPhone-
UI web app of the sort that we’ve been describing. Software engineer Joe Hewitt, the
author of i
UI, said the following about it in his initial blog posting on the topic:
First and foremost, i
UI is not meant as a “JavaScript library.” Its goal is to turn
ordinary standards-based
HTML into a polished, usable interface that meets the

UI’s license is a permissive new BSD license that places few restrictions on what
you can do with the software.
Barring problems, you should now be ready to start programming a web app in
i
UI. But we’ll offer one last disclaimer before we talk about that: author Christopher
Allen is currently one of the three owners of i
UI, along with Joe Hewitt and Sean Gilli-
gan. Naturally, this makes us biased toward i
UI. But we wouldn’t be supporting it if we
didn’t think it was a superb product for creating iPhone-specific web pages. We’re
pretty sure you’ll agree too.
5.3 Developing with iUI
Once you’ve got iUI installed, you can include it in your code by referencing iUI’s
JavaScript and
CSS files. Listing 5.1 shows a typical iUI header, placed in the
<head>
section of your HTML file. This is the beginning of a color-selector application that
we’re going to develop over the next couple of examples; it will allow you to look up
your favorite shades of red (and other colors if you want to extend the example on
your own).
<meta name="viewport" content="width=device-width; initial-scale=1.0;
maximum-scale=1.0; user-scalable=0;">
<style type="text/css" media="screen">@import "iui/iui.css";</style>
<script type="application/x-javascript" src="iui/iui.js"></script>
Note that besides the standard include statements for the style and the script, you’ll
also set a viewport, following the suggestions we offered earlier for iPhone-
UI web
apps. This viewport is set to the iPhone screen width and also keeps users from scaling
the window.
From here you can start building an application using the i

B
. Most will also have a
backButton
line
C
, unless your app contains no subsidiary pages. The
button
line
D
—which is what
we called an action button in section 5.1—is the most optional of the three, and will only
appear when you have some action that you want a user to be able to take. A few of these
elements bear additional discussion.
First, notice that the
pageTitle
and
backButton
lines do not contain any content.
This is because i
UI’s Javascript automatically fills them. The
pageTitle
will be filled
with the title of the element that’s currently selected. The
backButton
will be filled by
the title of the previous element when you move forward a page (and won’t be used
until then).
Table 5.2 iUI makes about a dozen classes available for you to use in creating iPhone-like web pages.
iUI class Element Summary
button <a>

Second, be aware the
backButton
allows access to a whole stack of pages—just like
on the iPhone itself. No matter how deep you are in your iUI page stack, you’ll always
be able to get all the way back to your first page.
Third, note that we said “elements” when referring to the individual parts of an i
UI
screen. Although an iUI web app will look like several pages on an iPhone, it can all be
in one file on your web server (using the standard model of views that we’ve already
highlighted). Individual forms, lists, and
<div>
s are each named. iUI then redraws the
page—using simple animations that model the iPhone—whenever a user moves to a
new, named element.
5.3.2 iUI lists
Once you’ve written your (relatively standard)
toolbar, you then need to prepare your default
element. It’s what will get pulled up on the screen
the first time a user visits your i
UI page. To create
your default element, you must write a
<div>
,
form, list, or other element, then give it the
selected="true"
attribute.
This selected element is the only one that will
appear when your page is first drawn. All the other
elements on your page should be available via
links from your default element; they’ll only

C
D
Figure 5.2 A list-based paradigm is
easy to program in iUI, using just the
<li> elements.
88 CHAPTER 5 Using iUI for web apps
The rest of the lines in this element are list items holding links. Although you’ll
frequently be linking to other elements that are part of the same iUI page, as you do
in your first three list items
C
, you’re creating a fully functional web page and can
thus link to anywhere on the web.
Your penultimate anchor line
D
shows an offsite link. The
target="_self"
attri-
bute is required when you’re linking to a complete (usually off-site)
HTML page. This
is because iUI assumes that external links usually connect to iUI-style page fragments
containing only elements. It therefore tries to load them via Ajax if you don’t tell it
otherwise. We’ll explain more about how you might want to use these page fragments
and Ajax when we get to i
UI tips and tricks, later in this chapter, but for now just be
aware that you need to set the
target
attribute to _
self
for normal links.
Once you’ve written your default element, you

grated into web pages, but it’s more a set of techniques than an actual language. It
combines JavaScript and XML (as you’d expect from the name) with DOM.
The concept behind Ajax is that the web browser exchanges small amounts of data
with the web server without redrawing complete pages. Typically, a form sends some
data to the server, the server processes it, and then it sends back a command for
the browser to update some small part of a page. Ajax is great for data entry where
you want to indicate that the server has accepted the data. As it happens, it’s really
good for low-bandwidth services too, like EDGE.
Figure 5.3 Groups help programs to
organize lists into logical units.
89Developing with iUI
<ul id="red" title="Red Shades">
<li class="group">Light Reds
<li><font color="#ff0000"><b>Computer Red (#ff0000)</b></font>
<li><font color="#ED1C24"><b>Pigment Red (#ED1C24)</b></font>
<li><font color="#E0115F"><b>Ruby Red (#E0115F)</b></font>
<li class="group">Dark Reds
<li><font color="#DC143C"><b>Crimson (#DC143C)</b></font>
<li><font color="#800000"><b>Maroon (#800000)</b></font>
</ul>
We could easily extend this example to also show pages for green and blue color selec-
tions, but doing so wouldn’t add anything to what you’ve already learned. Instead,
we’re going to jump to the next major element
of our color selector example: the searchForm.
5.3.3 iUI dialogs
The iPhone already has a standard way to display
web searches. You can see it when you click the
magnifying glass in mobile Safari. A search dia-
log pops up toward the top of the screen, com-
plete with a cancel button in the chrome.

B
C
D
E
F
Figure 5.4 A dialog allows users
to conduct searches.
90 CHAPTER 5 Using iUI for web apps
Inside the
dialog
class, the order of the contents is important. You must have a
<fieldset>

B
, which is used to logically group form elements together and then
draw a box around them. Then you must have a level one header
C
, which will
appear amid the chrome at the top. Omitting either of these will cause your dialog to
display incorrectly.
The buttons
D
can be set in several configurations. Here you display both
cancel and search buttons. This isn’t quite how the iPhone does things by default,
but it provides a more complete UI, thus trading off usability for conformity. If you
prefer to stick with the iPhone standard, replace the pair of buttons with a single
Cancel line:
<a class="button" type="cancel">Cancel</a>
Note that this example also introduces how to apply the iUI button classes. The button
class by itself always displays a right-justified gray button, but by applying multiple

elements rather than complete pages.
This is the case with iUI-based searches. Your search result pages should not draw
full pages, nor should they forward you to full pages. Instead, they should output an
individual element, just like those elements that you’ve been writing to model other
i
UI subpages.
Listing 5.6 shows what search.php might output after a search for “Maroon”.
<ul id="search" title="Maroon">
<li><font color="#800000"><b>Maroon (#800000)</b></font>
</ul>
Listing 5.6 A search page fragment
91Developing with iUI
How the back end of your search works is, of course, entirely up to you. All that mat-
ters is that the output supplies a fragment, because that’s what iUI’s Ajax engine
expects to see.
5.3.5 iUI panels and rows
That leaves us with just one missing item from our iUI color selector example: the set-
tings page. We’ll be laying this out with our remaining iUI classes for this example:
panel
and
row
(see

listing 5.7). These classes are meant to mimic the Settings page
found on your iPhone, with its rows of options that you can change.
<div id="settings" title="Settings" class="panel">
<fieldset>
<div class="row">
<label>Color in Names</label>
<div class="toggle" onclick="return;">

THE ROW
Within a panel, information is organized into rows
D
.
Again we see similarity to the layout of the dialog,
because a
<label>
tag
E
designates data that is
pushed to the left of the element. Here, you also have
the option of placing data to the right. In the case of
this example, you’re placing a special toggle class
F
in
that location. The results are shown in figure 5.5.
You’ll most often use the
panel
and
row
classes in
i
UI just as you do here, for toggles. Note that the
row
class can be used elsewhere if you want to mimic the
left/right row-based organization of data in other
places. The downside is that rows are set up to contain
Listing 5.7 Panels, rows, and toggles forming another user input model
B
C

The
toggle
class is managed by an
onclick
JavaScript event handler. The example
includes
return;
, but you’ll want to instead call up something that makes an appro-
priate change based on the change in settings.
Usually a
toggle
starts in the off position, but if you instead want to set it on by
default, you just need to set the toggled attribute in your toggle
<div>
:
<div class="toggle" onclick="return;" toggled="true">
If you’ve been following along on your home computer, by this point you should have
a sparsely functional color selector with examples of all the major i
UI classes. Having
finished designing an i
UI color selector, we’ve also finished our overview of most of
the major classes for i
UI. There’s still one set of classes that could use a bit of addi-
tional clarification: the buttons.
5.3.6 iUI buttons
There are a total of five different classes for buttons. We’ve already seen them in use
both in the
toolbar
and the
dialog

button leftButton blueButton
Blue button to the left
93Developing with iUI
You should be careful about moving the colors and locations of buttons too far from
the iPhone standards. Given those constraints, though, the small button classes pro-
vide considerable ability to easily create attractive iPhone-like graphics.
The large buttons,
grayButton
and
whiteButton
, work differently from the small
buttons. They’re each used singularly, and each will entirely fill the width of an
iPhone screen. You can embed them by adding a class to an
<a>
tag, just as with the
other buttons:
<a class="grayButton" href="#confirm">I'm Sure!</a>
You should use these buttons when you want to make a notable impact on your docu-
ment somewhere other than your toolbar or dialog box. The large buttons are similar
in look and feel to the confirmation buttons that you’ll often see pop up on an
iPhone, so your users should already be familiar with their usage.
Having completed our look at i
UI classes, there’s only one other thing we want to
look at in our overview of IUI: a few special attributes that are used by the JavaScript
libraries.
5.3.7 iUI attributes
iUI recognizes a handful of special attributes that can be applied to various tags. These
each tend to be related to one of the classes that we’ve already met (see table 5.4).
You’ve already seen the majority of these attributes. The
cancel

orient="landscape"
(none)
94 CHAPTER 5 Using iUI for web apps
to the previous page. If we didn’t want the settings page in our color selector app to
have a back button, we’d replace the first line of that element with the following:
<div id="settings" title="Settings" class="panel" hideBackButton="true">
You probably won’t want to do this much (if ever) because it breaks the standard
iPhone navigation model.
Finally,
orient
is a
<body>
attribute that iUI sets for you. It can be used to tell
whether the iPhone is in portrait or landscape mode at any time without having to
watch for orientation change events. Of course, it’s probably just as easy to use the
WebKit’s
orientation
property, making this attribute somewhat redundant.
Having thoroughly described how i
UI works, we’re now going to briefly revisit how
i
UI page design is done. What we’ve discussed thus far assumes a simplistic data model
for your website, which probably won’t be the case, so let’s take a step back and see
how i
UI might be integrated in a more realistic manner.
5.4 Creating an iUI back end
With our color selector (with the exception of that search.php page), we assumed that
you were working with static data. If you have unchanging data and you’re just looking
for a handy way to access it on the iPhone, then our suggestions thus far will work fine.
And there are plenty of handy applications that you could write for the iPhone using

C
D
E
95Other iUI tips and tricks
?>
<li class="group">Entered <? echo $recent[$i][entrydate]; ?>
<?
}
$lastdate = $recent[$i][entrydate];
?>
<li>
<a href="display-entry.phtml?mainid=<?
echo $recent[$i][mainid]; ?>" target="_self"><?
echo $recent[$i][title]; ?></a>
<i><? echo $recent[$i][authors]; ?></i>
<?
}
?>
</ul>
</body>
[XHTML?]
You will find nothing here surprising. You’ve got a standard toolbar
B
, which you fol-
low up with a default element
C
, once again using our old favorite, the unsorted list.
The main body of this page is taken up by linked list items
F
. It’s interesting to note

intensive look at Ajax and how it can help you organize your code and your listings; a
simple way to include slightly smaller i
UI libraries; and some methods to change the
standard look and feel of iUI. We’ll kick off with that code organization.
5.5.1 Organizing your code
You’ve already seen that iUI changes the way web pages are written by representing
many subpages as elements in a single
HTML file. But as files gets larger (and thus
F
G
96 CHAPTER 5 Using iUI for web apps
more unwieldy over EDGE), you have to decide when you should create a new page in
iUI rather than a new element. It turns out that there are three ways organize your iUI
pages, as summarized in table 5.5.
Each of the three methods shown in table 5.5 should be used in different circumstances.
A single file is the standard process that we’ve been using so far. It keeps things
nicely organized on your side of things. It also preserves i
UI’s history stack, as we’ve
briefly mentioned before.
Multiple fragments is an alternative that you can use if your file is getting too large
and thus causing problems over
EDGE. You need to start out with a single main file, as
usual, but you can then put individual elements in subpages, and call them
up through a normal
URL. The trick is that the subpage must be a fragment, just like
the fragment that we created for our search results. It can’t contain headers or any
other information.
For example, in our color selector we might put each of our colors on a subpage,
like red.html, green.html, and blue.html. Those subpages would then contain only
the

Multiple files For larger multipurpose applications
Table 5.5 You can keep elements on
the same page, maintain fragmentary
subpages, or write totally different
pages, depending on the app.
97Other iUI tips and tricks
iPhone’s home page. This has the advantage of being more attractive, but you’ll need
to create special navigation to get back to it.
5.5.2 Improving data listings
iUI also uses Ajax in one other place, solving another common iPhone UI problem. As
we mentioned a few times, when you’re listing data on an iPhone you should cut it
down into bite-sized chunks to be easily loaded over the wireless network. We saw this
demonstrated in the iPhone’s mail program and in our own recent books example.
There’s an even fancier way to create these partial listings in i
UI. If you use the
mail program on the iPhone, you’ll note that its Load 25 More Messages button
doesn’t load a new web page (as would be standard for a desktop web page), but
instead shows 25 additional messages at the bottom of the same page. This is the same
methodology used for YouTube searches, and can generally be considered yet another
bit of iPhone-specific chrome.
You can mimic this easily thanks to i
UI’s next bit of Ajax magic. You just use
target="_replace"
in your “more”
<a>
link. Returning once more to our color selec-
tor example, what if we had too many reds for a single page? All we’d need to do is
include the following line at the bottom of our page:
<li><a href="darkred.html" target="_replace">See More Reds</a>
The darkred.html file would be another page fragment—just like those we’ve already

Having finished with Ajax, we can now look at one final feature hidden inside iUI:
compression.
5.5.3 Compressing iUI
Do you need your pages to be more efficient because everyone is accessing them via
EDGE? If so, you can use specially compressed versions of the iUI CSS and JavaScript
files that are packaged with i
UI. Just include them under the compressed names:
<style type="text/css" media="screen">@import "iui/iuix.css";</style>
<script type="application/x-javascript" Don’t expect the savings from compression to be huge. As of the current version of
i
UI at the time of this writing, the CSS file decreases from 8k to 6k and the JavaScript
file decreases from 10k to 6k. But every byte can help on an
EDGE connection, and the
only real cost is readability of the files.
5.5.4 Selecting a different look
In the last few sections we’ve taken advantage of iUI’s ability to look and work exactly
like an iPhone. We’re now going to contradict ourselves by addressing the following
problem: what if you have a standard look and feel for your website that you want to
replicate with i
UI, rather than sticking with the staid and normal iPhone look?
Because i
UI is just a library of CSS and JavaScript, changing its look and feel is
not only possible, but it’s also easy. At the time of this writing, an i
UI web page at
http://www.ampersandsoftware.com/
NHLapp/ showed how this could be done by
introducing some bright red and blue colors into its style. All you need to do is to cre-
ate additional styles for your pages.
The simplest way to do this is to embed a style statement in the particular tag that
you want to change. For example, if you wanted to change the

to upgrade i
UI in the future.
As for why in the world you’d want your panel box to be red, we’ll leave that as an
exercise for the reader.
5.6 Integrating iUI with other libraries
Before we finish up with iUI entirely, let’s see how it can integrate with other libraries,
including both the WebKit that was the subject of the previous chapter and jQuery,
another library package that we haven’t discussed yet.
5.6.1 Using jQuery with iUI
The iPhone is a device that has elicited a lot of excitement in the user community, and
i
UI isn’t the only freely available library that’s come about as a result. In early 2008
Jonathan Neal released a jQuery library for the iPhone. You can download it from
http://plugins.jquery.com/project/iphone.
jQuery is a lightweight JavaScript librar y that’s intended to make JavaScript and
DOM
manipulation simpler and more intuitive. You can learn more by checking out jQuery in
Action by Bear Bibeault and Yehuda Katz (Manning, 2008). The iPhone extension adds
a few common iPhone-related manipulations to jQuery. You can access them just by
including the appropriate JavaScript scripts (jquery.iphone.js, jquery.js) or if you prefer
the appropriate compressed scripts (jquery.iphone.min.js, jquery.min.js).
Once you’ve done that, you can use a handful of new functions. We’re not going to
go in-depth into jQuery for the iPhone as we did with i
UI. Table 5.7 summarizes the
contents of the package, and you can find more complete examples in jQuery’s
iPhone documentation.
iPhone’s jQuery is compatible with i
UI; web apps have already been created that use
both of them. But there is some overlap. In particular, the
hideURLbar

tion, transform, or animation as part of a web page, i
UI won’t get in your way. In fact,
we think some of elements of the advanced WebKit will work great with iUI. For exam-
ple, you could use a client-side database to create dynamic i
UI-based web pages, using
methods similar to the PHP dynamic web page that we described earlier.
Second, it’s unnecessary because iUI tends to support a specific type of web design:
the list-based data paradigm that we saw earlier was central to much iPhone develop-
ment. If you’re following that paradigm, you probably won’t need the bells and whis-
tles of the WebKit; if you’re not, then you probably won’t need i
UI. There are
situations when you might combine the two, such as creating a list-based application
that had fancy end pages that could make use of WebKit features, but we expect those
will be the minority of i
UI designs.
Nonetheless, there’s little technical reason not to combine the two libraries if the
opportunity arises to do something cool.
Lessons for SDK developers
Although iUI is a web-only library, it provides some of the best insights into SDK de-
velopment, primarily because Joe Hewitt did such a careful job of not only mimicking
the look and feel of the iPhone’s UI, but also its functionality.
The discussions that lead off the chapter, centering on the iPhone UI and the
iPhone’s architectural paradigms, provide a great overview for your own SDK program-
ming. A lot of the bells and whistles, such as the chrome and the way data is output,
will already be laid out for you with the SDK. Thinking about the data-centric focus of
iPhone users and the ways in which the six unique iPhone design elements will influ-
ence your program design remain important.
Finally, iUI itself really shows many of the features that SDK programs should have
as well. Short data bursts, expanding lists, and special search and setting forms will
all be part of a well-designed SDK programming experience. We’ll even return to the

freely developed or being developed for sale with fancy graphical interfaces. We’re
not going to try and cover all of these here, other than to say there will probably be
more stuff out there by the time this book sees print, but that we expect iUI to be the
leader in the area for at least a while to come.
We will, however, make a special mention of Apple’s Dashcode, which is a graphical
development platform that can be used to lay out many simple iPhone-UI web apps.
If you don’t need anything other than JavaScript, CSS, and HTML in your web app,
you’ll probably want to use Dashcode instead of iUI; it’s discussed in chapter 7. But
for all those more complex programs that require PHP, Ruby on Rails, or another dy-
namic language, we think that iUI is a great foundation.