Clockwise

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.

Current barebones Lexikon app

My first iPhone application that is currently installed only on my phone is an application that simplifies and makes using the Lexin, a Swedish – English dictionary for immigrants, easier on the iPhone. I never purchased a Swedish English dictionary instead relying on Lexin, or Lexikon a Mac application for doing so. However the times I most want to look up a word I’m not at home and the being able to do lookups from my phone would be nice. I don’t know that I’d always want to carry a word book around, but I always carry my phone. The Lexin site is definitely usable in mobile Safari, but it can be a pain as the design requires you to zoom in on each load to actually use the service.

My barebones version consists of a search field, a button to toggle language direction and a webview to display the results. Lexin does have an API, but for some reason it only works Swedish to English and not the reverse, so to do an English to Swedish lookup one must load up the regular web interface page. Both resulting files have extraneous HTML to dump, though at least using the API can save a little bandwidth. There is definitely more I would like to do to style the HTML to make it clear and easy to read while being compact.

iPhone 2.1 Contacts application localized in Swedish

Current design mockup for Lexikon application

The current application saves nothing about state and closing and reopening the application will give you a big blank webview under the search bar. So being able to save the state and bring the user back to where they left the application has been important to implement. However I also wanted to cache the results. In Sweden not all iPhone plans have unlimited data, and while you would need to look up a lot of words to go over the lowest limit of 100mb a month, anything I can do to save bandwidth would be a plus. In addition I’ve used the Lexin for over a year and have never noticed when simply using a cached response would be unfavorable due to stale data. Still I want the user to be able to get fresh data if they so want. I also thought it would be nice for the user to have a way to select words already looked up.

With those considerations in mind I decided that I needed a different design for the main UI for the application. First I needed to determine what functionality the main UI needed:

1. Search for a word
2. Toggle translation direction
3. See the translation results
4. See words cached
5. Maybe a way to edit the cached words list

My barebones version had items 1-3, but lacked a good way to interact and see cached words. Item number 5 was something that could be nice, but not a deal breaker or maker.

I took a look at the landscape of applications to see what would work for my idea. I didn’t have to look hard as I found the Contacts application was a near perfect fit. It has spots for two buttons, toggle translation direction and edit, a place to list the cached words and a search field. Unfortunately having the magnifying glass search icon as part of the table index on the side does not appear to be part of the public API. It would be easy enough to put a searchBar element on the header of the table, but without being able to easily know it was there and browse up to it is a deal breaker. Though it would be nice to not have to devote permanent screen real estate to it, as it could then be scrolled off the screen.

The last image is my current working mockup, it’s not pixel perfect yet, but gives you an idea of what I am shooting for. The search field will filter the word list below so the user can see if a word’s translation is already cached and be able to select it from the table instead. Searching for a word will grab the translation from the website and populate the cache, updating it if already there. The user will have easy access to switch between the direction of the translation. The word list displayed will be for the source language. I’m going to store the translations in a SQLite database and since I have the space I’ll most likely put an edit button so the cache can be pruned from this main view.

I’ll still need to work on the detailed view for a word, but it will most likely be a navigation bar with a back button to get back to the word list, the word in the title bar and a webview displaying the translation below.

I’ll be open sourcing the project and putting it in the AppStore for free. The content is all coming from the Lexin website and it’s mostly a tool that I’ll find useful and maybe others might too. Though I’m still booked up at the moment so any attention it gets will be limited for awhile.