I've found that in some tricky cases, it can be helpful to extend the Application class and use it to hold onto references and values that are otherwise hard to coordinate in the lifecycle through configuration changes.
Is there any real downside to doing this? I can't help but feel it's "too easy" a fix which means there's probably some major downside I am not considering.
I am going to decompose your question into two sub-questions.
Is there any real downside to [storing information in a static scope]?
Some problems include:
Thread safety, if there are multiple threads that might hit the static values
Handling N possible values, in cases where you might need N possible values (e.g., multiple instances of some activity, each needing a distinct value)
Like retained fragments and
onRetainNonConfigurationInstance(), this solution does not help with process termination and restoration for a recent task, whereas the
Bundle helps with that too
Did I mention memory leaks?
Common patterns for helping to mitigate some of these things include:
Considering the static value to be a cache with limited size (e.g.,
Using an event bus instead of your own static values
Is there any real downside to [using
Applicationas a static scope, as opposed to just an ordinary
There is only one
Application instance. Usually, it offers little value over a regular
static field. And, because various libraries want you to use their "special snowflake"
Application base class, the less of your own stuff you try lumping in there, the less likely it is you will run into collisions in the future.