Late Night Cocoa (013) : Sparkle , Design Patterns & UI Standards with Andy Matuschak

Traditional software update requires the user to do a lot of work. The problem with that is that users are lazy. In this episode, guest Andy Matuschak discusses the philosophy of auto-update, some ways to use Sparkle, and some hints about what's coming for it in the future. But who needs software update without a good project? Andy will discuss practices of refactoring and systems design in large projects, and some methods for quickly duplicating Apple's new wave of user interface stylings.



Guest Link
Andys Blog

F-Script Anywhere
Class Dump

Forum for this episode


Not a great show

A little late to the party (I don't listen to the podcasts regularly, I save them up for when I'm on the road)...

I did not enjoy this show and got very little from it. Sorry Steve and Andy. To be fair this may be because I had just listened to Wolf's two-parter and it is hard for anyone to compete with Wolf... ;-)

But frankly the show was too all over the place and too much of it was based on Andy's opinions. Andy has a blog (which I subscribe to) and much of the podcast should have just been a posting there. I much prefer LNC podcasts to deal with a single subject, in detail.

Also time spent discussing how to add Sparkle to a project could have been better used, simply referring listeners to the documentation should have been enough.

please dont endorse the adoption of i tunes 7 ui,

Because its extremely ugly. I don't see what all the fuss is about the ui discontinuity. They are not all that different, except for itunes. That may be so it looks the same as windows without being so obtrusive. notice how it looks like quicktime for Windows.
The ui widgets we are given via IB gives us enough visual continuity to keep things familiar yet varied enough to be interesting. also, they gave guidelines on which ui to use in which situation (even if they brake them regularly.)

Well, okay, yes.

Well, okay, yes. I sort-of-kind-of qualified it in the show, but using private methods isn't really appropriate for serious, production kinds of software. I guess working only on casual, open-source software has probably influenced my willingness to do iffy things. To be fair, I've done a lot of iffy things with private and undocumented API, and I haven't really had any problem with bits changing out from under me. Not that that really says anything about the future, it's just maybe a little comforting.

To clear things up: don't use anything private at all if your app is mission critical or you don't feel like maintaining it if things change. But hey, at least if you use Sparkle, most people will probably update to a fixed version if something breaks. ;)

Sorry if I confused anyone!

- Andy Matuschak

Another great show ...

Thanks guys, some really good tips in there.

I want to take slight issue with one thing Andy came back to a couple times during the podcast: the notion that the lack of underscores before method or instance variable names was some kind of implicit guarantee of their relative stability or permanence.

If a class, method, or instance variable is not publicly endorsed and documented by Apple, then it really doesn't matter how it's named. It's risky to employ it and no rationalizing the underscores will help that :)

Daniel Jalkut
Red Sweater Software

Post new comment

The content of this field is kept private and will not be shown publicly.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Allowed HTML tags: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • Lines and paragraphs break automatically.

More information about formatting options