Getting Started

First, create a new View-based application. Give it a memorable name like “TwitterXML.”

Now that you have a clean slate to work off, let’s rename some classes. I find Xcode’s default naming scheme a bit silly, with the way it prepends the project name to each file. I think the Application Delegate should be called, simply, AppDelegate.m instead of the needlessly long TwitterXMLAppDelegate.m. However, you can’t just rename the file to whatever your preference is, as that would break things.

You can rename a class project-wide, file and all, by using the Refactoring tool. You can call it up by right-clicking on the class name in the implementation file and choosing “Refactoring” from the resulting menu.

This renaming business is entirely optional as far as this tutorial goes, but it’s worth know how to do. Imagine if you made a typo in a class name and didn’t realize it until after you had already referenced it in a few places. It’s nice to have an automated fix.

Setting Up the Header File

Most of our code is going to go in the View controller, named TweetViewController in my case. Switch to the corresponding .h file and we can start setting up properties and whatnot.

First, we need to implement the NSXMLParserDelegate protocol so our class can respond to NSXMLParser delegate methods. This is easily done by adding NSXMLParserDelegate to the @interface line, like so:

@interface TweetViewController : UIViewController <NSXMLParserDelegate> {

Now we need to declare some variables and other objects in the interface block. We need a string to hold the name of the Twitter user whose profile we will be accessing, a mutable array to hold the statuses we’ve pulled from the parser and a few that are used to hold data temporarily during the parsing process. Also, we need a few IBOutlets so we can update the View once we finish reading the XML data.

@interface TweetViewController : UIViewController <NSXMLParserDelegate> {
NSString *twitterUser;
NSMutableArray *statuses;
NSString *currentElement;
NSMutableDictionary *currentElementData;
NSMutableString *currentElementString;
IBOutlet UIImageView *backgroundImage;
IBOutlet UILabel *tweetLabel;
IBOutlet UIImageView *avatar;
}

Of course, we need to make these objects into properties. This means adding a few property declarations after the interface block ends.

@property (nonatomic, retain) NSString *twitterUser;
@property (nonatomic, retain) NSMutableArray *statuses;
@property (nonatomic, retain) NSString *currentElement;
@property (nonatomic, retain) NSMutableDictionary *currentElementData;
@property (nonatomic, retain) NSMutableString *currentElementString;
@property (nonatomic, retain) UIImageView *backgroundImage;
@property (nonatomic, retain) UILabel *tweetLabel;
@property (nonatomic, retain) UIImageView *avatar;

And then you need to synthesize them in the .m file by adding the following line right after the @implementation line:

@synthesize twitterUser, statuses, currentElement, currentElementData, currentElementString, backgroundImage, tweetLabel, avatar;

Now that that’s out of the way, we can get to the interesting part.

Setting Up the Parser

The first method in the View controller is <em>viewDidLoad</em>, which fires as soon as the View as loaded. (Subtle, isn’t it?) We will be putting our initialization stuff in there. Basically, we just need to ready our properties, set the Twitter username and start the parser.

- (void)viewDidLoad {
[super viewDidLoad];
statuses = [[NSMutableArray alloc] init];
currentElement = [[NSString alloc] init];
currentElementData = [[NSMutableDictionary alloc] init];
currentElementString = [[NSMutableString alloc] init];
twitterUser = [NSString stringWithString:@"collis"];
[self parseXMLForUser:twitterUser];
}

After the first arrays and dictionaries are initialized, the twitterUser string is set to the username of the Twitter account we want the app to pull the latest statuses from. I’m using Collis, one of the co-founders of Envato, as an example. You could put any user you want there, so long as they have a cool-looking background on their profile!

The last line calls the parseXMLForUser: method and passes the twitterUser string along with it. We will work on that part next.

The parseXMLForUser: method is responsible for setting up the parser, as well as building the Twitter API URL.

- (void)parseXMLForUser:(NSString *)user {

//Build the Twitter API URL by combining the user with the rest of the URL
NSString *urlString = [NSString stringWithFormat:@"http://twitter.com/statuses/user_timeline/%@.xml?count=3", user];
NSURL *url = [NSURL URLWithString:urlString];

//Create an instance of NSXMLParser and download the XML data from the URL
NSXMLParser *parser = [[NSXMLParser alloc] initWithContentsOfURL:url];

//Set this class as its own delegate so we can process NSXMLParser callbacks
[parser setDelegate:self];

//Disable namespace support and other things we don't really need
[parser setShouldProcessNamespaces:NO];
[parser setShouldReportNamespacePrefixes:NO];
[parser setShouldResolveExternalEntities:NO];

[parser parse]; //Go go gadget XML parser...

[parser release];

}

The first part of the method should look familiar to anyone who has worked with C or Java before. It takes our user argument (which contains the text of twitterUser) and splices it into the URL string, just before the .xml part. Cocoa expects URLs to be of the NSURL object type, we create a new one of those and pass it urlString.

After that is done, we create a new instance of the NSXMLParser class and nickname it “parser.” We also pass it the new URL object, which it will use to download the contents it finds there at runtime. Next we set the parser’s delegate to self, or the current class. The next three lines turn off some features we don’t really need. Finally, we kick the parser into action and leave a [parser release] command to clean up after it’s done.

That was simple, wasn’t it? Sadly, that was only the beginning. In order for the parser to, well, parse we still need to implement the delegate methods for NSXMLParser. And we need to make a spiffy UI.

Building the Parser

NSXMLParser is what is called an event-based parser. This means it loops around, searching a document for anything that looks like an XML tag. When it finds one, it raises an event. Basically it says “I found an opening tag named ‘something'” and leaves you to deal with it. The parser does the same thing with ending tags and the text between them. We have to implement delegate methods to handle these events and save the data they find.

Let’s start with a couple of simple ones.

- (void)parserDidStartDocument:(NSXMLParser *)parser {
NSLog(@"The XML document is now being parsed.");
}

- (void)parser:(NSXMLParser *)parser parseErrorOccurred:(NSError *)parseError {
NSLog(@"Parse error: %d", [parseError code]);
}

The first method fires when NSXMLParser starts to parse the document. For this application, there isn’t really anything that we need to do at that point. Putting an NSLog there is great for debugging, though. (If your app is crashing, it’s helpful to know whether it’s getting to that step or not.) I’m sure you can guess what the parseErrorOccurred method does. (It logs an error code if the XML document is malformed or if, for some other reason, the parser could not process it.)

Moving on, we have a method that is called when the parser finds an opening XML tag.

- (void)parser:(NSXMLParser *)parser didStartElement:(NSString *)elementName namespaceURI:(NSString *)namespaceURI qualifiedName:(NSString *)qName attributes:(NSDictionary *)attributeDict {

//Store the name of the element currently being parsed.
currentElement = [elementName copy];

//Create an empty mutable string to hold the contents of elements
currentElementString = [NSMutableString stringWithString:@""];

//Empty the dictionary if we're parsing a new status element
if ([elementName isEqualToString:@"status"]) {
[currentElementData removeAllObjects];
}

}

This one is a bit more complicated. When it’s called, its arguments are populated with information that the parser found out about the element currently being parsed. It’s name is what we care about, primarily. Using the properties we created earlier, the method keeps track of the element currently being parsed (we need to know its name in other methods) and whatever is inside the element (between the opening and closing tag). The conditional statement at the end empties our dictionary every time the parser moves on to a new <status> element, as we will have already copied its contents to the statuses array.

The next delegate method takes any characters found inside an XML element and stores it in the currentElementString property for later.

- (void)parser:(NSXMLParser *)parser foundCharacters:(NSString *)string {
//Take the string inside an element (e.g. <tag>string</tag>) and save it in a property
[currentElementString appendString:string];
}

And finally, the penultimate method. This one contains the real meat of the parser. It is called whenever NSXMLParser comes across a closing XML tag. And so, it serves as a good place to put most of the data-saving logic.

- (void)parser:(NSXMLParser *)parser didEndElement:(NSString *)elementName namespaceURI:(NSString *)namespaceURI qualifiedName:(NSString *)qName {

//If we've hit the </status> tag, store the data in the statuses array
if ([elementName isEqualToString:@"status"]) {
[statuses addObject:[currentElementData copy]];
}

//Trim any extra spaces and newline characters from around currentElementString
NSString *string = [currentElementString stringByTrimmingCharactersInSet:[NSCharacterSet whitespaceAndNewlineCharacterSet]];

//Store the status data in the currentElementData dictionary
if ([currentElement isEqualToString:@"created_at"]) {
[currentElementData setObject:string forKey:@"created_at"];
} else if ([currentElement isEqualToString:@"text"]) {
[currentElementData setObject:string forKey:@"text"];
} else if ([currentElement isEqualToString:@"retweeted"]) {
[currentElementData setObject:string forKey:@"retweeted"];
} else if ([currentElement isEqualToString:@"id"]) {
[currentElementData setObject:string forKey:@"id"];
} else if ([currentElement isEqualToString:@"profile_image_url"]) {
[currentElementData setObject:string forKey:@"profile_image_url"];
} else if ([currentElement isEqualToString:@"profile_background_image_url"]) {
[currentElementData setObject:string forKey:@"profile_background_image_url"];
} else if ([currentElement isEqualToString:@"profile_link_color"]) {
[currentElementData setObject:string forKey:@"profile_link_color"];
}

}

The first code chunk saves the contents of the currentElementData dictionary to the statuses array if, and only if, the ending tag being processed currently is </status>. If you remember from before, currentElementData will be emptied the next time the didStartElement method is called. Otherwise, the block will be skipped and the application will handle the tasks it needs to run for child elements of <status>.

After stripping out extraneous spaces and newline characters from either side of currentElementString, so we don’t end up with weird output, we have a rather long if/else if block. This checks whether the element being parsed is one we want to save (e.g. “text” or “profile_image_url”) and if it is, it adds it to the element data dictionary.

The code may seem a bit strange at first, but it should make more sense after you become more familiar with it.

And now, for the last delegate method. This one fires when the document has finished parsing. This is the place to launch any operations we want to be started after we have our data. As you can see below, logging the statuses array to the console and then calling a method to display that data is what we will be doing here.

- (void)parserDidEndDocument:(NSXMLParser *)parser {
//Document has been parsed. It's time to fire some new methods off!
NSLog(@"%@", statuses);
[self updateView];
}

The View

After all that code, let’s work on the interface. Double-click the TweetViewController.xib file (or whatever your View XIB is called) in the Xcode sidebar to open it in Interface Builder. Now that your screen is sufficiently cluttered with windows, you want to drag a UIImageView from the Library window into your View canvas. Make sure that it is sized to fit the whole available area.

Of course, the Image View won’t be much use to us unless we link it with the controller. Right-click on the File’s Owner icon and drag the little rubberband/wire thing from the backgroundImage Outlet over to the UIImageView and drop it. The File’s Owner overlay window should update to show the Image View as being connected to backgroundImage.

I think this app would be better if it used a horizontal orientation, don’t you? Click the little arrow icon in the upper right corner of the View canvas. Interface Builder should automagically resize the Image View inside it to still fill the View. Save the XIB file out and switch back to Xcode. Now we have to configure the application to use a landscape orientation instead of the default portrait one.

Inside your controller class there should be a method called shouldAutorotateToInterfaceOrientation. It’s commented out by default. Uncomment it and change the interfaceOrientation to UIInterfaceOrientationLandscapeLeft. It should look like this:

- (BOOL)shouldAutorotateToInterfaceOrientation:(UIInterfaceOrientation)interfaceOrientation {
return (interfaceOrientation == UIInterfaceOrientationLandscapeLeft);
}

Back in Interface Builder, drop in a new UIImageView. We won’t be hooking this one up to an IBOutlet. Instead, we will set the image to the word bubble image I made (it’s in the project file), resize the view to be the same point-width as the image (375×208) and position it neatly over the background image view. I also lowered the opacity a bit, just because I liked the effect.

Now we need a way to display the contents of the latest tweet. So drag a UILabel onto the View canvas and resize it to fit nicely over the word bubble graphic. Turn the “# Lines” setting up to five or so, set the font size to something that looks legible and change the “Line Breaks” option to “Word Wrap. Then wire it up to the tweetLabel IBOutlet, like you did with the UIImageView.

Ready to tie everything together? Switch back to Xcode and add one last method to the controller class.

- (void)updateView {

//Select the latest tweet
NSDictionary *latestTweet = [statuses objectAtIndex:0];

//Set the tweet label
[tweetLabel setText:[latestTweet objectForKey:@"text"]];

//Set the background image after downloading it.
NSString *urlString = [latestTweet objectForKey:@"profile_background_image_url"];
NSURL *url = [NSURL URLWithString:urlString];
NSData *data = [NSData dataWithContentsOfURL:url];
UIImage *background = [[UIImage alloc] initWithData:data];
[backgroundImage setImage:background];
backgroundImage.contentMode = UIViewContentModeScaleAspectFill;

}

While it looks nearly as intimidating as the NSXMLParser didEndElement delegate method, it’s actually quite a bit simpler. The first line gets the newest tweet from the statuses array, the =[tweetLabel setText:…]= line updates the UILabel with the text of the message, and the last part changes the background image behind the word bubble to be the same as the Twitter user’s profile background.

That last part needs the most explanation. Before we can display the image (which is what the setImage line does) we have to download it first. Taking the urlString, which of course is a string containing the web address where the image can be found, we convert it to a NSURL object, which is named url. We create a new NSData object and use it’s dataWithContentsOfURL method to download the image. (Cocoa requires that URLs used with it’s objects be of the NSURL class.) Next we initialize a UIImage object with the NSData object and set it as the image in the UIImageView named backgroundImage. Oh, and we set the content mode to UIViewContentModeScaleAspectFill so it’s not squished funny.

Now if you build and run the app, you should get something like this:

Before we free up our allocated memory and finish the app up, let’s add one more thing: an avatar field! Switch back to Interface Builder and add a new UIImageView. Resize it to 52×52 or so and wire it up to the “avatar” IBOutlet. Re-using the code from the background image bit, we can quickly modify it for the avatar.

//Set the avatar image after downloading it.
NSString *avatarUrlString = [latestTweet objectForKey:@"profile_image_url"];
NSURL *avatarUrl = [NSURL URLWithString:avatarUrlString];
NSData *avatarData = [NSData dataWithContentsOfURL:avatarUrl];
UIImage *avatarImage = [[UIImage alloc] initWithData:avatarData];
[avatar setImage:avatarImage];
avatar.contentMode = UIViewContentModeScaleAspectFill;

That goes in the updateView method, after everything else.

Now, before we can say the application is finished, there is one thing that needs to be done. Any memory we specifically allocated should be released. It’s not a huge deal in a single-view app, as it will be forcefully freed up on exit, but it’s a good habit to get into. (In more complicated applications, you can expect to see frequent crashes if you don’t release objects when you’re done with them.) It’s easy to do. For every object we explicitely alloc or retain, we have to release somewhere. The dealloc method is called when the application quits in this case, so we put most of our release statements there.

You can learn more about iOS memory management in this screencast.

- (void)dealloc {
[twitterUser release];
[statuses release];
[currentElement release];
[currentElementData release];
[currentElementString release];
[backgroundImage release];
[tweetLabel release];
[avatar release];
[super dealloc];
}

And we’re done!

Additional Challenge

Want to add to this sample application? Try making the following change: Use an NSTimer to cycle through the items in the statuses array and update the View accordingly. Most of the groundwork has been laid for you already.

Sahil Lavingia, creator of the Dayta app, has a quick tutorial on how to optimize your website for iPhone in 10 minutes…using only CSS.

I haven’t had a chance to try it out for myself, but it looks fairly simple.

iPhone Application Development For Dummies is a good primer on building applications for the iPhone or iPod Touch. It covers the basic theory over the first few chapters, and then moves on to building a simple View-based application. I haven’t finished the book quite yet, as I’m working my way through the tutorials as I read, but the book seems to cover all of the basics quite well. There are parts on data storage, input events, and many other things that are critical to iPhone development.

I’m finding the book to be a bit challenging, as I don’t have any real desktop programming experience, other than BASIC if that counts. I don’t think I’d recommend it to someone who doesn’t have a strong grasp of at least one programming language with a C-style syntax, such as PHP or Java. Knowledge of object-oriented programming is important, in addition to more basic skills such as dealing with variables and control structures. If you’re a total programming newbie, I would recommend reading a good introductory book first, and then moving on to iPhone Application Development for Dummies.

I’ve enjoyed what I’ve read of the book so far, and I hope that, by the time I’m done, I’ll have a good enough grasp of things to develop an idea I’ve had for awhile into an app.

<link rel="stylesheet" href="style.css" type="text/css" media="Screen" />
<link rel="stylesheet" href="mobile.css" type="text/css" media="handheld" />

By linking a stylesheet with a media of “handheld,” you tell mobile browsers to remove any of the preceding styles. You can then apply some new styles within, taking care to avoid explicitly setting widths or anything that might foul-up mobile browsers.

It’s a little bit more complicated than that in reality, but not too much so. You can find a full how-to over at Perishable Press: The 5-Minute CSS Mobile Makeover.

• Part 1: Why Go Mobile?
• Part 2: Mobilize Your Site the Easy Way
• Part 3: iPhonitizing Your Site Sans MoFuse
• Part 4: 14 iPhone-Formatted Websites
• Part 5: iPhoneMicrosites.com

I think it’s about time to bring this series to a close, with today’s post “7 Useful Mobile Site Resources.” I have to admit, the biggest reason I wrote this series was because I recently got my hands on an iPod Touch, after far too much waiting. I’ve been thinking about the topic for a long time, well before I got the i’Touch, since before I was seriously considering buying one (since the first generation Touch came out).

Now, where should you go from here? Following are a few resources that you may find useful.

1. Mobile Web Development by Nirav Mehta

Mobile Web Development is focused on non-iPhone mobile sites (I’m not sure if it even mentions the iPhone). It’s fairly current, having been published in 2008, and covers a broad array of topics in it’s 216 pages. It covers WML and WAP, XHTML MP, sending text messages (SMS) via server-side script, PayPal Mobile, Interactive Voice, and a few other things.

I haven’t tried out any of the examples or anything, but I read through the book, and it seems to be good overall. It’s an easy read, and shouldn’t take much time to get through.

2. iPod Touch or iPhone

Now, you can get by without one of these. You can use simulators to get a good idea of what a page will look like on the iPhone (I gave a couple links here), or you can borrow someone else’s for a couple minutes. But if you do a lot of work targetted at the iPhone, especially if you do it professionally, it’s a logical purchase.

The iPod Touch has come down in price, costing $229 for the 8GB model. Not something you want to impulse-buy, but if you’re looking for a new MP3 player it’s a good option.

3. MoFuse

I know, I know. I already wrote an entire post about MoFuse fo this series. It’s a great service, and one ideal for newbies and those who aren’t the Do-it-Yourself type. I’m not saying it’s only for newbies, after all some bigwig blogs (blogwigs?) like ReadWriteWeb use it, but it’s a great option for them.

MoFuse allows you to “Mobilize your blog” in about ten minutes. You simply create a free account, supply your blog’s URL, and pick a URL for your resulting mobile site. The URL will look something like you.mofuse.mobi, though you can map it to your own subdomain if you wish (m.yourdomain.com is a common convention).

Did I mention it generates an iPhone version and a WML version?

4. CiUI

My favorite JavaScript iPhone interface. CiUI was developed by CNET for their own mobile site. Their developers made it publicly available, with a little bit of documentation. A little bit of server-side scripting magic can pull posts from WordPress (or whatever you content management system may be) and display them in the AJAX-y interface. Or you could build a web app with it.

5. Apple Developer Connection

The maker of the iPhone and iPod Touch has plenty of documentation on their website for web app developers. There are tutorials, specs, and more. You need to create a free developer account to access the documents though.

6.� iPhoneMicrosites.com

iPhone Microsites is another web location I covered in this series. They have a nice collection of articles, news, and tutorials to help you build iPhone sites. They also offer their services to build such sites for you. (Their services are a little pricey for most individuals, and are more targetted at businesses, I would assume.) Their tutorial section is especially worth a look.

7.� A List Apart

ALA is one of the most popular designer sites ever. Since 1998 they’ve been in the business of informing and teaching “people who make websites.” They have a couple posts on iPhone/i’Touch web development.

• Put Your Content in My Pocket
• Put Your Content in my Pocket, Part II

Definitely worth a read. If you haven’t been to A List Apart before, you don’t know what you’re missing. I’m not a frequent reader (I just drop in now and then rather than subscribe), but I just may end up adding them to my feed reader one of these days…

Conclusion

Well, there you have it. Six days of nothing but mobile web development. Perhaps I should start a spin-off blog, iPhone-Source? (FYI, I’m kidding. I don’t have time for that… ). It would be fun though…

If you have any questions about anything from the past six posts, feel free to leave a comment. I’ll do my best to answer it.

iPhone Microsites is based entirely around the “iPhone Version” idea. They not only offer their services to build said microsites, but they also provide free tutorials and articles to teach you how to do it yourself. In addition, they provide a handy list of resources for developing web pages for the iPhone.

Their services certainly aren’t cheap, and are more in the price range for medium to large businesses than individuals, but their articles and resource lists are good. The site’s definitely worth a look at least.

Here are some good examples of iPhone-specific pages.

Amazon

CNET

Digg

Evernote

Facebook

Leaflets

GMail

Google Reader

Powerset

Remember The Milk

Retail Me Not

Ta-Da List

Twitter

Weather Underground

Bonus #15: Engage Interactive

I just found this design in time to stop the clichéd presses. It’s unique because it makes use of the iPhone’s orientation to show different content. In portrait orientation the designer’s blog is shown. Turn the device on one side to see the portfolio. Flip it over to the other horizontal position to see the about page. You have to try it to believe it.

That’s all for today. Come back tomorrow for the next installment in “The Mobile Web.”

P.S. If you liked this post, be sure to give it a quick Stumble or Float.

Option 1: Use a WordPress Plugin

If you’re blog is powered by WordPress, you’re in luck. There are a couple of plugins out there to help make your blog iPhone-friendly.

• WPtouch
• iWPhone

Both of the plugins automatically detect whether the user is coming to the site via iPhone and render the blog with their own included iPhone themes. WPtouch also allows the reader to toggle between iPhone-formatted and normal versions of the site. (iWPhone does not have this feature yet.)

Option 2: Code it Yourself

Note: I will not be providing complete sample code, and I won’t be covering every little detail of the process. The following is intended for people who have some knowledge of PHP or *insert web language here*.

First, download a CSS/JavaScript iPhone interface. There are a few out there, such as iUI, CiUI, and iPhone Interface in JavaScript. (My favorite is CiUI.)

Once you get the feel for how the interface works, start writing a back-end for it. Use your favorite scripting language to pull the content into the interface. There are two ways to go about this:

• Access the database, query the posts, then display them.
• Use SimplePie or SimpleXmlElement (in the case of PHP) to parse the RSS feed and write the items into the page.

Both options are generally easy enough if you know what you’re doing, and work well. If you want as much control over the final product as possible, this is the way to go.

Further Reading

• Web Apps DevCenter
• Prepare Your Blog for the iPhone, Easily
• Developing for the iPhone

Come back on Sunday for the next installment in The Mobile Web.

MoFuse allows you to “Mobilize your blog” in about ten minutes. You simply create a free account, supply your blog’s URL, and pick a URL for your resulting mobile site. The URL will look something like you.mofuse.mobi, though you can map it to your own subdomain if you wish (m.yourdomain.com is a common convention).

You can upload a logo, customize the color scheme, and control what goes into your mobile site. You start out with a homepage consisting of just your ten most recent posts, though you can add in more RSS feeds, static pages, and links to other sites.

MoFuse generates both an iPhone/iPod Touch version and a WML version, and sends visitors to the correct one when they access the site. Users of computers will see previews of what it will look like on their mobile device. Take a look for yourself with source.mofuse.mobi.

• iPhone Version
• WML Version

You can place a link to your MoFuse page on your site, or you can use a bit of PHP code they provide to automatically detect mobile users visiting your site and send them to MoFuse.

Mofuse is a great option for anyone looking to easily put together a mobile version of their blog (or any RSS-equipped website).

Come back tomorrow for the next post in The Mobile Web.

Today, the mobile web is split between two groups: iPhone/iPod Touch users and everybody else.

Plenty of people have phones now that can browse stripped-down WML pages, which is painful at best, impossible at worst. Then Apple came out with the iPhone and iPod Touch, finally creating a mobile device that’s actually bearable to surf the web with. (I recently bought an iPod Touch, and I have to say it’s awesome.)

iPhone and iPod Touch

As great as the iPhone/i’Touch is, it’s not perfect. It’s still much easier to navigate an iPhone-specific page than a normal page. I can read pretty much any page on the web with ease on my iPod Touch. Here I am reading a page on Pro Blog Design with the device:

Looks fairly easy to read, right? With a double-tap, you can make a portion of the page (in this case the content column) fill the screen for easy viewing. From there you can scroll in any direction by dragging your finger along the screen. Need more horizontal space? Just rotate the device, and the display will switch to landscape mode.

Easy enough, but iPhone-specific pages are even better. Here’s a screenshot of iphone.cnet.com, which I believe to be the best-made iPhone site so far:

Looks fairly similar to the iPhone’s menu system, doesn’t it? It works much like they do also. Want to see if the latest episode of the Buzz Out Loud podcast is out? Tap “Podcast Central”; the menu will slide away, being replaced with a new one. Then tap “Buzz Out Loud” and check through the results to see if there’s a new one. If there is, you can even play it right then, streaming it over the webs. (You would be advised to only try streaming web audio over WiFi, and not over 3G or EDGE phone service.)

You can find pretty much everythig CNET has to offer through the iPhone (thanks to the wonders of databases). You can even search, to easily find a specific product review; you can read current tech news; you can see what the CNET bloggers are talking about today. It works well. Why? Everything is put together here in an easily navigable list that can be scrolled through with the flick of a finger. No zooming or horizontal panning necessary.

Which is better for your site? Should you have a version of your site for the iPhone and iPod Touch, or should you just let them use your normal site? It depends on three factors:

1. Is your site’s design easy to navigate on the iPhone?
2. What type of content do you have?
3. Who is your audience?

To get a vague idea of what your site will look like on the iPhone, use a tool such as iPhoney or TestiPhone. You’ll get better results though if you try it out on an actual device (which is part of why I bought an iPod Touch). Borrow a friend’s for a couple of minutes, or walk into your local Apple store (or other consumer electronics store) and play with a demo model. (Apple stores pretty much always have open WiFi networks, so you’ll be able to test your site out there.)

For the second item on the list, just ask yourself a couple questions: Is my content time-oriented (such as news)? Would I want to check this site for new postings when I’m out and doing things?

As for your audience, think about the sort of people who use your site. (If you have no clue, run a reader survey.) Do they have any of Apple’s web-ready mobile devices? Are they g33ks? Are they the sort of people who want to keep up with online goings on no matter where they are?

In the end, the decision is up to you. Do you think it’s necessary to build an iPhone-specific version of your site? If you have ten minutes free (or a few hours, depending on how you want to go about it), go ahead and throw one together. The worst that can happen is no one will use it.

The Watered-Down Web: WML Sites

WML, or Wireless Markup Language, is a subset of XML. It’s like a stripped-down version of XHTML. There aren’t a lot of formatting options, and the syntax is very strict. A lot of phones out there can view sites formatted in WML, but it’s not a pleasant experience. I don’t happen to have a WAP device, but here’s an approximation of what it looks like:

I don’t happen to have a WML device, but simulators like this show a fairly good approximation of how they work. They don’t look all that great, you can’t have more than a couple of images, and navigation is a nightmare, relying on the phone’s keypad to scroll and activate links. You probably won’t find a device with a screen capable of showing more than ten lines of 25 characters either.

If you think your site would potentially be of value to users of WML devices, you could go ahead and put together a WML version, but keep in mind that most people with WML-capable phones don’t use them to browse the web, due to the painful navigation, slow speeds, and lack of support.

Conclusion

So, are you interested in putting together a mobile site? Stay tuned, part two of this series will be coming at you tomorrow.