KontakteDB

Background

With the era of printed business cards coming to an end, it seems that for most people, their phone (plus a social network or two) is their main storage for contact information. When I started this project I had a number of contacts on my phone that I hadn’t spoken to in years, but that I also didn’t necessarily want to delete. On my desktop computer, where I have more control over my data and the programs I run, contact management tends to be baked into e-mail clients, but not every one of my contacts has an e-mail address attached, plus my e-mail cient of choice doesn’t have the contact management functionality I want anyway.

That’s why I started a dedicated application for contact management and storage. I have since moved all my contact data into it, which is a sizable amount. I’m also glad that I can restrict the contact list on my phone to people with whom I’m actually in regular contact.

Information

Here’s an (anonymized) example of what the contact editing view looks like in the application. All common data fields are available including phone, e-mail, postal address, employment details, social media links and more.

File Storage

With every contact being a file, they can be moved, copied, sent etc. using standard file operations. This screenshot shows a number of contact files in the GNOME Nautilus file manager (each with name and photo) on Ubuntu Linux.

One of my goals was to be able to integrate contact data into my incremental backup procedure. This meant that I needed to adhere to a design where one contact is saved in one file, which can then be moved, backed up, sent vial e-mail and so on. The “last modified” timestamp stored in the computer’s file system also functions as the last data change timestamp for that particular contact. By avoiding a monolithic database file, my contacts can be incrementally backed up just like any other document.

As for the format, I decided on a Zip-compressed file that includes a vCard, a JSON file with additional metadata, and any number of photos and scanned business cards. KontakteDB supports basic image editing functionality (cropping and brightness/contrast adjustment), the parameters of which are saved in the contact file along with the unmodified original photo, thus even after the editing process the integrity of the original file is preserved.

Technical Issues

Although KontakteDB includes some pretty respectable features for a solo project, it was also my first attempt at using GTK 3, which is very obvious when you use it. Because it does almost everything (including image processing and file I/O) in the render thread, it’s a very laggy program. If I were to revamp or publish it, at minimum I’d have to restructure it so it doesn’t chug for several seconds when opening a contact file.

The vCard export is also a mixed bag. I intended for it to be compatible with many other systems and spent a lot of time deep in RFC 6350, but it turned out that the clients I wanted to interface with (mainly the contacts apps on the two phone models I have owned since the start of this project) were so fragile in their vCard functionality that they would often fail or even outright crash when attempting an import of a standards-compliant vCard. As a result there is a fair amount of device-specific formatting hacks in my export code.