• Test your website in Safari on iPad using the iPhone Simulator (Hardware -> Device -> iPad). iPad is available in the iPhone Simulator in iPhone OS 3.2 SDK.

• Test your website on iPad, and update user agent detection code if necessary. iPad user agent string is:
  

  Mozilla/5.0 (iPad; U; CPU OS 3_2 like Mac OS X; en-us) AppleWebKit/531.21.10 (KHTML, like Gecko) Version/4.0.4 Mobile/7B334b Safari/531.21.10

• Simulating Safari on iPad HTTP requests in Safari on the desktop.  First, enable the checkbox next to “Show Develop menu in menu bar” in Safari’s Advanced Preference pane. Next, select Develop -> User Agent -> Other from the Safari menu. You will be prompted to enter a user agent string. Copy the Safari on iPad user agent string above, then paste in it into the dialog box that appears. Note: You can try this trick with websites like Gmail and YouTube to view how they display a different version of their website for iPad Safari.

• Using a constant for viewport width.
  

  <meta name="viewport" content="width=device-width" />

• Prepare for a touch interface. Don’t use a:hover pseudo class or mouseover events.
• Orientation media queries to automatically select the proper stylesheet based on whether the user is in landscape or portrait.
  

  <link rel=”stylesheet” media=”all and (orientation:portrait)” href=”portrait.css”>
  <link rel=”stylesheet” media=”all and (orientation:landscape)” href=”landscape.css”>

News about Pastebud:

• Copy and Paste Comes to iPhone – Wired News
  
• iPhone Copy and Paste Now Working Between Safari and Mail – Gizmodo

We have decided to drop the non-disclosure agreement (NDA) for released iPhone software.

We put the NDA in place because the iPhone OS includes many Apple inventions and innovations that we would like to protect, so that others don’t steal our work. It has happened before. While we have filed for hundreds of patents on iPhone technology, the NDA added yet another level of protection. We put it in place as one more way to help protect the iPhone from being ripped off by others.

However, the NDA has created too much of a burden on developers, authors and others interested in helping further the iPhone’s success, so we are dropping it for released software. Developers will receive a new agreement without an NDA covering released software within a week or so. Please note that unreleased software and features will remain under NDA until they are released.

What does this mean to you?  This means that developers can now share to the world any technical articles or tutorials related to developing iPhone apps or web apps.  Now, I can finally proceed with publishing my iCopyUPaste technical article.

The main advantages of client based mobile Web applications are that they provide very good possibilities for graphic design of user interfaces and keep content available even offline. Furthermore, they often show faster reaction times and are sometimes easier to link to other telephone functions such as directories, camera, etc. The main disadvantage of every client-based solution is that they initially need to be downloaded by the user and installed on the mobile – a practice that will need to be repeated for every new release. Many users are prevented from taking this step due to technical problems, security issues and a lack of clarity concerning costs involved. Furthermore clients are always dependent on the mobile phone operating system and must often undergo costly adjustments for each individual terminal.

Mobile sites, on the other hand, do not require any installation. They are immediately available over the browser and the sites’ content and software are continuously updated unobtrusively to the mobile user. Mobile sites also provide a greater scope of outreach than clients do, as nowadays practically all mobile phones have a browser. Adjusting mobile sites and rich media content to various mobile terminals can be made 100 percent automatic. This means a massive reduction in development and testing expenses. User interface design is also no longer an obstacle. Modern mobile phone browsers enable use of AJAX and Flash, thus creating a user experience similar to that of PC Web. If a company is looking for a larger audience reach with as little hassle as possible, the mobile site is the clear winner.

I totally agree. The one thing that I advocate is to have some kind of markup language that allows the browser to have access to native device functions such as the PIM, camera, etc.

The premise is simple.  I want a way for anyone using an iPhone to open a bookmarklet on any Safari web page that activates a hidden dialog menu.  They can select any text from the web page and copy the text to a “Copy and Paste” web service up in the “cloud”.  The user can paste the text on another page’s form input field or somewhere else on the same page.  I can already think of several hurdles such as cross-domain JavaScript, server-related security issues, and iPhone limitations on JavaScript events.  I plan on sharing every morsel of information that I find on my journey and I invite anyone to help.  I will start putting up the code in some form of source control (more on that later).  By the time I’m done, perhaps Apple will already have implemented a nice solution to this problem.

The wonderful part of this idea is that it doesn’t necessarily have to be confined to iPhones.  Creating it as a web service and opening up an API allows any platform that can consume web services to have access to a “cloud-based” Copy and Paste.  Therefore, I can envision native iPhone apps to simply create the following options: “Copy to iCopyuPaste” and “Paste from iCopyuPaste“.  They can hook those events to consume the “iCopyuPaste” web service.  Of course, the down side is that it won’t work if you aren’t immediately connected to the 3G or Edge or Wi-Fi network, but that’s the trade off for copy and paste.  Another use case scenario could be for someone who needs to copy some text from one computer’s browser over to another computer’s browser.  If they needed that text to be pasted into a native app via the system’s clipboard, someone could conceivable use Adobe AIR to create a widget that consumes the “iCopyuPaste” web service and store that text onto the system clipboard, ready to be pasted on any application on the desktop. Thoughts?

What does iPhone 2.0 offer that warrants an upgrade?  GPS, 3G, and slightly larger storage.  That simply is NOT enough to warrant the extra $30 / month I’d have to shell out to get the new iPhone 2.0.  I currently pay $55 incl. taxes and fees for my iPhone 1.0 plan, and I thought that was pretty hefty to begin with.  This new plan simply is highway robbery!  Apple and AT&T, no thanks, but I’m sticking with iPhone 1.0.

Why has Firefox surged to  the top?  Two things. Add-ons/extensions, and tabbed browsing.  I cannot even imagine browsing the web without these innovations.  Those two simple ideas have made my online experience a sheer joy.  My top ten add-ons include:  del.icio.us, Foxmarks, Adblock, Google Browser Sync, Google Gears, Google Notebook, Operator, Greasemonkey, Firebug, and User Agent Switcher.

The upcoming FIrefox 3 also promises new innovations to make browsing even more simpler and useful. The aptly named “Awesome Bar” is indeed awesome.  You just start typing in anything that you’ve accessed in your browser URL, and it comes up with possible suggestions.  Unlike type-ahead, the suggestions you get can come from any position in the URL (not just the first n characters). Also, the performance and security enhancements are much needed as pre-Firefox-3 browsers had started to become slow.  I remembered the primary reason that I had switched from IE to Firefox back in the day was because Firefox 1.0 was so much faster than IE 6.0.  Performance is as much part of the user experience as UI. You can have the prettiest user interface, but if the user has to wait longer to get their information, they will perceive the product as crap.

Mozilla’s next phase is to rule the mobile browser space. The space is already crowded with the likes of Webkit, Opera, Pocket IE, etc. How awesome will it be to be able to keep those Add-Ons while surfing the mobile web on any smartphone platform. That’s Firefox’s bread and butter.  That’s what will make them successful in the mobile web 2.0.

The iPhone Safari browser, Nokia, and Android all use the same web browser engine called Webkit.  Webkit is a revelation in itself. The full web browsing experience on the desktop now available on the mobile device. Mozilla’s Fennec is based on the same Mozilla Firefox engine and also allows for the full browsing experience.  Windows Mobile has Internet Explorer and its also starting to move in this direction. See a trend?  Yep. The days of WAP browsing are slowing being numbered. Its not going away anytime soon, but it eventually will.

Of course, as a developer, you will also be faced with a choice of developing a mobile native application vs mobile web application. That decision is not an easy one to make. There are so many platforms to choose from. iPhone, Windows Mobile, Palm, BlackBerry, Java ME, Flash Lite, Symbian, and the list goes on. This tells me that in order to get the most market penetration for your application, targeting the mobile web is the logical choice. However, there are exceptions. Gaming apps, off-line storage, and integration with phone hardware feature set are all compelling reasons to target your application to a platform as opposed to the mobile web.  What Apple should have done to make this decision easier was to integrate phone APIs into the Safari Webkit engine. Create a subset of XHTML tags or JavaScript objects that allow the mobile web app to tap into the PIM, camera, or other mobile device native function.

It is after all a very good thing that Apple has decided to provide URL-based access to the iPhone’s telephony, email, and other services, but that point really got lost on the crowd I think, who were expecting an SDK to access these things. We’ve known all along that web apps would be one possibility for third-party iPhone development, and Steve’s “there’s no SDK, just use Safari and standard Web 2.0 technologies like Ajax to develop iPhone apps” message didn’t highlight the power of what they are actually allowing here. (As one colleague commented, “just try getting your web app to make an actual phone call on a J2ME-based phone.”) Personally, I think that there are a lot of interesting possibilities for third-party development with this kind of access to the iPhone’s main features, and I’m not surprised that Apple isn’t letting us get at the OS or place buttons on the home screen, but his message clearly didn’t go over well with the developer audience here in San Francisco. Read More.

Obviously, having access to basic phone functions isn’t entirely new as many current mobile web browsers give this basic functionality (if your web pages are coded correctly). The real meat is if web developers are given access to local persistent storage on the phone, access to iTunes, and access to mail and calendar. Another important thing that we would need is access to the multi-touch user interface events (i.e. in addition to the standard onClick and onFocus events, perhaps we would use onPinchIn or onPinchOut events to trigger actions on the web application. I have yet to see any real specifications on this 3rd party web app API, but it does hold some promise (contrary to what many see as a disappointment).

Oh, and one last thing. I also want to be able to run Java ME on the iPhone. I already have two Java ME apps that I use constantly. Gmail and Opera Mini. It would be sweet if the iPhone could leverage the Java ME space. However, I do recall that Steve Jobs once quoted as saying that Java is too heavy weight and isn’t likely to be in its future plans. Therefore, I’d assume that Java ME on the iPhone will most likely never happen.

Time to stop using the button element because it doesn’t render on many of the mobile web browsers.

If only there was a way to save common canned responses to some datastore on your mobile phone, and simply paste them into form fields that you need to enter. I have a Windows Mobile smartphone device, and that is a feature that I most wished for. Sure… the platform supports copy and paste, but only for phones that have pen-based input. Surely, there must be a copy-paste mechanism for those smartphones that only have the joystick/keypad-based input. I have tried several mobile web browsers for my Cingular 2125 Windows Mobile smartphone device, and they all fail on providing this key feature. I tried Opera Mini (J2ME), Pocket IE, and the Opera Browser beta for Windows Smartphones, and it is an incredible chore to input text. A simple copy to datastore and paste mechanism would help alleviate this annoyance.

My hope is that someday the mobile browser space will be advanced enough that it will rival that of the desktop browser space. That way, web developers can simply write their code once, and that it will render properly on all web browsers – desktop and mobile versions.

Web developers in the desktop world have had to deal with cross-browser incompatibilities when writing code. The same can be said for the old class of mobile handsets and their fragmented support for WAP, XHTML, JavaScript, and AJAX. To my knowledge, there are only a few mobile web browsers capable of rendering AJAX.

If your phone runs on the Windows Mobile platform, IE Mobile is the default web browser installed. According to the IE Mobile developer blog, AJAX is supported on IE Mobile. Unfortunately, the JavaScript DOM support is limited. Therefore, most AJAX toolkits out there will NOT render their AJAX widgets correctly on IE Mobile. Come to think of it, I am not sure that any AJAX toolkits even consider testing on IE Mobile or any other mobile web browser for that matter.

The Opera platform is probably the most well-known mobile web browser that is capable of supporting AJAX. The only thing slowing its adoption is the fact that it is not free, and it is a separate download and install. Opera does have a free version called Opera Mini, but it is not known to support AJAX. Opera Mobile is also only targeted for Symbian and Windows Mobile platforms. This leaves out Blackberry users, which is significant base of mobile web users out there. The only other way for Blackberry users and other handsets to adopt AJAX-like functionality is through the use of Java MIDlets (J2ME). However, this requires the handset to include a J2ME runtime, and it is a separate application install. Speaking of J2ME, Mojax is yet another platform that promises to enable AJAX in a large subset of mobile devices.

To recap… Full AJAX supported mobile web browsers are far and few between. The iPhone’s Safari Mobile and S60 Platform is a giant leap forward for mobile AJAX. The other players include Windows Mobile, and Opera Platform. Blackberry and the rest of the field can use J2ME technology to fill the gaps for AJAX-like web content, but it really is not a true mobile web browser experience (as it is a separate application install required). Any bets as to who will lead this pack? Let’s just hope that more and more mobile web browsers will support AJAX, and that everyone works together to ensure that we do not have the same cross-browser incompatibilities that have plagued the desktop web browser world.

Resources:
http://www.fiercedeveloper.com/story/editor-s-corner/2007-01-23
http://my.opera.com/operaplatform/blog/
http://my.opera.com/operaplatform/links/