I'm currently working on an Android app that will serve as a reference for a video game (Pokemon to be specific) and I was wondering if there's anything inherently wrong with having all of the data saved inside static classes? This data set is fixed so other than when new games come out, it won't involve much updating. I also don't really want to keep the data on a server because I want to minimize load times as much as possible.
Yes, it is inefficient, though whether this is significant depends on how much data your are talking about.
The inefficiencies arise from the following:
If you hard-wire the data into initializers for
static variables, then the data all needs to be loaded (e.g. into the string pool) at class load time, and it needs to stay there for the lifetime of the application. No opportunity1 to only keep the stuff that is (still) needed.
A second issue is that you also may have a non-trivial amount of code in the static initialization methods for the classes.
Long-term memory usage for "stuff" that is not actually needed will impact on overall efficiency. The GC has more objects to scan, more places to look. And since there is less free space after a GC cycle, it has to run more often.
There is also the issue that embedding your data in you code is liable to be inflexible. The only way to change the data is to rebuild / redeploy. That could inefficient in terms of developer time.
There are various alternatives; e.h. properties files, preferences, light-weight databases. Some of these will give load-time performance that is as good if not better; e.g. by lazy-loading. All of them could allow the loaded data to be thrown away if it is not needed ... and then reloaded.
1 - Even if you were to assign
null to the static variables, there would still likely be implicit references to the objects in the string pool associated with the class itself.