According to AdMob, the iPhone operating system makes up 50% of the worldwide smartphone market, with the next-highest OS being Android at 24%. Sales projections for the Apple iPad run anywhere from one to four million units in the first year. Like it or not, the iPhone OS, and Safari in particular, have become a force to be reckoned with for Web developers. If you haven’t already, it’s time to dive in and familiarize yourself with the tools required to optimize websites and Web applications for this OS.
Mockapp.com has created both Keynote and PowerPoint templates of iPhone UI elements, and has made them available as free downloads. Say you had a dream in the middle of the night about the most awesome iPhone app that, to your surprise, no one has thought of yet. Instead of waking up in a deep sweat and scribbling said ideas on paper, you could dream them up on Keynote.
After mapping out your concept on Keynote, you could then pitch it to others in a Keynote presentation. The Keynote and PowerPoint templates include alerts, the iPhone keyboard, arrow icons, buttons, as well as a host of other UI elements.
Here’s an excerpt from Cooper Journal: Things I learned at Agile Up To Here:
Elisabeth Hendrickson has recently opened a new test-and-development training facility in Pleasanton CA called Agilistry. It’s bright and airy, well-lit and well-stocked, and it feels like home the minute you walk in. In order to publicize her new facility, she very generously hosted a week-long intensive learning exercise.
She invited eleven different people with widely varied skill sets, backgrounds, and interests. She challenged them to build a website in five days using the best practices of interaction design, agile programming, and test-driven-development. We christened it “AgileUpToHere” (#au2h) and it exceeded everyone’s expectations (you can see our results here).
Safari on iPad is capable of delivering a “desktop” web experience. iPad has a large, 9.7″ screen and fast network connectivity, and Safari on iPad uses the same WebKit layout engine as Safari on Mac OS X and Windows. You can ensure that your website looks and works great on iPad, and even create new touch-enabled web experiences for your customers, by considering a few specific differences between iPad and other platforms.
If you have access to an iPad, test your website using the iPad. If not, you can 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 beta 2 and later, which is available to iPhone Developer Program members. In cases where it is possible to simulate iPad-like behavior in Safari on a desktop computer, instructions are given below.
With all this Dashcode and iPhone web development exploration that I’ve been doing lately, the question of course came up in my mind… what about the iPad? I’m already using some rudimentary sniffing to make sure iPhone users go to the appropriate spot, but obviously this case would have to be dealt with too, since maybe I would not want to send iPad users to the same spot as the iPhone users.
So I was very glad to find this article: iPad web development tips by Nicholas C. Zakas at his site, NCZOnline.
As it turns out, my method would have failed in that case since I have only been checking for “iPhone” (NOTE: strings are split on multiple lines to fit on this page… they actually don’t have line breaks.):
The previously-linked post describes the iPad Safari user-agent to be in the following format: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
This was the user-agent string during the beta testing phase. The format is slightly different for the final release: Although this appears to be the official user-agent string, I have received reports of a user-agent like this:Mozilla/5.0(iPad; U; CPU iPhone OS 3_2 like Mac OS X; en-us) AppleWebKit/531.21.10 (KHTML, like Gecko) Version/4.0.4 Mobile/7B314 Safari/531.21.10
You’ll note the addition of “iPhone” in the operating system segment of the user-agent string. This brings the user-agent string for Safari on the iPad more into line with Safari on the iPhone and iPod Touch, which have the following user-agent strings, respectively:Mozilla/5.0 (iPod; U; CPU iPhone OS 3_0 like Mac OS X; en-us) AppleWebKit/528.18 (KHTML, like Gecko) Version/4.0 Mobile/7A341 Safari/528.16 Mozilla/5.0 (iPhone; U; CPU iPhone OS 3_0 like Mac OS X; en-us) AppleWebKit/528.18 (KHTML, like Gecko) Version/4.0 Mobile/7A341 Safari/528.16
This means a single user-agent string sniff for “iPhone” returns true in all three cases. The problem, of course, is that you might want to serve different experiences to the iPhone/iPod Touch than you would for the iPad. Make sure you double-check any user-agent sniffing designed to target these devices.
Then we move on to the interesting tidbit for the client-side. If detection is necessary, evidently we can use the navigator.platform property:
Also, keep in mind that navigator.platform doesn’t change even when the user-agent string for a browser is changed.
Good information for both sides of the computing fence, so I’m glad to have it!
var dsource = dashcode.getDataSource("list"); var name = dsource.selection().valueForKey("name"); document.location = ("http://www.google.com/search?client=googlet&q=" + name);
But your first thought when looking at this may be (as was mine), “what if there are spaces or other characters in the “name” value that are not legal in an URL?
So then I set out to use one of the standard functions for escaping URIs: encodeURIComponent.
Unfortunately, when I entered the function I spelled it encodeUriComponent using camel case, which is what I thought was appropriate in this situation. Evidently not. I even was referencing good ol’ w3schools on the subject too.
But once again it kind of gets back to the whole “was it getElementByID or getElementById?” dilemma. And, unfortunately, unlike Visual Studio, there wasn’t IntelliSense in this case.
So then I set out looking to see why it was bombing, thinking that it was maybe a problem in Mobile Safari, like it didn’t support the function. I switched to escape and that worked just fine.
Then I looked more closely at the w3schools page and noticed the difference.
Felt real stupid too.
But when using the function with the correct spelling/capitalization it worked just fine. Whew!!!
I guess I should have just copy-n-pasted.
Found this forum post to be very helpful and I think I may employ this more often when doing UpdatePanel related messaging-when-done…
You should call the method in this way:
All I know is that when I launched the script properly passing this.Page it worked properly. I had derived from Page to a custom base page, so maybe that had something to do with it.
Additionally, I refined it just a bit by building the script dynamically in a string and then passing that instead of just a literal in the static method call.
One more improvement I was considering is to embed this as a method on my aforementioned customized base page. Then i can just pass a name and the script to the method, and I won’t have to worry about the messy details every time.