It is clearly better than old-Android-API, but it still has some limitations:

No compile-time name checks
If there are a typo on the key name of the preferences, compiler does not warn you. It will be a nightmare if some preference name is used in multiple places and only one has a typo.

Key names should be a Scala symbol name
For example, a key.name@with:special#chars cannot be accessed with Scala type dynamic

Inconsistencies with method and preference access
In the above example, pref.remove(...) is a pre-defined method call, while pref.executionCount(...) is a preference access.

Scaloid 4.0-RC2 contains a new way to access Preferences. Let's look into it:

It is cleaner, performs compile-time validation, and better semantics. Scala macro accesses the value name to be assigned, executionCount in this example. If you want a keyname has special characters, we provide an alternative:

val executionCount = preferenceVar("execution.count", 0)

Preference values does not have a dependency on android.context.Context when it is created. A Context is only needed when it is actually being accessed (e.g. reading, writing, removing). So, it can be a property of plain object (static method in Java terms), and can be defined only once: