Look before you leap before buying the new iPhone. This is the iPhone that all of us have been waiting for. It promised to address the deficiencies of the first generation iPhone, but does it really?
Here are some reasons why not:
1. Too expensive to own.
Apple and AT&T may have shaved a couple of hundred dollars off the price but they will more than make up for it in monthly fees. If you take into account the regular monthly fee, the data fee, the text message fee, which used to be free, and the $99 annual mobileme fee you could end up spending over $1,000 a year to own an iPhone, that’s 200 gallons of $5 gas.
2. Can’t use the GPS like a GPS.
Forget about getting turn-by-turn voice directions in your car from the new iPhone 3G. The iPhone SDK makes it pretty clear it’s not allowed, “Applications may not be designed or marketed for real time guidance.” Yes it will superimpose your position on a Google map, or show you the closest pizzeria but what about getting real-time route guidance? If you read reviews for other GPS devices you never come across a GPS that doesn’t provide some form of guidance. There’s a rumor that TomTom may be developing a guidance application but you have to wonder how they’ll get it past the Apple police.
3. Can’t tether the iPhone to your laptop.
Want to save sixty dollars per month for a 3G card for your laptop and use the iPhone instead? Not going to happen—not allowed. Although there are plenty of phones, including AT&T’s Tilt, that will allow you to use your 3G phone as a high speed modem for your laptop, the iPhone won’t be one of them so you can add the cost of a 3G card for your laptop at $720 a year to your total cost of ownership.
4. Still no cut and paste.
Cut and paste has been around on Apple computers since the earliest Mac Plus computers. What’s the big problem with implementing it on iPhones? Why is cut and paste so important? Suppose you’re browsing a web site and want to capture some text or a URL, or someone sent you an email and you want to grab some text from it and send to someone else. Not possible on an iPhone. Speaking of email, where’s the spell checker? Predictive typing is fine but spell checkers are everywhere else but here.
5. Wimpy 2 MP camera.
In the world of 5 MP Smartphones and 10 MP point and shoot cameras that you can buy for under $200, why is the iPhone still stuck with a measly 2 MP? That’s so 2003. While we’re at it how come we can’t record video, afraid the non-existent SD card might fill up? The iPhone should be able to stream video by now just like many other cell phones can already do right now.
6. No stereo Bluetooth.
We thought the iPhone was supposed to be part iPod. At least they fixed the recessed headphone jack flaw (and called it a new feature) but the A2DP stereo Bluetooth standard has been around for a while and is missing from the iPhone.
7. The list goes on.
Still no Flash player for rich media content (what grudge does Steve Jobs hold against Adobe). Still can’t send pictures in MMS messages, still no native voice dialing, no mobile TV, no replaceable battery, no flash memory card, and on and on.
Okay, now that I got that off my chest, I feel better and what the heck, so it’s not perfect but it’s still the coolest smartphone out there (other smartphones) and I still want one. I look forward to seeing you on the line.
// Update the values for the next time a gesture happens
width *= e.scale;
height *= e.scale;
rotation = (rotation + e.rotation) % 360;
}
Some readers might have noticed that a gesture is just a prettier way of looking at touch events. It’s completely true, and if you don’t handle things properly, you can end up with some odd behavior. Remember to keep track of what’s currently happening in a page, as you’ll probably want to let one of these two operations “win†when they come in conflict.
We see the birth of the second baby when it comes to building and running apps on the iPhone. People have already spent almost $100k in the first few hours of the AppStore not being open, so tomorrow is likely to be a great day for Apple, and developers, as people run around clicking on buy without thinking of the price.
I spent some time running the applications, and thinking about how different they are to Web versions. For example, when I launch Twitterific vs. a web based Twitter it actually was faster for the Web page to load Safari up with everything. Twitterific also had a strange feature for loading images. As I moved up and down the list the images looked like they were being pushed out of cache which made for a weird experience.
What if the iPhone offered the ability to aggressively cache "applications". When you open the application it opens its own instance of Safari instead of just linking over to Safari. What if it had access to local storage APIs in WebKit?
The native applications do have benefits. They have access to the camera, addressbook, ... well wait, those could be JavaScript APIs too.
There is the tool chain. You can have fine grained performance knowledge of your application with the Objective-C tools, but with SquirrelFish Apple is getting better and better there too. Other nice tooling could work well when constraining the Web interfaces to the iPhone form factor.
What about games? You couldn't do super monkey ball, or could you if you had a really solid Flash, or feature complete canvas.
The native apps are great, but I am still betting on the Web as a great platform for mobile applications too.
Jon Brisbin is a Java programmer doing iPhone development, and decided to scratch his own itch for a better iPhone remote debugger, creating iPhoneDebug:
The iPhone Debug Consle is meant to give greater visibility and interactivity on your iPhone/iPod Touch while doing development. I grew frustrated having to go through the "include console.log statement then reload" method of debugging. I wanted something similar to Firebug's fantastic console and debugger.
I grew frustrated with trying to debug my iPhone/iPod Touch apps because I had no interactivity with the page. I couldn't interrogate variable values or CSS values unless I put in a console.log statement and reloaded the page. This is far from ideal.
In trying to find something that would fit my needs, I came across Joe Hewitt's iPhone/Firebug integration, but I wanted something more robust and that worked without firebug and requiring "console.log" in the desktop browser.
I'm a Java programmer, so naturally I thought of using COMET and Jetty to pass messages between a desktop browser and the iPhone. A couple days later, I had a workable solution. It lets you log things in your mobile JavaScript to a desktop console, but the biggest plus for my situation is that I can send JavaScript to the iPhone to be executed there, with the results logged back to my desktop console. Just like in Firebug, I can call methods, retrieve CSS values, and all manner of debugging activities I've grown used to doing while building apps with Firebug. There is also rudimentary UP and DOWN arrow command retrieval on the prompt.
Here it is in action, getting commands from the console:
Apple is secretive. I normally don't mind so much, as they always come through on yet another cool Mac product. If I could know one thing though, it wouldn't be when the next Macbook Pro is coming out, or when we will see the 3G iPhone. Instead, I wish I knew the attentions in the battle of "what can we develop with on the iPhone".
We started out with only being able to use JavaScript, and folks like Joe Hewitt quickly mastered the restrictive tools such as meta viewport and co.
Then we got the final word of the iPhone SDK, and the Cocoa developers rejoiced as they went from being the cool kids to the "now you will pay me to help in the land grab yO".
Now we got a glimpse of new updates for the iPhone Ajaxians:
Safari 3.1 showed us CSS transforms, which are 2D. On the iPhone though, we can now do 3D transforms which means you can do true coverflow through the browser.
The optimist in me thinks: Wow, WebKit is going to be a first class citizen and Apple will continue to open up more and more of the innards as JavaScript APIs.
The cynic in me thinks: Yeah, they will support it, kinda like how Java is supported on the Mac. One poor bugger has to do all of the work and make people care. In this case, when Apple starts making 30% on all of the native applications, what will their incentive be to help people develop apps using the Web?
The hope is that they realize that the Web is the long term winner, and that they want to win in that market too. Please, Mr. Jobs.
Bob Buffone has created a tool that can be used to output script and HTML to make your site more usable on an iPhone. He tells us about it here:
I bought an iPhone about six months ago; in that time I noticed that even though it had this part of the Web and that part of the Web. Every page I went to I was only reading this part and in order to do that, I needed to scroll it into view and resize the page the same way every time. When I go www.eng.ajaxian.com on my iPhone I need to scroll the content to the right location and scale it so the middle column fits the screen and then start reading. It’s a real pain in the ass.
This was the case for my blog as well. I didn’t want to rewrite it so I figured out a way to use a little JavaScript to set the scale and position of the page at start up so the main content area completely fills the screen for the iPhone.
Once you input the URL to your site, it gets loaded and you can interact with it to put the box in the right place. For Ajaxian, it then output the following HTML:
Man, I was wrong in my post on what about us? and the iPhone SDK. All I knew about was the VP of Phone Software saying "we have stuff coming", but there is a lot more that that, it is just not mentioned in many places.
If you head over to the iPhone DevCenter (registration required) you will find a video titled "iPhone SDK for Web Developers" that goes into detail.
When you watch it you will see a ton of great stuff:
Gestures: ongesturestart, ongesturechange, on gestureend
Other actions: pinching, rotating, swiping
Full screen mode (no more chrome)
A lot of the cool stuff from WebKit nightlies (HTML 5 goodness)
Fantastic news. For a minute I worried that Apple would try to lure in us Web folk to learn Objective-C and Cocoa to grow that platform, but it looks like they are giving the mobile Web love as well as the native APIs. You just have to fork up $99.
As an iPhone user I am quite happy. I look forward to email / contact / calendar push. I think that the tool chain looked fantastic (debugger, simulator, IDE, GUI-builder) and I am sure that I will be seeing fantastic new applications when June comes around (waiting for June again?????). Skype. IM. You name it (as long as Apple approves!)
There are some that don't like the 30% tax, and Russell Beattie has some thoughts too:
I was right about the sandbox, though there's a bit more access to hardware than I thought, there's no VoIP over cellular or ability to interact with the Dock, no ability to change the UI. So though it's not a technical sandbox, it's an arbitrary Apple approved one instead.
Also right about the Orwellian doublespeak: Jobs called only being able to distribute your apps via the iTunes store "the best deal going to distribute applications in the mobile space." Uh-huh. Who wants to be able to put downloadable install files on their own websites? Exchanging the carrier-only distribution model for an Apple-only one doesn't do much for me. I mean, imagine if you could only install applications on your computer via Apple or Microsoft... it's the same thing, no matter how "convenient" it may sound.
Overall though, I am happy. I would love to see how many people pick up Objective-C and Cocoa now. We should keep an eye on the book sales. James Duncan Davidson will be happy :)
But what about Mobile Safari? What about some Cocoa JS love? Apple started out showing off the Web applications for the iPhone, so how about enabling more in that development stream? Some may enjoy learning something new, but others want to just stay in the growing Ajax universe. With the ability to hide the browser chrome, access to Touch APIs, and a few others.... and we can do a lot.
During the event, the VP of Phone Software told us that the next update will include new features for the web apps, so we will see (Thanks to Arn of MacRumors for letting me know).
At this point though maybe Steve wants to shut down that world a little? This is his chance to get a ton of developers on the full OSX platform. Once they learn Cocoa and the tool chain, some percentage of the developers will go on to build desktop applications too!
Interesting times. What do you think? Getting ready to use those square brackets?
I always wonder why the cache is so small. It is typical Apple to not allow an expert mode where you can tweak it. I would rather have a few less songs and have a large cache. But, Steve knows best ;)
The end result of the article is that you should follow this ideal rule:
Reduce the size of each component to 25 Kbytes or less for optimal caching behavior
Given that the wireless network speed on iPhone is limited and the browser cache is cleared across power cycle, it is even more important to make fewer HTTP requests to achieve good performance than in the desktop world. To reduce the number of HTTP requests, Safari on iPhone supports image map, CSS sprites, inline images and inline CSS images. Take advantage of the browser cache whenever possible. If an external component can be shared across multiple pages in the site, remember that each individual component has to be smaller than 25 KB to be cacheable. Also, the maximum cache limit of all components is 475 - 500 KB. Minify all the JavaScript, CSS and HTML. For components that aren’t shared across multiple pages, consider making them inline.
This of course is quite painful if you like to package JavaScript in One Large File for other performance reasons, or if you use a library that is larger than 25KB!
The iPhone can tell us a bunch of things about a site. If I go to TechCrunch for example, it drives me batty as it does a bunch of JavaScript to load in the CrunchBase widgets, and the iPhone keeps thinking it is loading. The blue bar keeps going, and the browser isn't as responsive. I hate those Crunchbase widgets :)
You setup your HTML with a body tag with the class of "portrait" or "landscape" and most of the CSS goes from that. You also put an empty div with the id of currentOrientation that is used for some of the magic.
/*window.orientation returns a value that indicates whether iPhone is in portrait mode, landscape mode with the screen turned to the
left, or landscape mode with the screen turned to the right. */
var orientation = window.orientation;
switch(orientation){
case0:
/* If in portrait mode, sets the body's class attribute to portrait. Consequently, all style definitions matching the body[class="portrait"] declaration
in the iPhoneOrientation.css file will be selected and used to style "Handling iPhone or iPod touch Orientation Events". */
document.body.setAttribute("class","portrait");
/* Add a descriptive message on "Handling iPhone or iPod touch Orientation Events" */
document.getElementById("currentOrientation").innerHTML="Now in portrait orientation (Home button on the bottom).";
break;
case90:
/* If in landscape mode with the screen turned to the left, sets the body's class attribute to landscapeLeft. In this case, all style definitions matching the
body[class="landscapeLeft"] declaration in the iPhoneOrientation.css file will be selected and used to style "Handling iPhone or iPod touch Orientation Events". */
