I've been watching, with interest, developers create new applications for the iPhone. Owning one myself - and being knowledgeable in JavaScript - I've been wondering what options there were for creating downloadable JavaScript applications or the iPhone. In doing some research I found a number of solutions, some simpler than others, some requiring more knowledge of Objective-C than others.
Before looking at the options I should note that given the requirements of the platform if you're really serious about getting in to iPhone development you should learn Objective-C. None of the options appear to provide the full range of functionality that a normally-written application would.
This was an early entry to the JavaScript iPhone application market - arriving back in 2007. It requires a Jailbroken iPhone (likely running version 1.1 of the Operating System).
JiggyApp provides a full API for developing an application - apparently separate from most of the typical APIs. Arguably, though, the code ends up being relatively usable.
Plugins.load("UIKit");
var window = new UIWindow( UIHardware.fullScreenApplicationContentRect);
window.setHidden(false);
window.orderFront();
window.makeKey();
window.backgroundColor = [0.8 , 0 , 0, 1];
JSCocoa is a full bridge that maps Cocoa development into JavaScript (instead of the typical Objective-C/Cocoa mapping). The result ends up working in both OS X and on the iPhone.
It's a pretty-clear port of Objective-C style and mannerisms but with a JavaScript syntax. Note some of the differences:
Right now it seems like JSCocoa is more usable for developing OS X applications but the progress moving forward is certainly promising.
"Applications" in MobileSafari
While it's not, technically, a true iPhone application one option is to adapt your existing web applications to be used in a more application-centric manner.
Apple provides a number of tips for improving the style of your web application. The most important points of which are:
Providing a tray icon for the application (to be used when the user saves it).
Providing a full-screen view of the application (with no MobileSafari toolbars showing).
This will give the full appearance of a regular iPhone application (after using some more styling and setup from iui, or similar).
The next step to making your iPhone web application more native-like is to tap into some of the underlying native APIs. One recent release that will help is that of PhoneGap.
PhoneGap is an application that exposes a few JavaScript APIs to pages running MobileSafari. Right now this includes Geolocation and access to the Accelerometer.
Geolocation:
getLocation();
function gotLocation(lat,lon){
document.body.innerHTML = "latitude: " + lat + " longitude: " + lon; }
They're also working on access to the camera, sound, and vibration tools of the phone.
WebTouch
The other day "Dr Nic" wrote up an article on how he had used a WebKit instance (along with HTML, CSS, and JavaScript) to render a portion of his iPhone application.
I contacted him about the project and wondered if he'd be willing to provide some of the code that backs it. Written up by his co-worker at Mocra, Anthony Mittaz, the result is called WebTouch.
Right now it's just a zip file of sample code but hopefully it'll be expanded at some point.
It's really simple and gives you a good entry point into the world of hybrid HTML/CSS/JavaScript/Objective-C/Cocoa development. If you've been interested in Objective-C this might make for a good starting point, as well.
Bonus
While this isn't something that you can actually use, I think it's pretty cool. This guy ported my Processing.js work to the iPhone, writing his own Canvas implementation using OpenGL ES hooking in to SpiderMonkey.
There are a lot of options available for the discerning JavaScript developer - the most promising of which is, I think, WebTouch. It's pretty obvious that in order to be able to build the best possible iPhone application you would have to know Objective-C. Having a clear path, paved with JavaScript, to that end result should be any JavaScript developer's goal.
The other week I went to the Boston iPhone Tech Talk and took a bunch of notes. I thought everyone would be interested in what they had to say as its quite relevant to Mozilla's upcoming mobile efforts, and the browser space in general. Let me know if anything needs any, additional, clarification.
Notes:
There was a lot of JavaScript hate by attendees ("blah blah... GWT is the only thing we trust... blah blah JavaScript is a stupid language..."). Not really surprised. Generally, these are Mac application developers by trade and the Open Web, by comparison, is frustrating and limiting.
There was strong promotion of web standards, down play of plugin (Flash, Silverlight, Java Applets) dependencies.
They recommended optimizing your page according to the following points: Scales for readability, minimize pan/zoom, finger friendly, and tuned for wireless. That translates to: Use clear type and logical page layout, reduce the height or width of the page to better fit within the screen, make your links and inputs large (to handle the large "mouse pointer"), and make liberal use of caching and gzip. All of these are good points to encourage within the web, in general.
Pages that are marked up with XHTML Mobile or are on a .mobi domain are handled specially (they're shown unmodified - assuming that the developer has already optimized the page for a mobile device appropriately).
There are some, very interesting, limitations to pages; and the browser, in general. For the most part this shouldn't effect many sites (especially considering that plugins don't run). I've noted the JavaScript-related ones:
10 MB JavaScript object allocation
5 second JavaScript execution limit
XHR not counted to JavaScript execution time (async or sync)
Scripts may be paused (Inactive window, Safari not active)
Scripts are not paused while a Quicktime movie is playing
Maximum 8 windows open at a time
I found it to be interesting that JavaScript execution was pausable. Thus, if have a game running in one window and go to another, the game (presumably, written in JavaScript) will be paused until you come back to it. This model is akin to what they currently do with Dashboard widgets (which are, also, HTML/CSS/JS and are paused until you view them).
It's important to note that, not only, are you not able to have more than 8 windows open at a time, but you don't have control over windows that you open. There is no such thing as a popup or modal dialog. Nor are there tabs to browse through the open windows (You have to navigate to a separate view where you browse thumbnail views of the sites). I've been trying to decide if this is more-tabbed-like or less-tabbed-like because of how it's designed (e.g. one could argue that having modal popups breaks the tabbed model), whereas not actually having access to tabs (or information about the tabs that you open) is very limiting.
Only three dialogs are allowed: alert, confirm, and prompt. They are all highly styled and consume a large portion of the screen when they appear.
Interacting with form controls is highly unique. When you do so you are placed into a separate editing/manipulation mode laid on top of the browser itself. This is indicative of the larger theme in the browser: They consistently push the user into a separate pane to deal with specialized content. I think that this is an incredibly interesting development and - quite possibly - an optimal way of dealing with "non-native" browser content.
For example, Excel, Word, PDF, and Quicktime content are all handled natively by the browser - and are shown in separate, specialized, views. (Videos are especially interesting - the whole browser is hidden and is replaced with a completely-tailored UI that is optimized for viewing movies.) I was hugely impressed by this set of features and I really think that this is a huge step for a browser to take. Mozilla is starting to do this with the new video tag, but providing means for handling common documents might be interesting as well.
They include a fully standards compliant version of Canvas - they recommend using it, highly. In fact, they recommend using things like border-image, border-radius, and Canvas to remove the need for extra markup or images.
There is no way to completely emulate the iPhone outside of the iPhone itself (e.g. no desktop iPhone browser - even though there's Webkit/Safari - it's not completely the same).
Webkit's new Element Inspector is very, very, nice. Heavily inspired by Firebug, but with the trademark Apple UI touch. They have a CSS/Stylesheet browser (like Firebug) but they also include the default User Agent Stylesheet (which is immensely useful).
To allow the user to have control over page scaling they define a custom meta name/content that you can use:
<meta name='viewport' content='width=320'/>
The possible values for it are as follows:
width=320 (how wide to start the viewport at)
initial-scale=1 (default dimensions)
minimum/maximum-scale (limits user/auto scaling)
user-scalable=yes/no (Allows/prevents zooming via double-taps)
When the user zooms in on a portion of the page, you can adjust how large/small the font size should become with a custom CSS property:
-webkit-text-size-adjust: none
none (font size doesn't grow larger)
auto (the text grows larger)
200%, the text grows even larger
They also publish their own, custom, event and window property to let the user know about the orientation to which the iPhone is rotated, it can be used like so:
There is no concept of hovering (or, really, mouse move events in general - drag/drap isn't possible).
There are no multiple selects. All multiple selects are just treated as single selects.
There is no way to detect which type of connection that you're on (Edge vs. Wireless) and to serve content based upon it. The one catch is that you're able to do it with Quicktime (serving different types of movies) but not with normal web content.
Finally, they're very interested in getting a public sync schema for bookmarks - one that works across all browsers (easily synchronizing Firefox with Safari with iPhone Safari, etc.). Apparently they've contacted Mozilla in the past about this, but I'm not sure to what end this has led.
Today I took a little trip down the road to the grand opening of the Eastview Apple Store. Luckily, I was one of the first 1000 there so I got a snazzy nice T-Shirt, which is exciting. Below is an assortment of pictures borrowed from my Flickr set.
Included in the new release of Apple OS X, Tiger, is a simple command-line application that can be used to convert one document format, to another. Think of it as Image Magick, only for text documents. This is an amazingly useful feature. You can convert to/from any number of these format: txt, html, rtf, rtfd, doc, wordml, or webarchive. Consider this: You have a text document, borrowed from the repository at Project Gutenberg, but you're friends refuse to read anything that isn't a Word doc - and you don't own Word. No problem, just run your text file through this program and you should have your desired result. Now, couple this with a quick install of Ghostscript and you'll be able to generate Postscript files (and, subsequently, PDF files and Images - which brings you full circle back to Image Magick) all from the command-line!
A good new feature in Safari 2.0 is the RSS reader, which I'm sure everyone has heard about by now. However, Apple feels compelled to change all feed URLs from their original http: to a new feed:, making it annoying to use that address elsewhere. The one area that is particularly frustrating is trying to subscribe to a web site using a bookmarklet (such as one provided by most of the major news aggregator services). So, in a nutshell, here are a bunch of modified bookmarklets that will work in Safari, handling the wonky feed URLs easily.
