Making your web site mobile friendly

How to obtain the IP address of your iPhone?

1. click on Settings
2. click on Wi-Fi
3. click on the right arrow on the network that you are using

How to transfer file from your PC to your iPhone?

• Using SFTP: On Windows, use FileZilla. You can SFTP into you iPhone using root / alpine.
• Using direct wire: Transfering files using SFTP with Wi-Fi connection can be slow

iPhone - Mobile Safari
BlackBerry -

J2ME, BREW

iPhone, Android, Windows Mobile, Blackberry

Rhomobile

The iPhone developers did a really smart thing—they designed the iPhone so that you really don’t need to do anything with your site for it to display correctly.

The first thing you’ll want to do is check your site for compatibility. After that, you can begin to make some simple changes that adapt your content to the iPhone. Finally, you may wish to make a version of your site that is targeted directly at the iPhone: a site fully optimized for the device.

Keep in mind that, like most things on the web, adding support for the iPhone is an evolutionary endeavor: you don’t need to completely change your site overnight. Many of these changes can be done incrementally without adversely affecting the other parts of your site.

First, you’ll want to make sure that your site is accessible by the iPhone. It’s likely that you won’t need to do much—for the most part, compatibility just happens. If you’ve been using web standards to develop your site, you’ll find that Mobile Safari works just as you’d expect. Because it uses the same Web Kit rendering engine as Safari on the desktop. It support, with a few exceptions, the latest versions of HTML/XHTML, CSS, JavaScript, and the W3C DOM. Many of the AJAX technologies, including getElementById and XMLHttpRequest, work just like their counterparts on the desktop. Still, there are some areas in which Mobile Safari will work differently or not at all.

Flash plug-in is not supported on iPhone. If your site relies on Flash, all iPhone visitors will see is a blue Lego-style brick with question marks.

Developers on both Mac and Windows can use the Safari browser as a proxy for web development on the iPhone. For the most part, the way Safari renders content is identical to the way it’s rendered on the phone.

The iPhone works well with non-Flash multimedia content—a special version of the QuickTime plug-in is available using normal <object> and <embed> tags. Mobile Safari, however, behaves differently than Safari on the desktop. Embedded movies or audio only display a “play” button which opens the media in a separate window that overlays your content (referred to as “playback mode”). Additionally, you don’t have any control over this playback mode with JavaScript. Because of these differences, Apple recommends that you add a poster image when you embed multimedia content:

<embed src="poster.jpg" href="movie.mov" » 
width="456" height="123" ...>

The poster image is displayed until the user clicks on it to play the multimedia content. This gives a consistent user experience for both mobile and desktop visitors.

After you’ve verified that your site is compatible with the iPhone, you’ll want to focus on some simple changes that give your visitors the best possible experience.

The iPhone makes prominent a little-discussed web development concept: the viewport. To deal with the problem of fitting a relatively large web page onto a small phone display, the iPhone’s developers use a viewport to select the part of the page you are viewing.

Conceptually, the viewport is like a loupe whose magnification is adjustable. When you open a page in Mobile Safari, it will render a 980-pixel-wide section of your website (Apple chose this size to accommodate the largest number of websites). The magnification of the loupe, or scaling factor, is set to shrink these 980 pixels to the iPhone’s 320-pixel-wide screen.

As you pinch or spread your fingers, you are effectively changing the magnification of the loupe (and adjusting the scaling factor). Likewise, double-tapping on a page element, such as a <div>, will adjust the scaling factor so that the viewport is optimized for viewing the element.

Thanks to a new <meta> tag recognized by the iPhone, you can control the behavior of the viewport. Imagine a site whose <body> content is exactly 808 pixels wide. By specifying the following <meta> tag, we can tell Mobile Safari how big to make the initial viewport:

<meta name="viewport" content="width=808" />

This cuts the number of pixels the iPhone has to squeeze onto its screen from 980 to 808. It may not seem like much, but when you consider that the phone’s display width is just 320 pixels, it makes a big difference. In the case of my personal site, it makes the title of each posting readable on the first view—a huge usability improvement.

You also need to be aware that the iPhone adjusts text sizes as the viewport changes. The font size increases automatically to make text as readable as possible. Sometimes this negatively affects elements that use absolute positioning or fixed sizes (especially when using pixels to specify page coordinates). If you find that this causes overflow or other unsightly results, you can easily turn it off using the following CSS rule:

-webkit-text-size-adjust: none;

Alternatively, you can use ems to specify coordinates. Sizes specified this way will increase along with the text size.

In some cases, you may want to use this feature to increase font size for important information on your page. As an example, you could increase type size in a header tag used for a weblog title with a rule like this:

  h1 {
    -webkit-text-size-adjust: 200%;
  }

Before pursuing further adaptions, consider the hardware we’re dealing with—that of both the phone and our bodies. The screen on the iPhone squeezes 160 pixels into every inch of display space—and you’re using your finger to access that display. If you press your finger against the edge of a ruler, you’ll see it uses somewhere between 1/4” and 1/2” at the point of contact. That corresponds to anywhere between 40 and 80 pixels of display space. Now, look at your web page. How many pixels are between the items on your navbar? If you answer less than 40, then you’re effectively asking your visitor to play Russian roulette: their 40-80 pixel finger isn’t going to hit your 20 pixel link effectively. When you use iPhone specific styles, it improves accessibility for someone working on a high-density mobile device. My rule of thumb is to double important elements: bumping a font-size from 18px to 36px, for example. You’ll want to focus both on interactive elements (such as <a> and <input>) and navigational indicators (such as section titles and bread crumb trails). So how do you use styling rules that apply only to the iPhone? The answer is to use a media query on a <link> tag. The following rule is recommended by Apple:

<link media="only screen and (max-device-width: 480px)" 
    href="iPhone.css" type="text/css" rel="stylesheet" />

Other browsers will ignore iPhone.css since they have a maximum device width greater than 480px.

As you continue to adapt your site to the iPhone, you’ll want to think about how Mobile Safari integrates with other services on the phone. It’s easy to have your page pass information to the Mail, Maps, and Phone applications—all you need to do is craft special hrefs for your links.

A link with a mailto: in the href works as expected—it opens the iPhone Mail application using the specified parameters. You can specify some HTML markup in the body, but I’d advise against it since not all mail clients will handle it correctly.

Mobile Safari handles links to Google Maps differently than other browsers, too. It checks to see if a link href begins with “http://maps.google.com/maps” and will automatically load the remaining part of the URL into the Maps application instead of a new web page. The normal ?q=location and ?saddr=start&daddr=destination map queries will be handed by Maps from that point on. Note that since you’re switching applications, the user will have to click the Home button, then the Safari icon to return to your web page from the Maps application. Be judicious when using map links as this can be a disruptive context switch for the user—in most cases it would be wise to provide a map preview on the link so the user can get basic directions without loading the interactive Maps.

Now to the newest and most interesting linking feature on the iPhone: clicking on a link to make a call.

Say you have the following hCard microformat on your contact page:

<div id="hcard-Ernestine" class="vcard">
    <span class="fn">Ernestine</span>
    <div class="tel">555-1212</div>
</div>

By default, the iPhone will turn the 555-1212 into a clickable link. It will take whatever styling has been specified for the parent (i.e. there isn’t any way to specify an id or class for the automatically generated link). If you’d like more control over the link that is generated, you can use markup like this:

<a class="call" href="tel:555-1212">Call Me</a>

When the user clicks on the link, it will initiate a call to the number specified. You need to be careful with these links. Many browsers will display an error message because they don’t recognize the tel: protocol. You’ll probably want to hide these links in your site-wide CSS:

a.call {
    display: none;
    }

And then use your iPhone-specific CSS, to show them with the following:

a.call {
    display: inline;
    }

Going deeper: designing for the iPhone

One thing that’s important to remember when working with Mobile Safari web pages is that they will often be served over the EDGE network. This network, based on cell phone technology, is much slower than broadband networks. It also has higher latency—it takes longer for your HTTP requests to reach a server and for the responses for the request to arrive back at the phone.

The feeling is very similar to the days when the 56K modem reigned supreme. And like those days, it’s important to keep an eye on the size of what’s on your server:

• HTML—Leverage web standards to keep markup and page size to a minimum.
  
• CSS—Use media queries to ensure that a minimum number of rules are loaded and parsed.
  
• Multimedia—Use QuickTime H.264 encoding and pay attention to bit rates. Reference movies allow you to serve up different sized content using the same HTML.
  
• Images—Use iPhone-specific CSS to load lower resolution images.
  
• JavaScript—Be careful about including large JavaScript frameworks—loading hundreds of KB of scripts to show and hide a <div> doesn’t make sense.

Finally, remember the width of the iPhone screen: 320 pixels (for portrait) and 480 pixels (for landscape). Content that fits naturally within these sizes works best and will require less scrolling by the user. Likewise, content that does not span across multiple columns will be easier for the iPhone user to access.

Now let’s talk about taking the big plunge: creating a separate part of your website that is dedicated to iPhone users. Why would you want to do this?

Again, before we can answer this question, we need to take a high-level look at the surroundings for our web designs. We’re all familiar with the current desktop and the browsers that run in this environment—so much so that we take its high density for granted.

Now look at your iPhone. Typically, you’re only doing one thing at a time—making a call, finding a restaurant, or checking your appointments. The interfaces for these tasks are much simpler, making it much easier for you to focus on the work at hand.

Once you’ve decided that you want to customize your site for the iPhone, there are things you need to keep in mind:

• Simplify—On the iPhone, less is more. Let the user focus on your content. Use one column layouts instead of two or three columns.
  
• Size—Bigger is better. Make it easy for the user to manipulate your content. Element sizes should start at 40 pixels and go up from there.
  
• Emulate—Designs that mimic the iPhone user interface will be more successful. The user doesn’t have to learn new conventions when dealing with your content.

There are also JavaScript-based frameworks being developed to ease the development of iPhone-specific interfaces. One of the more advanced and popular ones is Joe Hewitt’s iUI.

One final thing to keep in mind when you start this kind of development: make it an addition to your existing site. Don’t force an iPhone to use this special section of your site—it’s an enhancement, not a jail. Likewise, if a user without an iPhone wants to look at this part of your site, don’t block them with some “for iPhone only” nonsense. Remember that the web always works best when it’s open and developers don’t try to outsmart their visitors.

There are two sets of dimensions to consider, depending on how the user has oriented the device: 320×480 pixels (portrait) or 480×320 pixels (landscape). But you don’t get to use all of those pixels: the top status bar, where the signal strength, time, and battery indicators are located, uses 20 pixels of screen real estate. Then there’s the Mobile Safari address bar (60 pixels at the top) and toolbar (44 pixels at the bottom in portrait, 32 pixels in landscape).

Additionally, Mobile Safari—unlike other browsers—does not maintain a constant size for content viewing. Because of the small screen, the content area is constantly adjusted to maximize the space available for the task at hand. For one thing, Mobile Safari’s address bar moves out of the way as you scroll down the page. If the user is in portrait mode, the height of the viewport is 356px at the top and 416px further down the page (with a constant width of 320 pixels). In landscape mode, the dimensions are 208px or 268px by 480px.

The onscreen keyboard will also hide some of your content while the user is typing. In portrait mode, the keyboard uses 260px at the bottom of the screen (covering the toolbar). The portrait keyboard uses 224px.

Remember also that viewport scaling means that your content may not be displayed pixel-for-pixel within these dimensions. If you’d like to prevent that, you can use the <meta> tag to disable scaling—a very useful trick when you are trying to emulate the iPhone UI. You can disable scaling using this meta tag:

<meta name="viewport" content="width=320; user-scalable=no" />

The physical size of the display is not your only limitation. Unlike your desktop, with its gigabytes of memory, the iPhone has a much smaller area to store data. The four or eight GB of storage on the iPhone is for files, not for caching data like web pages.

Only Apple knows how much RAM is actually in the iPhone. What we do know are the limits imposed by the Mobile Safari browser when loading a page:

• Each text resource must be less than 10 MB (.html, .css, and .js files as well as any other text-based resources).
  
• Images must be less than eight MB uncompressed, calculated as width x height x four bytes. In other words, less than two megapixels. (The exception: JPEG images up to 32 MB will be loaded, but automatically resampled down to the eight MB size.)
  
• Animated GIF graphics must be less than two MB.
  
• Total page content size should be less than 30 MB.

Not only are there limits on how much data can be stored, but there are limits on how fast it can be processed. Again, Apple is keeping quiet about the CPU that’s in the phone, but it’s rumored to be about 400-600 mhz. Compare this with your desktop that’s running three or four times as fast.

The test results show that the iPhone executes JavaScript about 80 times more slowly than an average desktop computer. If your application takes 1/10 of a second to execute on your desktop, it could take up to eight seconds on the iPhone.

Because of the memory and speed limitations, the JavaScript interpreter also places limits on your code: a maximum of 10 MB of data (objects) can be created, and any JavaScript that runs for more than five seconds in a function call will be terminated with an exception.

Note also that scripts will pause frequently to minimize CPU usage. Scripts will not run during a phone call, if a window is inactive, or if another iPhone application is running. Scripts will continue to run during QuickTime playback—though there is no way to control the playback with a script.

There are limits in the Mobile Safari browser itself. The user is only allowed to open a total of eight windows. You can create a new window using either window.open() or "_new" as a link target attribute. If you try to open a pop-up when there are no windows left, the user will see an error (“Could not open a pop-up because there are too many pages open”) and the page load will fail. This also triggers a bug in the current version of Mobile Safari: the browser history in the original window becomes unusable. My advice is to open links in the same window and let the user control the creation of new pages.

As you explore the iPhone, you’ll be happy to learn that the browser works surprisingly well. Still, there are cases where functionality is either missing or behaves differently than it does on the desktop.

Much of what’s missing in Mobile Safari is missing because the user is working with a finger, not a mouse. There are no gestural equivalents to many familiar desktop actions, so corresponding events cannot be generated. When developing on the phone, you’ll find that events for cut/copy/paste, drag and drop, or selection changes (select/unselect) do not fire. Other events behave differently on the phone—most notably mouseDown, which fires after the completion of a tap instead of at the beginning.

In a similar vein, you’ll find that there is no multiple-selection mechanism, since there is no Command or Control key to use while tapping. This may be a good thing: how many sites have you seen with a note to “hold down the key” next to the <select> element? Multiple selection is not an intuitive action for many users.

It’s not surprising that the showModalDialog() method doesn’t work either, since there are no such windows on the iPhone. The same is true about the print() method—there is no way to get printed output from the phone.

There are also issues that arise because of the simplified user interface. After using the phone for awhile, you’ll notice that there are no open or save dialogs. Indeed, there is no file system that’s visible to the user, so it’s not surprising that the <input type="file" …> does not work—there’s no way for a user to pick the file to upload.

Likewise, you’ll find that download links may not work. If the linked file is a known content type, then Mobile Safari can display it directly; if the file type is unknown, an error dialog will display (“Safari can’t download this file”) since there is no way for a user to store it. The valid content types on the iPhone are:

• JPEG, GIF, PNG, TIFF
  
• PDF
  
• Excel, Word (converted to HTML on demand, they are not editable)
  
• Plain Text (.TXT)
  
• MOV (QuickTime)

The following file types will not work in Mobile Safari, even though they are supported in the desktop version of Safari:

• BMP (Microsoft Bitmap), PICT (Macintosh Picture)
  
• RTF (Rich Text Format)
  
• SVG (Scalable Vector Graphics)
  
• # AVI (Video for Windows), MPEG

Finally, there’s an interesting behavior when scrolling with a script: window.scrollTo(0,1) will hide the address bar in Mobile Safari. Use this trick with care, since it hides the refresh button and can lead to usability problems.

If you decide to build an application that tries to mimic the iPhone user interface, you’ll want to stick to some of the standards set by Apple. Of course, you may choose your own color scheme and other branding elements, but remember that sizes for controls, fonts and other interface elements were chosen by Apple to maximize usability. You’d do well to follow their lead:

• Use Helvetica.
  
• Use bold font-weight to maximize readability (remember, your design will often be used in daylight conditions).
  
• Use normal font weight for secondary information.
  
• Each row should be 44 pixels high (lists)
  
• Set text at 20px (lists)
  
• Inset text 10px from edges, and center vertically in row (lists)
  
• Make controls 29px high, with 12px bold text and a 5px border radius, centered vertically in row (lists)
  
• Group items in a 300px wide box with 8px radius (10px on each side of box) (groups)
  
• Set text at 20px (groups)
  
• Inset text 10px from edges (groups)
  
• Place labels above group box (groups)
  
• Inset labels 20px (so that they line up with 10px inset for group box and 10px inset for text within the box) (groups)
  
• Use #d9d9d9 for borders and list dividers (standard colors)
  
• Use #c5ccd3 for light blue (background) (standard colors)
  
• Use #4c566c for dark blue (group box header) (standard colors)

Generally, it’s not a good idea to sniff the user agent when developing sites: the whole point of web standards is “one size fits all.” It’s much smarter to detect JavaScript objects and deal with the browser’s deficiencies:

if ("showModalDialog" in window)
  {
    // show a modal dialog
  }
  else
  {
    // the iPhone cannot show
    // a modal dialog, so do
    // something else
  }

<meta name="viewport" content="width=device-width; initial-scale=1.0; maximum-scale=1.0; user-scalable=0;" />

Here's what each field means:

• width=device-width This fits the page to the device's width. The iPhone's display is 320x480 pixels in portrait mode, and 480x320 pixels in landscape mode, which is why you sometimes see sites use width=320 instead of width=device-width.
  
• initial-scale=1.0 This is the scaling when the page first loads up.
  
• maximum-scale=1.0 This is the maximum scaling allowed.
  
• user-scalable=0 This determines whether the user is allowed to zoom in and out by pinching/double-tapping. You can also use user-scalable=no and user-scalable=yes instead of 0 and 1.

Keep in mind that the viewport IS NOT A WINDOW. Think of it like a magnifying glass over a page. You can move the magnifying glass around and zoom in/out. This is why certain features like fixed positioning don't work on the iPhone(at least at the time of this writing). In Professional iPhone and iPod touch Programming, Richard Wagner explains what a viewport is:

A viewport is a rectangular area of screen space within which an application is displayed. Traditional Windows and Mac desktop applications are contained inside their own windows. Web apps are displayed inside a browser window. A user can manipulate what is seen inside of the viewport by resizing the window, scrolling its contents, and in many cases, changing the zoom level.

Hide the address bar. The address bar takes up a considerable portion of the already tiny screen we have to work with. You'll want to hide the address bar to display as much information on the screen as you can, so that the user doesn't have to flick down. Now let us hide the address bar by adding this single line of javascript code: window.scrollTo(0, 1);

This will "hide" the address bar by scrolling down just enough so that you won't see it when loading the page.

Notice that this only temporarily hides the address bar by just scrolling down a bit upon loading the page. Permanently hiding the address bar may not be the best idea.

If possible, minimize the number of screens your users have to navigate to in order to get the information they want. Having less pages to jump to means less redirecting and unnecessary loading by going backwards and forewards.

Make sure to have a nice icon that people can see when they add your web app to their homescreen. Make a 57x57 PNG file and add the following code to your home page:

<link href="path/to/your/icon.png" rel="apple-touch-icon" />

Having an icon is a good way to quickly recognize your web app, as well as look professional while having some nice eye-candy.

SOURCE