What is the benefit of putting values like this in...

# announcements

[Florian]

What is the benefit of putting values like this into a private object? Is the only purpose that we have the PreferencesKey. prefix?

private object PreferencesKeys {
        val SORT_ORDER = preferencesKey<String>("sort_order")
        val HIDE_COMPLETED = preferencesKey<Boolean>("hide_completed")
    }

[Animesh Sahu]

Yea, since objects are initialized at startup you can have grouped variables. You can also put them in a companion object but since companion can't be private, you'll have to append private in front of each property.

[Florian]

thank you

[Florian]

I could also put them as normal `val`s into the enclosing class tho. I don't really see the point

[Animesh Sahu]

Putting them on a class, makes them instance variables, which is initialized at the instantiation of it. Variables declared in object are initliazed statically, i.e. before main() runs and you can reference them from anywhere at runtime.

[Florian]

even if they are private objects?

[Animesh Sahu]

Yes, objects are singleton, created at startup, exist throughout the runtime.

[Florian]

I still don't get the point in the example above. There is no reason these keys need to be initialized in advance

[Animesh Sahu]

https://developer.android.com/reference/kotlin/androidx/datastore/preferences/package-summary#preferencesKey(kotlin.String) Docs suggests, that there should not be multiple keys with the same name in the runtime (and with different types will even throw exception).

Initalizing them at startup and having same instance of key throughout the application lifecycle may be more consistent 🙂

If you don't want to initialize them statically, then you can use lazy delegate, which doesn't initilalize the value at startup but instead at the first access and then caches it.

[Florian]

alright, thank you very much

[Florian]

although I think objects are initialized lazily

[Florian]

companion objects are static right?

[Animesh Sahu]

All objects are statically initialized

[Florian]

the docs say "Object declaration's initialization is thread-safe and done at first access."

[Animesh Sahu]

Strange, The decompiled code clearly shows it is statically initialized 😕

object TestObject {
    val a = "hello"
    fun b(): Nothing = TODO()
}

Decompiled version:

public final class TestObject {
   @NotNull
   private static final String a;
   public static final TestObject INSTANCE;

   @NotNull
   public final String getA() {
      return a;
   }

   @NotNull
   public final Void b() {
      boolean var1 = false;
      throw (Throwable)(new NotImplementedError((String)null, 1, (DefaultConstructorMarker)null));
   }

   private TestObject() {
   }

   static {
      TestObject var0 = new TestObject();
      INSTANCE = var0;
      a = "hello";
   }
}

[Animesh Sahu]

Even object without any property seems to show the same behavior 😕

[Florian]

thanks for checking it out

[Florian]

no idea

[Animesh Sahu]

Let's create a thread to discuss this behavior in #CQ3GFJTU1 I think the docs are not updated...