Andrew Marconi » Programming

Getting Started with iOS Web Applications: Block Best Practices

Andrew Marconi — Fri, 10 Sep 2010 13:56:34 +0000

Being relatively new to building Web applications for iPhone, iPad and other Webkit/iOS browsers, I’ve been spending more and more time searching through the Apple Developer Safari Reference Library.

It’s a very complete resource, but so far, I’ve found it to be mildly frustrating for the beginner. For instance, constructing a basic block requires referencing about 3-5 different pages in the Apple documentation (that don’t link together in a meaningful way), as well as a variety of third-party developers’ sites.

So, I’ll step through what I typically do, explaining it line by line. Hopefully it will help someone who might otherwise go through the same problems I experienced when I was first getting started with Web app development for iOS mobiles and Webkit. I’m not saying that this is the 100% best way to do it; it is the way that seems to work best for me. If you have any suggestions to improve it (or refute some of my thinking), please feel free to comment on this post or contact me directly.

What Character Set?

First up, the http-equiv meta tag. I always encode my pages for UTF-8 because I typically deal with users around the world who have Web browsers that may render local characters incorrectly. UTF-8 allows for a large character set. Learn more about UTF-8 at UTF8.com.

This Really is a Safari Web App

Setting the apple-mobile-web-app-capable meta tag to yes means that the page can be added as a full-screen app, and run “outside” of Safari. I say outside in quotes, because really it is still running using the Webkit rendering engine, but the user isn’t presented with the URL bar, or other chrome that, while useful when browsing the Web, only gets in the way when he or she is using your Web app.

The Status Bar

Next, we define how the top bar looks (the bit that has the carrier, time and other system-wide icons). By default, this value is default, meaning, a grey chrome finish and completely opaque. Lately, I’ve been going with setting this to black which is how it sounds. The other option available is translucent-black. This lets your app “bleed through,” which sounds like a good idea, and can look nice if you take this into consideration when you build your mobile Web app… but in practice can end up looking a little sloppy in my opinion.

Viewport vs. Window

The viewport is one of the tricker concepts to understand. By default, iOS Safari renders content in a window with a 1024 pixel width. It then scales things down using it’s own logic to fit what it can on your screen (the viewport). The basic idea is that the viewport is inside of the window. On the desktop version of Safari, the two are set to the exact same size.

What I’ve found to work best for the iOS devices is the following. Basically, I’m saying, set the scale to 1:1 (make the viewport the same size as the window); the width should be the device’s width (this is a constant that changes based on rotation of the device — better to set it to this than to give a static width); and don’t let the user scale anything (again, because I’ve designed this as a Web app, specifically for iOS, there should be no need to scale).

Auto-Detect Phone Numbers

Many of the Web apps that I work with extend digital asset management systems, and so they include things like identification numbers for TV commercials, print job numbers, etc.; rarely do I use telephone numbers in my Web apps. So, I turn off automatic detection of telephone numbers to prevent bad links. Your Web app may be different, and you might want this behavior… if so, then by all means, skip over this line.

For me, I start with no phone number detection, and then flag items manually that should be sent to the phone (for instance, a technical support phone number in the footer). For this type of scenario, I’ll use a tag like Support by Phone. Using “tel:” as the first part of the href let’s Safari know that the link is be sent to the phone app rather than as a Web link.

Default Home Screen Icon

By default when you click the “+” icon in Safari to add a Web app to your home page, Safari will take a screenshot and use it as the icon. Generally, this isn’t very pretty. You can supply a more user-friendly design by uploading a 57×57 pixel PNG (not GIF or JPG), and pointing apple-touch-icon to it. Don’t include any rounded corners, or the glass/glow art — Safari takes care of this for you. There is an alternate meta tag that allows you to supply a pre-composed image instead, but generally, I don’t go that route.

Startup Image

Similarly, you can provide a “startup image” that displays before your Web app runs (actually, it displays while the device compares its cached version of your Web app to the live version on your server, and if there are differences it downloads them). This should be a 320×460 pixels in size, again in PNG format. Remember, this will only appear when your Web app is running full-screen (i.e., when you click on it from your device’s home screen); it doesn’t display when browsing to it in Safari.

Localized CSS

Lastly, I link to my stylesheet that defines styles specific to the Web app. If you’ve used any third-party libraries to help with layout, they would appear before this link so that you can override any styles locally. Some examples of these libraries are iUI and iWebKit.

Does Order Matter?

I don’t really know. Typically, I organize my block by placing any tags first, then tags, and then the tag. I really don’t think that this matters much, but I’m a fairly visual person, and having things grouped this way makes it easier for me to browse my source code.</p> <h3>In Summary</h3> <p>In summary, here is the completed <head> block:</p> <div style="background: #ebebeb;"><code><head><br /> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><br /> <meta name="apple-mobile-web-app-capable" content="yes" /><br /> <meta name="apple-mobile-web-app-status-bar-style" content="black" /><br /> <meta name="viewport"<br /> content="initial-scale=1.0, width=device-width, user-scalable=no" /><br /> <meta name="format-detection" content="telephone=no" /><br /> <link rel="apple-touch-icon" href="/lib/media/apple/icon.png" /><br /> <link rel="apple-touch-startup-image" href="/lib/media/apple/splash.png" /><br /> <link rel="stylesheet" type="text/css" href="/lib/css/ios-common.css" /><br /> <title>Name of Your App Here

Enabling Flash Video (FLV) Playback on Windows IIS

Andrew Marconi — Wed, 10 Jun 2009 14:11:21 +0000

Here’s another “gotcha” courtesy of Microsoft: by default, IIS doesn’t include a MIME type for Flash Video (FLV) files, resulting in a 404 Not Found error whenever you try to access the file. One would think that they would deliver a 401 Unauthorized error, but hey… what do I know?

Right click on either the individual site or the full server, and then click “Properties.”

1. Click on the “HTTP Headers” tab.
2. Choose “File Types” and click “New Type.”
3. Add “.flv” for the associated extension, and “video/x-flv” as the content-type.
4. Click OK to save the addition, and close out.

Like everything with IIS, you may need to restart the service to see the change.

This is just one more reason to use Apache on Linux.

Troubleshooting jQuery in WordPress Themes

Andrew Marconi — Fri, 29 May 2009 04:29:03 +0000

Here’s another “oh yeah, I always forget about that” geek item.

I spent a few hours today going nuts trying to figure out why the jQuery Cycle plug-in wasn’t working in a new theme I’m working on. The code ran great outside of WordPress, but the minute I placed it inside the theme, it broke.

Then I realized: when using jQuery in WordPress you always have to remember to explicitly call it by name rather than use the handy-dandy $(“#identifier”) short-cut that every example and demo online uses. The long-winded reasoning (as I discovered thanks to Techxplorer’s blog entry) is that the bundled version of jQuery built into WordPress since version 2.2 is initialized with jQuery.noConflict. The upside is that this keeps the jQuery library from crashing into other bundled libraries (like Prototype). The bad news is that it breaks support for the $ shortcut.

I came across an simple solution via Chris Mellon:

Instead, for interoperability, be sure to use jQuery() instead, which should accomplish the same thing.

A bad example:
var username = $('#username').val();
If Prototype were to be loaded on the page this snippet of JS is running on, it would throw an error, since it uses a different pattern for selecting DOM elements.

A good example:
var username = jQuery('#username').val();
This line should work on any page, regardless of library conflicts. It’s a couple extra characters to type, but in the end it’s really for the best – you get portability, and it’s more self-explanatory which library is being used when you go back to look at this code in 6 months.

WordPress Theme Check List/Cheat Sheet

Andrew Marconi — Thu, 14 May 2009 16:06:12 +0000

Stefan Vervoort over at WPToy.com has published a great cheat sheet for developing WordPress themes. It’s available in PDF format, so as he suggests, if you build themes print it out and put it on your wall. When I’m building a WordPress theme, I always forget something along the line (when I go into “programmer mode” I get a little lazy sometimes, alright?) — this makes sure I cover off on all the elements.

Back in 2008, I announced the WordPress Theme Development Checklist on DivitoDesign. The Checklist with many small tips, code snippets and checkpoints you usually forget about was a success.

Today it is time to release an improved official PDF version of the Checklist for the WordPress crowd. This PDF version is clean and easy to print, which makes it an excellent checklist when you are developing your new WordPress Theme.

Great work, Stefan!

[Via WPToy.com]

How to Normalize URLs & Keep Google Happy

Andrew Marconi — Wed, 06 May 2009 19:47:53 +0000

This is something I always (1) forget to do, and (2) forget how to do. Simply add this code (modified for your domain name, of course) to your .htaccess file.

This is important to implement for your search engine ranking. Google, for example, thinks www.domain.com is a different site from domain.com, and this can seriously impact where you rank in Google. There are other ways of doing this, but the below is the only one that doesn’t spit back a 500 error on my server, for some reason.

RewriteEngine On RewriteCond %{HTTP_HOST} ^www.domain.com$ [NC] RewriteRule ^(.*)$ http://domain.com/$1 [R=301,L]

If you want to force ‘www’ on the front end of your URL, switch it up with:

RewriteEngine On RewriteCond %{HTTP_HOST} ^domain.com$ [NC] RewriteRule ^(.*)$ http://www.domain.com/$1 [R=301,L]

[Via DZone Snippets]