|[ LiB ]|
This section is less an overview of technology as much as it is a reminder that you're about to start producing applications. Before you start, there are a few steps worth taking.
Flash and other Macromedia software will all get installed within a Macromedia folder (inside Program Files by default on Windows or Applications on Mac). Within the Flash MX 2004 program folder, you'll find a folder called "en" (for English). Within that folder, you should see several folders including First Run and Configuration (see Figure 3.12).
First Run is the most interesting. This folder contains various configuration files that affect the Flash workspace (things such as the contents of the Actions panel and the Help panel). The interesting part is that this folder serves as a template. Its contents will get copied into another location every time you launch Flash. On my machine, that location is: C:\Documents and Settings\Phillip\Local Settings\Application Data\Macromedia\Flash 2004\en\Configuration. Notice the path will be similar on your machine, but you'll need to replace Phillip with the login you use on your computer. The idea is that personalized settings will be saved in the Local Settings version of the Configuration folder. If you don't have such a folder, the First Run folder gets renamed Configuration and is copied to that location.
The configuration folders have several elements. Just remember that changes to either usually require you to relaunch Flash to see the changes. I'm not going to document every subfolder; just remember that they come up many times later, so you should be familiar with how to find those folders. Personally, I've added shortcuts to both (the one adjacent to Flash and the personal copy inside Local Settings) to my Favorites for quick access.
The Central folder is similar to the Flash Player folder except you'll find actual SWF movies (as well as JPGs and MP3s). This makes it possible for Central apps to run even when you're not online. What's sort of weird is that SharedObject Local files created by any Central app actually appear in the Flash Player folder exactly as they would had they been written by those domain's web pages. It's not super complex, but it is worth snooping through these files and folders to familiarize yourself. In production situations, you'll find it's often easiest to just keep this folder open and delete or create files manually.
There are countless versions of the Flash Player. When you do Test Movie, (that is, Control, Test Movie) you use the authplay.dll version (or, on Mac the AuthPlayLib version). If you double-click a SWF, you'll be running the SAFlashPlayer (SA for standalone). Finally, if you publish and view the movie in the browser, you'll be using the Flash Player (either the ActiveX control for Internet Explorer or the plug-in for Netscape and others). On top of all this, there are both "release" and "debug" versions of the player. Multiply all that by the different revisions of the Flash Player, and you'll reach a pretty big number.
I don't mean to confuse matters. After all, you don't have to test everything you build with each player, but it's a good idea to get a handle on how to access each player. First, adjacent to your installed version of Flash 2004 you should find a folder called Players. It contains the standalone players as well installers for the web players. The version used when you do a test movie is named authplay.dll, and it appears in the First Run folder. Unfortunately, all these players will become out of date as soon as a new minor revision of the Flash Player is released.
I can recommend two TechNotes at Macromedia that cover how to remove and install the players: 12727 and 14157. (Just type either number into the Search field at www.macromedia.com). If you're really into archiving all the minor revisions, you'll want to back up any files before you install newer versions. Finally, you also can check out the TechNote 14266 for links to nearly all the old versions of the Flash Player.
My main point here is "know the players and where they are." The other huge tip I can give you is this: Files with the extension .swf (or .fla for that matter) will automatically get re-associated with whatever application last launched it. If you drag a SWF on top of an old Flash 4 standalone player you downloaded from Macromedia, for example, next time you double-click a SWF it'll run that standalone player. I find it easiest to maintain as few Flash Players as possibleand keep them all in a central location. I also keep a SWF on my desktop that contains a text field (named version_txt) and this simple script in the first frame: version_txt.text=$version . That way, I can quickly check what version of the Flash Player I'm running. Also, you can find the authplay.dll version by either accessing its file properties or just opening Flash and selecting Control, Debug Movie. You'll see the Flash Player version listed under _level0, as shown in Figure 3.13.
You can run countless free web server software programs locally on your computer. (For example, Macromedia has a free developer version of ColdFusion that includes a web server.) Installing a local web server is quite useful because you can test your applications without actually uploading to a public web site. As mentioned previously, the root will commonly be a folder named wwwroot. However, running a file in your local web server takes more than just opening a SWF or HTML file inside the wwwroot folder. You'll want to be sure the URL appearing in the browser begins with http:// and nothing else. To reach that wwwroot folder, you should be able to type one of the following addresses:
Don't ask me why, but sometimes the second option works when localhost fails, even though they should be the same.
There are lots more details, such as port numbers and configuring a router to forward HTTP request to a particular computer on your network. Systems vary greatly, and this topic is easily researched elsewhere. In any event, you'll want to make sure your setup is doing what you expect.
If you've figured out where your configuration folders, Flash Player versions, and local web server are located, surely you can move a few SWF files to the correct location. Personally, while I'm testing I often do things manually. For example, "test movie" and then move the SWF by hand to the right location, open the browser, and point to that filemaking sure to begin http://localhost . When you consider all the other folders you have to deal with, it gets really tiring really fast.
A few features attempt to "do the thinking for you," which is why I initially avoided them. Things such as Dreamweaver's Site panel, Flash's Publish command, and the new Project panel in Flash Pro. Without fully documenting these, let me just say this: Take the time to figure them out. They can save a lot of time. Having said this, please don't use anything you don't fully understand. It's not like you're going to cause the Internet to collapse, but instead you can be lulled into thinking everything's working. If you don't know why, however, it can be excessively difficult to troubleshoot when something does go wrong. In addition, you might end up doing something that appears to work but you're just fooling yourself. I don't want to sound too elite on this matterthe tools aren't that tough to figure out.
Here's a rundown of some of the cool things you can do now:
Flash Pro's Project panel can export several related SWFs and even upload the files to an external FTP site.
Dreamweaver's Site panel can do all of that except the SWF export.
Flash MX 2004's new Publish profiles mean you can save every last detail in your Publish settings and load those settings when you start a new project. (Just remember to select Import/Export, and then Export to save a profile to disk or Import to load one you've previously exported.)
In fact, I've yet to really exploit all of these features in a real live project. However, one thing that saves a ton of time is the folder icon that now appears under the Formats tab of the Publish Settings dialog box. It simply lets you browse to a folder where you want files to export. It's a tiny feature, but it shows you how you'll likely discover more little things that can save time.
Finally, if there's one manual process that puts undue stress on me, it's the way I have to clear my browser's cache. That is, if I test an application in the browser and then make an update to the files, I can retest but I might be viewing the old file! That is so frustrating. A lot of people set their browser to not cache, but I don't. Because I know the steps to clear the cache, I can practically follow them in my sleep. I often put a version number right onscreen and confirm I'm looking at the latest revision when I test.
I could go on with little tips, but you'll see more where appropriate throughout this book. In addition, there's a whole chapter on productivity later in this book. Being efficient isn't part of some personal goal to become more like a machine. Instead, being productive means you'll have more time for other interests, including relaxation.
|[ LiB ]|