Article Image
Article Image

WriteRise #3 - Storing Words

This is part 3 of my serie on building WriteRise.

As I shared at the beginning of this journey I’m working on my own word tracking app for Mac OS - WriteRise. I am planning to share its development process in the open through a series of articles here and on Twitter.

I needed a way to store the word count somewhere. But before deciding how to store it was necessary to decide what to store. Depending on what the how might change drastically. If you need to store the word count per day without any other information you can store it in a file or in a cache. When the data becomes more detailed and correlated you start needing something more robust: a proper database.

The idea was to store writing data for each application on a daily basis. The main questions the data needed to answer were:

  1. How much did I write today?
  2. In which apps?

That’s where I made the first mistake.

In the beginning, I started with a simple SQLite database and raw insert and update queries to update the word count. It seems like the most basic solution that still solved all of the problems.

I am a big supporter or not overengineering systems when it’s not needed, but sometime, as this case shows clearly, it might be a mistake.

This was to have a history that I could go back and look at later. I would also have a live word count kept in memory that would update on the fly.

The problem with this approach is that the same data could diverge since it lives in 2 different places. Maybe there is a bug in the function that takes care of updating the menubar label with the value, but the cause is not obvious. It might be a problem with the database and the in-memory counter diverging or it could also only be a visualization problem and the underlying data never diverged. When a system becomes complicated the points of failure increase.

There needed to be one single source of truth. The real data was either in memory on in the database and the other data would need to reflect that. The logical place to put the real data is in the database.

I had to scrap this solution altogether, not having the ability to have live updates from the database was a deal-breaker. I switched to Realm, I’ve used their database in many mobile apps before. It is not just a database, it’s a framework to manage your models. It does much more than just persisting them to a database and because of that is usually overkill for simple applications.

For WriteRise though the ability to have a query automatically update with new results from the database in real time is exactly what it needs.

I also didn’t want to manually worry about coalescing the changes to the database. Each time you type a word we update the word count, but if we updated the database every time it would be a bit too often. Realm automatically batches changes and writes them to the database every x seconds while still giving you the updated result right away.

This way I accomplished:

  • Live update of the word count without worrying of inconsistencies and manually syncing the state between the app and the database.
  • Data synced between the value in the menubar and the value in the detail view since it takes the data from the same place
  • Ability to have more details on the data, since it’s not only a database I can link each word to the application that originated them easily and automatically so I can easily see the word count for each application in real time.

Interested in participating in the closed alpha? Sign up to be notified when it starts and on how to get in.

Blog Logo

Valentino Urbano



Valentino Urbano

iOS Developer, Swift, Writer, Husband

Back to Overview