Enums with associated values are very helpful!

For my flash cards app, I’m currently working on the issue of language selection. This app is going to provide users with a list of many words in many languages. Its goal is to give people a tool to use flash cards for learning and maintaining multiple languages.

Consider a person that doesn’t have this app. Let’s assume their native tongue is French, and they want to practice their English and Japanese. The obvious approach would be to spend one chunk of time working between French and English and another chunk of time working between French and Japanese.

But what if they could work between all three languages? Or maybe just between their non-native languages? (English and Japanese in this case) This is the app for that. Maybe they also want to get to level 1 of Norwegian? Just add it to the mix.

To give credit where it is due, I got this idea from a recent episode of The Tim Ferriss Show.

Tim: If you’re getting too much traffic due to this link, my apologies. I’d be happy to remove it, just let me know.

I confess, Tim Ferriss is definitely a celebrity crush of mine, but back to the topic at hand, enums…

This flash cards app is going to start with approximately ten languages, and I want to give users flexibility in choosing what languages/words get shown, and also what languages they will be expected to use for their answers.

I started by defining a list of askLanguages, and a list of answerLanguages. I envisioned two columns of buttons. The column on the left would let users pick the askLanguages and the column on the right would let users pick the answerLanguages.

But there are some invalid combinations.

If a user selects zero answerLanguages, that is obviously not going to work

But if a user selects all the languages for askLanguages, and selects one answerLanguages, that’s not cool either. If you pick Japanese as your only answerLanguage, it doesn’t make sense to also use Japanese as an askLanguage. But if you add Haida as a second answerLanguage, then Japanese is a valid askLanguage. (eg “What is the Haida word for サーモン?” Trick question, Haida has *many* words for salmon.)

If a user selects two askLanguages, their list of answerLanguages needs to include either both the askLanguages, or at least one other language not in the askLanguages list.

When a user has selected values that can’t actually be used, it could be complicated/messy/challenging for the app to convey why their choice won’t work and what they need to change to make it workable.

So instead of giving users this hyper-flexible way to choose, I assumed users’ selection preferences are going to fall into one of a few categories:

• use all the languages, for both asking and answering
• use a subset of languages, for both asking and answering
• use one language for asking (native language perhaps) and all other languages for answering
• use one language for answering and all other languages for asking
• use one language for asking and one language for answering (old school!)

So I defined an enum that captures these specific cases:

enum LanguageChoice: Equatable, Codable {
    case all
    case oneToOne(Language, Language)
    case oneToAll(Language)
    case allToOne(Language)
    case symmetricSubset(Set<Language>)
}

And now all those obscure invalid corner cases go away. The UI to select a language choice starts with a picker with the five possibilities. For most of the picker choices there will a simple second step for users. Typically either:

• pick one item from a list -or-
• pick N items from a list

There are still some invalid cases (eg symmetricSubset requires users to pick at least one language) These cases (so far) are self-evident, and easy to convey to users in the picking UI. The logic to determine validity can be handled via a simple computed property on the enum.

    var isValid: Bool {
        switch self {
        case .oneToOne(let ask, let answer):
            return ask != answer
        case .symmetricSubset(let languages):
            return languages.count > 1
        default:
            return true
        }
    }

And thanks to the great team of people working on the Swift language, encoding and decoding enums with associated values is now built in. This means persisting a users preferred configuration is easy peasy.

If it turns out some users want to specify more complex language choices (eg “I want one askLanguage, and five answerLanguages“) these can be handled with new or modified enum cases. Even if it turns out there is a group of users who want the ‘totally wide open control’ option, it can be handled as a case in the enum. These users will need to navigate the invalid cases described above, but all the users that select less problematic options can remain blissfully unaware of this complexity.