Solipsism Gradient

Just got an email from Apple that my iPad reservation was fulfilled, and as soon as the store opens, I’ll be there to see if it’s true; I was resigned to waiting for at least 5, possibly 7 days! At least I already a good man-bag for it; not the one Matt‘s wearing in that picture, but this one:

It’s got lots of pockets and zippers, and the main pocket is almost big enough for a MacBook Air. That said, it’s not specific for the iPad, and I’ve already thought about putting in some extra padding in the bottom. But the upscale larger bags are all on back-order.

OK, now for the WWDC tips for newbies. I recommend also (or first) reading the tips from John Martellaro, Brent Simmons, Marco Arment and Peter Hosey – not necessarily in that order. There’s also Apple’s official FAQ.

1. Come in a day early, two or three if you’re from outside the US. It’ll give you some time to get over the jetlag, explore the area around Moscone Center, and meet some people early.
2. Pick up your badge on Sunday in the afternoon. Don’t come in on Sunday morning; although registration opens at 9:00AM, that’s when I will be registering, and I don’t want to stand in line… 😉
3. Take care of your badge. That’s important; if you lose it, there’s no replacement unless you pay again for the entire conference. You may be able to wheedle some Apple employee to give you his badge if your name is Steve Jobs, but otherwise, it’s a huge hassle. What I always do is to bring some small cable ties. Cole Hardware on 4th Street carry them, just a block from Moscone. The trick is to fasten two ties to the badge in a way that locks it to the neckstrap, and I leave the two tails sticking out, one to a side, which keeps the !@#$% thing from flipping over (which it otherwise will do constantly).
4. Unless you’re a legend in your own time, you’ll notice people constantly sidling up to you and stoop to squint at your badge – that’s why it’s important to keep it from flipping over. Even if you go up to someone you’ve talked to a dozen times before, they’ll do that, so don’t be offended; many geeks look alike, and geeks aren’t good at face recognition, anyway. So my tip is to make a special T-shirt for the conference. As long as it’s not too blatantly commercial and/or mentions some direct competitor, they’ll allow it – I recall one of the last WWDCs held in San José, where someone onstage at the keynote mentioned “Brand X” and the next day, all Microsoft employees showed up in “Brand X” T-shirts. Anyway, I have my shirts done at Zazzle, and I use their microfiber shirt; it’s not cheap, but it’s light enough for tropical climates, washes easily on trips, and the colors keep vivid for over a year, even if you use them almost daily.
5. Network. Don’t be shy – almost everybody at WWDC is. Well, you’ll notice the exceptions immediately, anyway. If you’re in a boring session, either walk out and find a better one, or sit down at one of the corridor tables and talk to people there.
6. The WWDC lunch wasn’t too bad in the San José days but has gone downhill steadily since then. Even so, the lunch is also an excellent networking opportunity; don’t waste it. Find some marginally acceptable liquids and solids and sit down at a table, and talk to people. Unless you really need to have that particular meeting right there, avoid going with your old clique.
7. Parties. Well, you should go to at least one – I’m going to sfMacIndie on Sunday (which falls on my birthday, ahem 😉 ). However, YMMV, as they say here; most parties are too loud and crowded, unless you enjoy that sort of thing. If you go, keep your badge on and/or wear that T-shirt. There are partial lists of more parties; just google for wwdc 2010 party list. The same goes for the beer bash on Thursday evening; last year the food there was actually good, but the lines were long, and the music was loud and not to my taste.
8. Bring a laptop and the extension cord for the charger; there are lots of outlets, but not always within reach. Bring a travel surge protector or at least an outlet splitter, so you can ask someone to share an outlet if none is free. Pack a long ethernet cable just in case.
9. Many fellow developers will be glad to talk to you, but won’t take kindly to in-person bug reports; more efficient to send an email. If you have a bug report for any of my products, please do email. However, if you have questions about my source code, we can set up a meeting.

That’s about what occurs to me now; be sure to read the other tip pages, though.

I just arrived in San Francisco a few days before WWDC, which starts next Monday, June 7. By a coincidence, June 6 is my birthday – will turn 0x3B. 😉

Let’s hope Uncle Steve has a nice present for me; I just came from the local Apple Store, where they don’t have any iPads in stock.

While reading the links pertaining to the previous post about a “back” button for the iPad – and, incidentally, for the Mac – it occurred to me that such a capability might be built into a future version of my Klicko utility. Which is Mac-only, of course. For now, Apple doesn’t allow any sort of utilities for the iPhone/iPad, more’s the pity.

I’m rather overloaded at the moment, moving out of my apartment only a few days before going off to WWDC, and I’ve got an iPad app prototype to work on, too; but I’ll definitely look into this as soon as possible. I think that most of the infrastructure, in fact, is already in place inside Klicko.

I did download the Universal Back Button App, but didn’t have time to check out how it works; at any rate, it seems to be quite different in implementation.

Brent Simmons, author of NetNewsWire, writes:

On Macs we have a long-standing culture of apps working together.

…

On the iPad (and iPhone) we can sort-of do the same thing. We don’t have AppleScript or Apple events, but we do have the URL scheme thing for inter-application communication. It’s technically possible to do some of these same things.

But we don’t have an easy way to get back to the calling app.

…

What if the calling app added, as a parameter to the URL, a URL to call when the task is completed?

This way the helper app (NetNewsWire in this case) would know, once the task is complete, how to get the user back to their place in the calling app (Twitterrific in this case).

I was thinking about the same issue, coincidentally, and one idea which occurred to me is to use the equivalent of the http referrer URL (often misspelled as “referer” for historical reasons).

For  a standard http request the referrer is the URL of the document containing the clicked link, so you can get back to that document by clicking on your browser’s “back” button. Now, this isn’t really contained in the URL itself – rather, the browser appends this as one of the fields in the http request headers – but the analogy is interesting.

For this to work locally between applications, the referrer URL would need to be set into the URL targeted at the called application. And indeed, there is a -[NSURL setResourceValue:forKey:error:] method that, in theory could add any key/value pair to the URL. (Currently only the “scheme” property seems to be available, though.)

Update: Mike Abdullah points out in the comments that, in practice, this method applies properties to the file a file URL points at, not to the URL itself. Drat.

On the receiving side, the “referrer” value would have to be pulled out from the NSAppleEventDescriptor that the application gets with the ‘GURL’ event.

All this needs filing enhancement requests and Apple would have to do the required twiddling inside their code base – or rather, bases, as this would be useful to have both on the iPhone/iPad and the Mac side. It would take a long time, if it’s done at all.

The alternative would be to developers to, informally, establish a convention for incorporating this into the URL itself. So we’d have something like:
calledscheme:///the/url/parameters&?REF=callingscheme://some/url/to/return

Probably the second part would have to be suitable encoded/escaped, too. Maybe this would be a good topic for discussion at WWDC?

Interesting piece by Sean Heber aka BigZaphod.  Remember my post about the significance of Clang/LLVM on the iPad?

I think there’s a chance that Apple is slowly building Objective-C into a managed environment similar to Java/.NET. At some point in the future they could define an Objective-C HD (or whatever :P) that no longer maintains total compatibility with C. Since they use LLVM a lot now, they can even use that to analyze your code to make sure that pointer accesses are safe and controlled. Anything that isn’t safely confined to your own app would be an error. Access to the Objective-C runtime functions could possibly even be revoked. After which point, Objective-C HD no longer compiles to machine code but instead to an intermediate representation.

By doing something like this, they can abstract the actual underlying CPU hardware and architecture out of the applications themselves as well as maintain a truly safe sandbox where private and undocumented APIs simply will not be allowed to work. Apps on the App Store would be submitted in this intermediate format which they can translate into the machine code that’s native to whatever CPU happens to be in the device you’re downloading the app for or they could simply put a JIT in iPhoneOS (although there’s no reason to waste the CPU cycles on the device if they can translate them once on the backend – at least for mobile stuff).

Pretty much complementary to my reasoning.

richardl wrote:

Rainer, it is interesting to note that Adobe built their ActionScript/Flash compiler for iPhone on top of LLVM.

http://cs.illinois.edu/news/2009/Oct8-2

http://www.adobe.com/devnet/logged_in/abansod_iphone.html

Thanks, I wasn’t aware of that. However, I don’t think that this invalidates my original argument, which is more based on Clang than on LLVM. Christopher Lloyd also remarked on this:

…Yet Adobe uses llvm for the compiled Flash, so they don’t like Adobe’s parser? silly. http://bit.ly/MQtRZ

Also thanks to Daveed Vandevoorde, who remarked that the LLVM bytecode isn’t as platform-independent as I thought – things like sizes of variables and ABIs (Application Binary Interfaces) stand in the way. Still, it’s not impossible to see Apple defining a generic target platform, in terms of sizes of pointers, integers and so forth, and a specific endianness and runtime ABI, and then staying within the bytecode for that.

Via John Gruber, I just saw an interesting post by Steve Cheney:

It?s pretty evident that Apple isn?t wed to individual suppliers. Not only are they back to creating their own chips, but they are also one of the only ‘compute’ companies to have used each of the top 3 processor architectures over time – ARM, x86, and Power PC.

…This week Apple confined developers to a specific set of tools (XCode [sic]).

…By telling developers to move to XCode tools, Apple is setting the stage to potentially switch architectures.

…In 2003, Apple advised developers to switch to XCode tools. …2 years later Apple moved to Intel across its entire Mac line.

…perhaps the A4 is NOT an ARM architecture. In fact, it?s highly possible that the A4 is a dual core Power Architecture…

The last sentence is of course false, as Gruber says; the A4 does run ARM code.

While I don’t think that forcing developers to switch to Xcode (which is the correct spelling) means that Apple will soon be switching architectures on their iPad/iPhone line, or on their desktop/laptop line for that matter, Xcode does offer developers a future-proof environment that hasn’t been commented on by other observers: the Clang/LLVM project. Briefly, Clang is a compiler frontend for C-based languages, backed by LLVM – which stands for “Low Level Virtual Machine”. Both projects are heavily backed and staffed by Apple.

Clang has been increasingly supported by Xcode as a substitute for the gcc compiler toolchain. The details are quite esoteric, but one interesting capability is that C-based languages – C, Objective-C and C++ – are compiled to the LLVM bytecode, which is then translated into native machine language by a back-end. The last phase could even happen in a just-in-time fashion, allowing apps to be distributed in LLVM code (therefore running on all current and future Apple machines). Some groups are even working on chips that execute LLVM bytecode directly.

In other words, it’s no coincidence that Apple is now instructing developers to switch to Clang-supported languages and their Clang-wrapping IDE (Xcode). There may not be an architecture switch coming soon, but Apple will have much more freedom in doing their own CPUs for iPad/iPhone, and more ammunition in negotations with Intel and other top-end chip companies.

Just a thought to complement my previous post on the subject. A few days ago, Apple announced iPhone OS 4.0 with “over 1500 new APIs” (not a permanent link, sorry).

It’s a safe bet that most of these APIs have been there in the previous iPhone OS release(s), but in their private form. Some of them were simply published – that is, included in the public headers. Beyond that, some had bugs fixed, or their functionality changed, or even their names and parameters changed; and, no doubt, many other APIs stayed private or were, even, dropped. And the common developer can never be sure which is which.

Only Apple’s in-house developers have all this information and for them it’s a mad scramble to update apps with every OS release. This is also why it’s, generally speaking, not advisable to use any apps that come with Mac OS (Preview, Mail, Address Book and so forth) with any previous or subsequent releases; they’ll crash in interesting ways. And this is why Apple lists new features and bug fixes inside those apps when a new Mac OS release comes out.