Archive Page 4



Subtle Errors and CoreData

Ideally in Kiwi, everything would be pulled from the server during launch, but this limits Spotlight integration and it makes offline reading of e-mail impossible. I originally toyed around with storing e-mail in the MH mail format because it’s an open format and every message has it’s own file. Persistence is never easy, especially when people demand stability, and implementing the MH format is no exception. Knee deep into writing file I/O code, I took a step back and rewrote with CoreData.

Previously, the interface fed off of instance variables in objects via bindings. It was clear that this was making persistance and multithreading more complex than necessary. So I packaged all the code together that performs IMAP calls and sat it on top of CoreData. Now, instead of writing retrieved IMAP data to local instance variables, it writes directly to the CoreData store. The interface sits on top of a copy of the CoreData store and feeds off of it with Cocoa bindings.

If I had used the MH format, I would have had to manage all of the relationships between Folders and Messages and more importantly, I also would have to insure consistency in the event of crash. CoreData has been a huge help in this regard, it maintains the referential integrity for me and it keeps changes in memory until they are committed. Now users of Kiwi can be confident that their data is stored in a SQLlite database that is consistent across sessions.

Moving from a graph of NSObjects in memory to CoreData has not been without trial and error, though. For about the past day, I’ve been trying to figure out why one table hasn’t been displaying data that exists in the database. I double checked all of my connections, I tripled checked my methods and still, the table was displaying a lone and empty cell. Finally, today I figured it out: I had forgotten to switch the controller in Interface Builder from Class Mode to Entity mode. I made the simple switch, and my tableview (thankfully) came to life.

I have to say that these new technologies, like Bindings and CoreData, solve problems but they also introduce yet another learning curve for developers on the Mac platform. In the end however, I think CoreData is going cause alot of developers out there to take a second look at their persistence code and wether CoreData and Bindings can help them spend more time on other features.

del.icio.us

I never realized how much I rely on del.icio.us until it’s gone down. It’s down right now and the site says:

del.icio.us is down for emergency maintenance. we’ll be back as soon possible.

I wonder what that’s about?

Why I chose CoreData over Maildir

I’ve gotten a few e-mails now from people asking me why I have chosen CoreData over a standard mail format like Maildir. Kiwi will support Maildir for importing and exporting your mail (via Libetpan), but it will not be using it as it’s primary storage method. Here’s a few of the pro’s and con’s for each:

CoreData

Advantages

  • Fast
  • Atomic Commit
  • Manages object graph
  • Simplifies implementation of multithreading
  • Allows for easy integration of added metadata like tags
  • Disadvantages

  • Format is application specific
  • Makes Spotlight integration more difficult
  • Maildir

    Advantages

  • Standard mail storage format
  • One message per file makes Spotlight integration easy
  • Small memory footprint
  • Disadvantage’s

  • Slower
  • Makes persistence code much more complex
  • Makes implementation of the interface much more complex
  • It’s impossible for me to ignore the speed and ease that CoreData brings to the table. While there are definite advantages to using an open standard like Maildir, CoreData is going to make it easier implement more innovate features. In a way the format for Kiwi is not proprietary, since the application will be open source and everyone will have access to the schema for the SQLlite database. So hopefully, CoreData will be the right choice and will allow us to build a better app faster.

    Content Is King

    I was thinking the other day about how the web started out simple, with just plain text and links. Before long we had graphics, flashing text, frames and pages muddled in animated gifs. People have figured out that most of that is junk, a flashy site design isn’t going to make your site popular if it doesn’t have any content. Many sites in the 90’s, didn’t have a whole lot besides animated gifs and nasty colored text blinking on a page, well maybe that’s an exageration but you get my point. Now, we are coming back around to simpler pages that focus on content and displaying their text in a clean consistent manner via CSS. That’s of course, because content is king. Take for example Del.icio.us and Google, they have very simplistic web site designs but it’s the content that matters. It’s interesting that we’ve come full circle.

    AdBlocking with Safari at ollieman.net:

    Using two very simple steps I’ve managed to eliminate almost all ads from the daily browsing experience. Sure, there are a few that get through, but it’s not much and nothing really annoying.
    The first step is to download a adblocking css file from floppymoose.com (direct link - download this). Find a permanent spot for it somewhere out of the way and go into Safari’s Advanced preferences. In the “Style Sheet” pop-up menu select “other” and find that file you just saved.

    I tried it out today and it’s very cool. Check it out at the Ollieman.net