Theocacao: CocoaHead Debriefing for Sandvox

CocoaHead Debriefing for Sandvox

Dan Wood talked about the development of Sandvox last night at CocoaHeads, and went into a significant amount of detail. Even though I was involved in the development of Sandvox at varying levels over time, a lot of the things he had to say about the design decisions was really interesting.

Core Data

Sandvox is centered around key Tiger technologies, such as Core Data, Core Image and the editing features of WebKit. Karelia encountered significant challenges getting Core Data and WebKit to work together in the way they needed. Dan said if given the chance to go back in time, he would likely not choose the Core Data path, but rather just use file packages.

It sounds like he hit some walls with NSPersistentDocument and storing resources in file packages. Instead, Sandvox stores resources as binary blobs in the database, which has its own set of challenges. There was some useful post-presentation dicussion about how to get around that though, which shows how useful these meetings can be.

By the way, I want to say I'm not necessarily endorsing the idea that Core Data was the wrong way to go for this app. Dan and Terry have done quite a lot of work with it, but it's still a personal design decision that's based on a certain set of experience. If I had to go just by what Dan said me last night, I believe I'd still go the Core Data route — perhaps because the Core Data model makes a lot of sense to me.

WebKit

Dan also talked about the challenges of working with a custom version of WebKit, specifically how to deal with the linker issues so that only Sandvox picks up the custom version. They explored a lot of options, and maybe I can convince Dan to explore it in more detail in a blog post at some point.

Something I didn't realize is that iWeb doesn't actually use WebKit for content editing. Therefore, Sandvox is probably hitting the framework harder than any other publically-available app. Apple Mail is more widely used, but I don't think it's nearly as demanding in terms of content. If you use the editing features of WebKit at some point in the future, you probably owe a debt of gratitude to Karelia.

Third-Party Code

There was also some dicussion about the many third-party frameworks and classes that Sandvox uses, as well as the code that they've contributed back to the community. The Connection framework by Greg Hulands is extremely useful for anyone doing FTP/SFTP connection (sorry, couldn't find a link).

The one interesting sidenote here is that Sandvox actually started out as a DataCrux application. After Core Data was announced, I tried to talk Dan into switching to it. He resisted initially, but eventually made the switch. After last night, I'm not so sure I should have talked him into it. :)

Thanks again to Dan for driving all the way down, and sharing some invaluable insight. Two lucky visitors walked away with a copy of Sandvox Pro.

The next meeting will be the Wednesday of Macworld week (January 10), this time in San Francisco. We haven't decided on a speaker yet, so if you have an app you'd like to talk about let me or "official organizer" Stephen Zyszkiewicz know (his contact info is at the bottom of this page). I think we're going to use the Apple Store as a venue.

CocoaHead Debriefing for Sandvox
Posted Dec 15, 2006 — 6 comments below

Joe — Dec 15, 06 2711

My app (which I hope to release by next week) actually uses Core Data and WebKit too, but without the editing, so I may not be hitting the same rough edges that Karelia hit, but there were still quite a few tricky bits that had to be overcome. In hindsight, would I still have chosen to use Core Data? Absolutely.

Although I may have done all the same features using a non-Core Data approach in about the same amount of time(actually probably less time, since some of the rough edges did take alot of time to workaround), it still doesn't beat the fact that using Core Data (and Bindings) results in a lot less code to maintain. Less code to read and maintain is always a BIG plus (at least for me).

Dan Wood — Dec 15, 06 2713

Just to be clear, I would definitely have used file packages for the media, but as far as the general persistence, Core Data might have been the way to go, although it would be easier to embark on that now, compared to way back when we started using it. So I'm not against Core Data, it's just that it's been an extremely difficult battle due to the immaturit of the documentation (which has been improving over time), the lack of debugging tools, the propensity for it to crash rather than offer helpful error messages, and the fact that it's a bitch to whip into shape when you are a highly multi-threaded application.

If I were starting an appliction now, I'd definitely consider it -- but only if I could figure out a way to store resources in a package, as opposed to in the database as a blob. (The current challenge, which I hope Apple will fix, is that NSPersistentDocument won't really work with a package.)

Greg Hulands — Dec 15, 06 2717

For those interested, the Connection Kit is located at <a href="http://opensource.utr-software.com/connection/">http://opensource.utr-software.com/connection/</a>

John C. Fox — Dec 16, 06 2719

Wish I could have made it to the talk: really interesting stuff. I used DataCrux in MemoryMiner, and have had no regrets. It's nice to be able to drop down to the raw SQL level when you need to, something which is not possible with Core Data (which is certainly understandable given its design goals).

Let me also thank Greg, Dan, Ben and everyone else involved in making the Connection Kit and the Media Browser frameworks. MemoryMiner would have taken a lot longer to bring to market were it not for these and other freameworks. It would not be nearly as "easy" to be an indie Cocoa developer without the existence of such a strong community.

Thanks Scott for all you do with your excellent blog and tutorials.

Best,

John

Scott Stevenson — Dec 16, 06 2721

I guess John is too humble to link to his own software. MemoryMiner is worth checking out, and also make sure to see the sample story site generated by the app.

Joe — Dec 18, 06 2743

Hi Dan,

I can totally relate to how you feel regarding Core Data crashing without leaving any useful debugging information.

I remember I was debugging my conduit under Palm Desktop and it just kept crashing although it was working fine under Missing Sync. The backtrace wasn't meaningful at all to me, and it took me a week to find out the cause in the end and find a workaround (with some great help from an Apple engineer on the Cocoa-Dev list).

If there are any Apple engineers listening in, a debugging tool for CoreData will be extremely appreciated!

Joe

Comments Feed

Comments Temporarily Disabled

I had to temporarily disable comments due to spam. I'll re-enable them soon.