Today I got to spend some quality time getting started on the iPhone Lexikon application. My high school computer science teacher, Mrs. Miller, would be so proud that a lot of it was done with pen and paper. Not quite psuedocode, but mapping out the application to make sure I had at least a rough idea of what the forest should look like before I started planting trees.
Another good thing is that the iPhone developer forums yielded an answer to a question that I’ve had for quite a while. I’m not quite sure where this sits on the NDA, because it’s not documented, but it is released public software. I suppose I’ll state up front I’ll remove it if asked. For my application design I wanted the top of the table of words to contain a searchBar. Searching can be one of the important features of the application, but if the user wants to browse the list I would like to allow them to see more words and not have to permanently give the searchBar screen real estate. Though ideally since search is so key it would be good to be able to send the user quickly back to it. This interface exists to have a magnifying glass as part of the table’s index in the contacts application, but is undocumented. Typically you can supply a character for the different index items, but apparently (I haven’t been able to test it yet myself) if you provide {search} back it will show up as a magnifying glass in your index.
I also spent some time evaluating adapters for SQLite. I only know of two contenders that work on the iPhone, sqlitepersistentobjects and fmdb. Now I am using the SQLite database as a lightweight data storage, I envision only needing three fields, the word, language and its translation result.
Sqlitepersitentobjects seemed like the no brainer option of the two and so I investigated it first. It’s nice in that it will handle creating the database and saving things for you without much work on your part at all. However this ease comes at a cost, all data in an object is saved if possible, I’ve got a property on my model that is related to memory management that I don’t want saved to the database. The other obstacle is that I envision having a unique index on the language and word so I can simple do a “REPLACE INTO” SQL statement instead of having to worry if a word already exists in the database.
This left me with Gus Mueller’s FMDB adapter. It seems like it will help ease the use of SQLite in my application, while still allowing me the control I need to make my application the way I want. Though I don’t foresee a need for my database table to ever change I am going to include Dr Nic Williams fmdb-migration-manager as well. In case the table ever needs to be changed this will ease that process by giving me something akin to Rails’ migrations, so users’ databases can remain intact.
I’ve pushed the initial version up to GitHub, as this will be an open source project. It will hopefully one day reside in the App Store as freeware. There isn’t much to the repository yet beyond a skeleton of the app, but hopefully that will change quickly.