Applications generally load their resources two different ways. One is known as “eager loading”, where everything the application would ever need is loaded all at once. Then there is “lazy loading”, only loading resources when required.
There are pros and cons of each:
– Pro: Small chance for lag when the application is running (everything is already in memory)
– Con: The time it takes to start the application is longer, as everything needs to be loaded
– Pro: Your application loads faster, the user gets in quicker
– Con: When moving to new sections there can be some lag when things are getting loaded into memory
Eager loading is essential for games, at least loading everything required for a level. When you are playing you don’t want any frames dropped, this is the reason you usually need to sit through a “loading level…” screen.
For the applications I work on, most of the time I use lazy loading, which usually works fine, but in an app I have been recently working on one of the requirements is a long list of main suburbs in Australia. Being on an iPhone, loading ~2500 suburbs on request from a database (lazily) can take > 10 seconds on some older devices, such as an iPhone 3GS. Obviously eager loading wasn’t much of an option either, as the user would be sitting on the splash screen for that 10 seconds. I decided to sort of mash them together, and go with lazy loading overall, but as soon as the application is opened it starts loading all the suburbs in a separate thread. If the user is unfortunate enough to immediately open the suburbs listing screen, they may need to watch a spinner for a second, but as the suburbs listing isn’t the main focus of the app, it would be transparent to most users that it was even happening, and most would never experience the lag.