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 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". */
document.getElementById("currentOrientation").innerHTML="Now in landscape orientation and turned to the left (Home button to the right).";
break;
case -90:
/* If in landscape mode with the screen turned to the right, sets the body's class attribute to landscapeRight. Here, all style definitions matching the
body[class="landscapeRight"] declaration in the iPhoneOrientation.css file will be selected and used to style "Handling iPhone or iPod touch Orientation Events". */
document.getElementById("currentOrientation").innerHTML="Now in landscape orientation and turned to the right (Home button to the left).";
break;
}
}
And, since it is Christmas/insert your winter holiday here, there is a nice sample snow globe that you can shake by changing the orientation of your iPhone.
Have a great holiday period, and try to stay off of your phones and spend some time with the family ;)
There was a day when Web development was in a sad state of affairs. The majority of developers laughed at JavaScript, and were focusing on a killer new server-side web framework, or a new ORM library. The consensus was that that browser was dumb. The modern TN3270 if you will.
A few renegades were actually building fantastic dhtml experiences. We could look up to Erik and Arv, and the many others who pushed the boundaries.
We were giving some talks on “Building killer web sites with dhtml” and we enjoyed surprisingly people with what was available, but the majority still didn’t care. Then Ajax came along and the revolution started. Finally, we could get back to thinking about the user interface and general usability of Web based applications. We could care about the user again!
This is from a post on the new devphone.com, a new community site that hopes to do the same for Ajax, for mobile development. We believe that it is the time of a mobile development renaissance. The iPhone has pushed the boundaries, and Android is joining in the fun. People are already using their mobile devices to do so much, but it is time for really great interfaces to come to life as we have platforms that enable them.
To kick off the community we got to sit down with Joe Hewitt to discuss the iPhone Facebook app, how he develops on the platform, the iPhone in general, and what he would love to see from Apple. We also got to talk about the upcoming Android release and what he is looking to see out of that mobile platform.
Watch and listen to the interview below:
If you are interested in mobile development, check out devphone, subscribe to our feed, and let us know what you would like to see. It is very early days, so who knows which direction it will go.