I just stumbled upon this: Home · libgdx/libgdx Wiki · GitHub
(…) the life-cycle of the static variable is not necessarily the same as the life-cycle of your application. Therefore the AssetManager instance of a previous instance of your application might be used for the next instance, while the resources are no longer valid. This typically would cause black/missing textures or incorrect assets.
I wonder if a similar approach would be safe when using Kotlin objects/singletons, because, according to the docs, these are not compiled as static members. So, would it?
Is the claim in the article really true? A static resource on the Jvm is classloader static and I would expect Android to launch every instance of the app in it’s own classloader.
And to be clear, I don’t know this for Android, I’m just wondering.
Android works a quite peculiar way. Basically it supports application suspension and resume on a different vm. If the vm/process for an application has been shut down, it will use a new process for your application (fork zygote and load your app). If however, the process was still cached (it’s memory structures still kept around), it will not start a new vm. Using another classloader in that case would not only be slow, but it would also imply a large use of resources. I’m not sure about the latest iterations, but earlier ones were certainly not close to garbage collecting class loaders.
On singletons, they would not be “safe” as they are singletons. Objects as the Kotlin replacement for anonymous inner classes are as safe as anonymous inner classes in Java (ie depending on your use they could cause a context leak).
1 Like
So you mean they are stil represented using static references? I though maybe this things were introduced in Kotlin to avoid such problem, but from what you’ve stated it looks they are just syntactic sugar.
There has to be a static path to them. They are singletons, and as such per definition you expect to get the same instance every time you ask for it, and you don’t expect to have to provide some sort of “handle” either. As such, there has to be a global variable. The only way to do that on the JVM is directly or indirectly through a static variable.
What Kotlin objects give you is easily creating singletons without having to do all the nasty thread safety things to ensure that the object is actually a singleton (even with serialization and multiple threads attempting to create the object at the same time). While there are some ways to get the JVM itself to do things for you, they are ugly and not straight forward.
1 Like
OK, this is what I was looking for.
Looks like I have some code to rewrite then. Thanks! 
I just want to make sure that this information is still current and my understanding is correct.
Is it possible that an object gets reset (due to process being destroyed and re-created) and is re-initialized when an activity is restored from an ActivityRecord?
Based on the information provided above, it sounds like it. I just want to be sure! Thanks.
Are objects suitable for storing your program state over a long time on Android. No. The android runtime is free to unload your program whenever it feels like it. It will give you callbacks, but it is your responsibility to store your state in a persistent way (sqlite/shared preferences/some other way).
You don’t want to use objects (or any other form of global - objects in many ways are like static variables in Java) to store activity state. There are proper mechanisms for that and statics are not it. You will only have 1 object instance though (per classloader if you want the nitty gritty - if you don’t use custom classloaders you will not have to consider it)