Understanding Flash security and configuration widgets

When your widget plays on a user's Chumby device, it's effectively loaded (via a loadMovie command) into a shell movie. Both the shell and your widget are downloaded from chumby.com to the device. This is important information if you plan on developing functionality that allows your widget to load data, images, sounds, or other SWF files from other domains—even from your own domain. Flash Player has built-in security restrictions preventing cross-domain access. If the SWF file you've developed originates on chumby.com, as all published widgets do, then your SWF file can only draw data directly from chumby.com. Luckily, there is a wealth of information available online about how this works and various strategies for loading external data. To get an overview of the security model included in Flash Player and how to use crossdomain.xml permission files, check out the Developer Connection article: Creating more secure SWF web applications.

Basically, if you want to provide dynamic data (such as tracking a shipped package or displaying the local weather forecast) then your widget must first have permission to access the domain where that data is provided. If you run a server that provides the data, you can simply copy a crossdomain.xml file to the root level of your server. If the source of the data resides on another domain (and that domain doesn't already have a crossdomain.xml file) then you'll need to set up a proxy server to allow your widget to call your server (still, with permission granted via the crossdomain.xml file) and then set up your proxy server to retrieve the data from the other domain and return it to the widget.

Configuration widgets

During the process of publishing your widget, you have an option to include a "configuration widget". This is a SWF file that can only be accessed by the end users at chumby.com via the "customize" link that appears with every widget that they add to their channel. If you don't create a configuration widget, the customize option only allows the users to specify how long a particular widget plays before cycling to the next widget on the channel. However, if you include a configuration widget, it serves as the UI to let users save data similar to storing a cookie or working with a local shared object. For example, if you create a weather checking widget, it would be helpful to provide a field where the end user can enter their zip code.

Including a configuration widget has two benefits. First, it offers you the ability to build a UI that's not limited by Chumby's small touch screen, because users access and enter their information into the customize page (the configuration widget) while using their browser—with their mouse and keyboard. Second, if you include the configuration widget, you can leverage it to save variables for each user between sessions. This offers a convenient strategy to allow each specific user to save their settings and the saved variables are automatically loaded the next time your widget runs on their device.

The process of writing the variables to chumby.com from a configuration widget is a bit tricky, and I'll cover that in a minute. However, each variable the user saves to a configuration widget is set automatically, the same way FlashVars work. The good news is that when your Chumby widget loads, those variables are already set and accessible.

To create a configuration widget, I recommend starting with the sample provided on the Chumby Wiki. If you check out the code on Frame 1 of the file named simplebanner_config.fla, you'll see all kinds of gnarly ActionScript, but the key section of the code is provided below:

function gotParameters(x) {
     _root.params = x;
     gotoAndStop(2);
}

Basically, the function above sets all of the variables that were previously saved into a variable named params. It may seem odd to start the widget running with the values that used to be, but understand that all except first-time users are returning to the configuration widget. Your application will be more inviting to users if you can display their current settings. 

We'll continue evaluating the code of the configuration widget by examining the code on Frame 2. Here the text field is populated with the value of params.banner with the following line of code:

bannerInput.text = _root.params['banner']  

In this configuration widget, the only variable that is saved is called banner , but it is possible to save more than one entry item. In order to support multiple variables, banner is saved as a property of the object params . For this reason, the variable is actually params.banner .

After the user clicks Done, you can see (inside the done() function) that the value of the text field is saved back into the params.banner variable and the value is saved in chumby.com's databases via the _chumby_set_widget_parameters() function (which is located in the code on Frame 1). Finally, the configuration widget calls a JavaScript function called dismiss() which is part of the page that hosts the configuration widget at chumby.com.

If you want to learn more, you can download the configuration widget and deconstruct the code, but it works…so I recommend simply changing the graphics on Frame 1 and then replacing the contents of the Stage on Frame 2 while continuing to use the params object to access the parameter(s) you plan to use.

For example, if you want to save a user's city and state, you can replace the content on the Stage at Frame 2 with two input text fields (city_txt and state_txt ) and a button instance named doneButton .  Then replace the ActionScript in Frame 2 with this code:

city_txt.text = params.city;
state_txt.text = params.state;
doneButton.onRelease = function() {
     params.city = city_txt.text;
     params.state = state_txt.text;
     _chumby_set_widget_parameters(doQuit,params);
}
function doQuit() {
     _chumby_exit();
}

It's important to remember that the values you save can only be strings or numbers. If you want to store an array, for example, you'll need to come up with a strategy such as using join() before saving the values and then split() when restoring them. 

The most convenient thing about using configuration widgets is that once the data is saved, your actual Chumby widget receives those variables automatically when it starts up (for example city ,  state or banner) .  However, be sure to account for the possibility that these have a value of undefined (which will occur for all new users that have not yet run your configuration widget).

Page 4 of 6

Previous Page

Next Page