When you're building programs in ActionScript that run inside a browser, you don't have unlimited access to the user's hard drive. At best, you can load or save one file at a time, with the user's permission in Flash Player 10, as you'll see in Chapter 30, "File Access."
However, using local shared objects, you can easily store all kinds of information that can be retrieved when the program runs again, even after the user shuts down the browser or her computer — usually without explicit user action. Using
SharedObjects, you can give users the power to personalize your programs, retain those preferences, and improve their experience.
There are several ways that SWFs playing in the browser can attain persistent storage. By persistent storage, I mean the ability to store data, close the browser, and then come back later and retrieve the data. All the approaches have different strengths and weaknesses, so let's compare them briefly.
SharedObjects to persistently store data from ActionScript is as cheap, painless, and efficient as instant noodles for dinner, and probably better for you, too. However,
SharedObjects have some limitations in terms of the size of the information you can store, and their dependence on the host computer.
The biggest limitation of
SharedObject data is ...