The Cult of Leif Everything Leif M. Wright

18May/100

Creating a flexible data model

Let's say you're writing a program to access and read the Bible. Let's just say.

Sounds simple (and it is simple, by the way, no matter what programming language and IDE you're using). The hard part is making it useful for the end user. Anyone can program a Bible reader. It was one of the first things I ever did.

It's as simple as opening up a Bible text, dumping the text into a dictionary (or associative array, depending on what language you're using) and then referring to that array by number to retrieve the chapter or verse you're looking for.

For some end users, that's all they need. Hooray. You're done.

But let's just say you wanted your program to be a bit more flexible and thus useful. For instance, say you wanted your text to have notations based on specific words in specific verses (I'm thinking of Strong's numbers here. For the uninitiated, Strong's numbers are number-coded references to specific words in the Bible. If you look up the numbers in the Strong's Dictionary, they give you a Greek or Hebrew definition for the English word the code refers to).

iBible versions 1 through 2.7 did that. Easy enough, but clunky as all get-out. You basically had to open a new window with a completely different text of the Bible that had the numbers in parentheses next to the words they represented. Double-click a number and the Greek or Hebrew definitions popped up on the screen. Effective, but essentially a kludge and I'm not proud of it.

There are more elegant ways to do it, and Core Data allows us to explore those ways. Here's the data model for iBible 3 (so far):

I've had to consider that my end users might want to use other versed text besides the Bible in their program. That means I can't call the main dataform "Bible." I also can't call the sections "Books", because though that's a perfectly reasonable Bible convention, it's not always the case in other versed text. Same for "Chapters," which I call sub-sections, and verses, which I call paragraphs. For instance, Genesis 1:1 is a descendent of three things: Tome (Bible), Section (Genesis), Sub-section (Chapter 1). And it is Paragraph 1 of Tome, Section and Subsection.

If I want to be flexible with my text, I need to abstract it as much as possible from my understanding of what a Bible should be. And that's not just a concession to non-Biblical texts. Some versions of the Bible use different book names, different chapter numbers and different verse numbers. If I'm rigidly stuck to 66 books, X number of chapters per given book, I can no longer have my program easily read other versions of the Bible than the one for which I specifically programmed it.

In addition, if I want my notes to work (Strong's, etc), then I have to let them determine which parts of the Tome they work on and which parts they don't. Otherwise I'll have to spend hours programming for EACH new kind of note, and the idea is to make iBible 3 very flexible - able to accept notes and texts I haven't even dreamed of.

17May/100

Core Data: Jeesh!

Working on iBible 3, and I'm using a framework from Apple called Core Data. Long story short, it makes the handling of data in an application a lot smoother and simpler, but the learning curve is high.

Since I started programming (back with BASIC, then Perl. Get off my lawn, you!) reading data from disk and writing it back to disk used some sort of hand-coded I/O, meaning I had to write code to open a file, read the contents of the file, parse the contents and then stash it away somewhere where the program could use it (and the inverse process to save data to a file).

Core Data basically handles the heavy lifting of that stuff so I can concentrate on the rest of the program. That's good and bad. It's good because I would much rather concentrate on the rest of the program. It's bad because I have to learn how to use Core Data and all of the tutorials on the Internet are CRAP!

There. I said it.

I'm thinking that, as I learn Core Data, I'm going to post about it here, breaking down the jargon (oh, is it ever loaded with jargon) and explaining it so a person can scale the wall of the castle of Core Data without having to learn magic and fly over.