waffle

With Leopard coming up, every Cocoa and Carbon developer will need to check their drawing to make sure they’re drawing in a resolution-independent way. Most people will go about doing this by going to Quartz Debug, open its User Interface Resolution panel, changing the DPI setting and then launching their application. And changing the DPI setting back when they’re done, of course.

Luckily, Xcode is flexible enough to provide a better way.

1. Locate your app’s Executable in the Groups and Files table. (Not the .app bundle or the binary under the Products group, the “Executable” under the special pen-and-paper-icon Executables group.)
2. RIght-click it and choose Duplicate. (You may want to rename the new Executable.)
3. Double click the new Executable to bring up its Info panel.
4. Go to the Arguments tab.
5. Add a new entry with the following argument: -AppleDisplayScaleFactor 2.0. (You can of course change 2.0 to taste.) The panel will look something like this when you’re done:
   
6. To try your app out in the scaled resolution, just change the “Active Executable” in the toolbar or by using the menus: Project → Set Active Executable, and then Run (or Debug) the app as usual.

You may also wish to read more on resolution independence itself:

• Daniel Jalkut explains how to draw images ‘live’ and thusly in the native resolution using everyone’s favorite class, NSCustomImageRep, and everyone’s favorite little yellow guy.
• The (luckily) inimitable Peter Hosey explains how to set up file build rules to compile EPS files to PDF files at build time. Incredibly useful for the other four of you who write your own PostScript.
• Apple’s own Resolution Independence release notes provides the state of the union of Tiger-level resolution independence, with some notes about Tiger hiding its support because no UI work of either exposing the slider nor creating a resolution independent UI had been made. Note that Leopard will ship with a totally resolution independent UI, and you’d better want to fit in here.

Happy hacking.

There are a lot of misconceptions about Java on the iPhone (or rather why it’s probably not going to be in the iPhone). Let me bust the first one right out of the gates: Java on a phone is never - never - about running unmodified desktop applications. If you don’t get this point, consider yourself missing the entire discussion.

Java is tremendously successful today as being the platform that’s most widely supported by a variety of phones. It’s not the native platform for any of them, but it plays more or less the same role that it does on the desktop - offering a device-independent platform. You can get a Java phone app - or MIDlet, as they are also called - and run it on any half-competent phone today.

The second thing to note is that all those Java phone apps are tuned towards a minimal subset of buttons, or towards a stylus. The keypad (digits + hash and star), at least one soft key (a soft key is a key without a label, whose function is described by the on-screen label) and at least the up and down arrow keys. These are very often “fixed in plastic”, as Steve Jobs put it - actual keys. The iPhone does not have that. The iPhone does not afford the precision needed by a stylus either.

And so what would happen if Java was available would be that, since Apple does not use one of the handful of real-time cell phone OSes out there, they will have to implement and thoroughly test, on their own, the Java ME standard.

What this all means is that even if Apple was bent on running Java (and Java phone apps) on the iPhone, it would be a tremendous effort to implement the standard and perform cursory tests on a few hundred apps to make sure that it simulated the controls well enough and also emulated the curiosities of the actual implementations of the standards well enough to be interoperable.

Apple isn’t bent on running Java.

At this point, you might even remember that Java apps will not have a chance to implement multi-touch either. There’ll be no support for multiple simultaneous cursor locations (or even different pressure, if that’s a factor). It will effectively be impossible to implement truly great iPhone apps on the iPhone using Java. And if that’s the case, really, what’s the point? What is the practical upshot for Apple, beyond allowing use of a range of applications coded towards different modes of data entry altogether?

Apple will, sooner or later, provide ways for other people than themselves to code apps for iPhone. At this point, we can only say two things: it very probably won’t be an open deal and it very probably will be Apple’s own tailored APIs. This does not preclude a good ecosystem of applications - look at the “Made for iPod” program and the iPod accessory economy. However, it will likely preclude Java, and on a sadder note, it will likely preclude independent development for the native APIs as well.

The New Stikkit Package is a collection of tools to create a new Stikkit note. Includes an AppleScript and two things built from that AppleScript - an application, generated by Script Editor, and a service, generated by ThisService!

Let me add that this is perhaps the most, uh, promiscuous AppleScripts I’ve seen in a while. Integrates with Growl, QuickSilver and LaunchBar and also provides a great example on calling a web service.

Luigi, Mario, Dr. Mario, Peach: Normal I. Reasonably average. Melee type attacks, a handful of long distance attacks (most weak, one not-so).

Yoshi, Samus, Young Link, Ness, Ice Climbers: Normal II. Light with long range attacks. More gimmicky than Normal I.

Pichu, Pikachu, Jigglypuff, Kirby, Mr. Game & Watch: Very light, fast recovery, long jumps.

Mewtwo, Marth, Roy, Zelda, Link, Ganondorf: SWORDS AND MAGIC LOL. The game’s self-professed champions.

Bowser, Donkey Kong: Token heavyweights: Strong and slow.

Fox, Falco: Guns. Fast.

Captain Falcon: Weak, less ugly Ganondorf.

I am reasonably proficient in Luigi, Captain Falcon and Jigglypuff. After around five years, what about you?