SharedObject Best Practices

I downloaded the Hulu Desktop application today and when it threw a runtime error (since I have my shared objects disabled by default) I decided it was finally time to blog about best practices when working with Shared Objects.

First, your code should never be “dependant” on a Shared Object being set. The user has full control to disable Shared Objects just like they can with browser cookies. If it absulutely must be set, then you should at least show a graceful degredation to the user explaining that they won’t get the full expereince without enabling shared objects.

Second, you should allways put your shared object code inside a try…catch statement. If the user does have Shared Objects disabled by default, a runtime error will be thrown (and shown if they have the debug player) when you try to write to a Shared Object.

One thought on “SharedObject Best Practices

  1. Scott Langeberg

    Thanks for the heads-up. Just writing some state persistence via SharedObject. May not be as much of an issue in corporate application development, and data may migrate to db, but worth planning for!

    Reply