Archive for March, 2008

Gruber at Daring Fireball links to DropClock, a screen saver “featuring Helvetica Bold numbers dropping into water in super-slow-motion.”

I’m sure there’s people who will appreciate this, but I haven’t downloaded it — at 100MB and $15, I feel like the press in Deep Space Homer1.

But I think DropClock also deserves some special mention for generating the most horrible subpixel rendering of any web page ever for the all-caps description at the top of the page. I’m still trying to figure out how they managed this. Is this a Flash “feature”?

  1. ”Is this a joke?” … “No really, is this a joke?” []

Still not moving to Firefox!

After my last post, Firefox fans are probably wondering why I’d bother. The truth is that even with the annoying bugs present in it, I still find Safari the least offensive browser, given Firefox’s window focus drawing bug, inability to be dragged from the status bar, the botched spellchecker integration, slow launches, etc, etc.

I’m sure most of these will be fixed, but Firefox is a well of platform integration problems. The well does have a bottom, but we’re probably not near it yet.

Restore deleted Safari cookies

Safari 3.1 still eats cookies, although it seems to do so much less often than 3.0. I just hit it for the first time since updating.

So what do you do when your cookies all disappear? Well, you can actually use Time Machine to restore them. The cookies are stored in ~/Library/Cookies in a single file called Cookies.plist. Trash this file, then use Time Machine to restore one from a couple hours previous.

Pidgin: It’s this or uninstall it…

pidgin.png

Based on better, original artwork here.

Mock disaster participants poisoned

Form the CBC, a story about participants in a mock disaster being (really) poisoned.

I don’t know about you, but I sure am glad that Transport Canada is practicing for a real disaster, like poisoning.

One App At a Time… Always?

Gruber at Daring Fireball writes about the restriction of one application at a time on the iPhone. Read it before you go on.

Writing a background task for Touch OS X would be very, very hard. Well, actually, not so much hard as taking a lot of skill, time and effort. I can really understand why Apple wouldn’t want just anyone doing it. But before I get too stressed over it, it’s worth asking a few questions:

First, what kind of program does this actually affect? Not many, probably. In fact, basically, polling network software or network software that receives pushes is the most common scenario.1 An instant messenger program is an obvious example; it needs to keep the connection alive and plays some sort of beep when a message comes in.

So we’ve established a program this affects. Now it’s worth asking a second question: Is it possible this rule is up for negotiation? At the right price, would it go away? And if so, what might the right price be?

  1. An application that background operation is critical to.
  2. An application that Apple thinks is important enough to be worth the resources on the iPhone and the effort. Because make no mistake, it’s going to take effort from Apple.
  3. Doing the work on campus with an Apple engineer’s help.
  4. Payment for the engineer, possibly to be waived in some cases.

In short, if I was to write a program that beeped on the hour, I probably wouldn’t get an exception. I wouldn’t even know who to ask. But AOL Instant Messenger? That might happen. AOL might not even have to ask.2

In short, as developers we need to worry more about we are going to do, than what someone like AOL is going to do.

  1. Time-based software is also a possibility, but let’s discard that for the moment. []
  2. Although I doubt they have anything running in the background at this point. For the purposes of a prototype/demo, a simple, customized back end would make more sense. []

iPhone SDK feedback

Rogue Amoeba’s list of enhancement requests against the iPhone SDK file in Apple’s bug reporting system. Most of these are more philosophy than technical issues, but I know there’s some I plan on filing, too.

In an effort to remedy this and remove some of the limitations, we’ve submitted a number of bug reports to Apple. Some of these are useful specifically for us, while others are beneficial to anyone, but our goal here is the same with all of them - we want to make the iPhone platform as robust and powerful as possible.

Some of the comments show people not getting it. Filing enhancement requests in Apple’s bug reporting system is not spam. That’s the feedback mechanism. Further, a hundred people filing duplicate bugs means more than one developer filing a single bug.

So if there’s something you don’t like in the iPhone SDK, file a report on it. I know I plan to report some of these.

Not everyone is ethical

Of course, we know this. But it’s still a bit shocking to me to see something like this.

John Terry, the apparent creator, hard coded his username and password to his gmail account in source code. All right, not the smartest thing in the world to do, but then I noticed that every time a user adds their account to the program to back up their data, it sends and email with their username and password to his personal email box!

iPhone App Store

Craig Hockenberry writes Hello App Store. Not sure I agree that $99 is too low, though. I think most of those who downloaded the SDK will never buy a signing key.

Code signing

Mike from Rogue Amoeba on Code Signing and You on Mac OS X.