How Does Integration Work?
Integration starts with coding the component in Flash you wish to use in Flex. Everything is a component; think like this and, no matter how small the asset, you'll be good to go. You write an AS3 class that represents the asset in Flash. Like the AS2 days of old, you make the linkage ID of the symbol in Flash point to your AS3 class. Since everything is a class now in Flash Player 9, your Flash design component asset is too. This class, by my convention, ends in "Symbol". So, if you are creating a glowing button, it's "GlowButtonSymbol". The "Symbol" denotes a Flash-based asset. That way, when you see the class amongst hundreds of others, you can immediately identify it as Flash-specific. Typically, the only thing you would do in Flex Builder to this class is add the Embed tag at the top. Flash IDE will ignore the Embed tag when compiling.

The second step is to create a UIComponent based class in Flex. This class will use your Flash class via composition. You are not required to extend UIComponent; you could extend Container or Canvas for example. A lot of Flash components, however, are design assets using low-level, boilerplate design functionality, so UIComponent usually is sufficient. Everything has to at least extend, or be wrapped in, a UIComponent. If it's not, Flex will throw an exception.

That's it!

You can take this a little further. I like to create test cases, classes that test to see if the component, and only that component, works. They basically throw it on the stage, and call their exposed methods, if any. This makes debugging a lot faster and a lot less frustrating. It may seem to take longer at the beginning; it does. You'll find, though, that in the long run you spend less time compiling your whole application only to find one stupid thing in your component made everything else blow up.

In Flash, this is just test_GlowButton.as. This class is a Document class that you input into the Document class field in the Flash 9 IDE. It attaches the component and hits some of its methods. I like to use keyboard commands to test methods and such. You can save this in the same Flash folder as well, thus segregating it from the rest of your code base.

In Flex, I basically do the same thing: make an application class, embed the component, and test its methods. Flex Builder 2 makes me keep these on the root folder, though, since they are Application files.

Pitfalls & Frustrations "Is it that simple?"
No. There are a plethora of gotchas. I'll try to list the most glaring here.

The most annoying is embedding of sound and images in Flex. For example, Flex doesn't have a library. You therefore use embed tags in your Flex code. This associates an external image or sound with a variable, and you can thenceforth treat that variable as a link to the asset. This embeds it in theSWF, so you don't have to worry about preloading, unlike using loadMovie on external images or Sound.loadSound for streaming MP3s. Flex wraps these assets in special classes called "Asset" classes. A little like when you import a sound into the Flash Library and export it with a linkage name. When you embed a Flash MovieClip symbol in an eternal SWF, it wraps it in a mx.core.MovieClipAsset class. When you embed an image, it wraps it in a mx.core.BitmapAsset class. This is nice. You get strong-typing with embedded assets.

The bad news is, Flash doesn't have access to these classes. I reckon you could use intrinsics, a class that implies "it'll be in the SWF at runtime", and allows Flash to compile. These have to be installed in the Flash 9 classes directory, though; if you put it in Flex's project directory, things could get dazed and confused. If you have to recompile in Flash for whatever reason, you have to comment out the sound code, compile, then undo your comments. Running Flash + Flex Builder at the same time with design intensive files open uses a lot of RAM, thus your comp goes slow, further exacerbating the frustration.

Fonts. Are. The. WORST! Flex 2.0.1, which isn't out yet, apparently has fixed some font importing challenges so you can import more than just polite ttf's. In the past, if you wanted the Flash Player 8 FlashType (a.k.a. Saffron) engine to show really nice-looking fonts, you had to embed them using Flash 8, and then reference that SWF as the font source in the Flex CSS. Either way, it's commonplace to utilize fonts willy nilly in Flash without thinking about what you are embedding. Static text fields, for example, embed fonts by default. There of course is the issue of how they are embedded. Bold or not? Animation anti-alias or readability? Did Flex already embed the font? Who killed JR?

For example, I finally get a build working last night. I then implemented the preloader via the preload attribute on the Application tag. Suddenly my navigation fonts failed to work. Huh? After two hours, I finally got it working again. The Flashpreloader had two static text fields that were using the same font that Flex was using. The difference? The preloader wasn't using the readability version. An issue like this eats away at your productivity and makes you want to start smoking again. Fonts have always been hard in Flash; now you really have to micro-manage that stuff.

Flex Builder caching is another gotcha. When you recompile in Flash, you have to refresh your Flex Builder project. I usually refresh the whole thing; I click on the Flex project base folder, and hit F5. This can take as long as the dreaded "Building 0%" you see on the bottom right of Flex Builder / Eclipse. Basically, it's just copying the updated SWF to your bin folder and/or re-compiling it into our main Flex SWF. This can drive you nuts if you are compiling, and fail to see your changes. Refreshing isn't always enough. Sometimes, if you recompiled fonts or bitmap stuff in Flash, an actual Clean project is appropriate via the Project menu. Takes longer, but it works every time. Good sanity check, that is.

Flash doing whack AS3 builds is another problem. It's probably because I have alpha bits, because sometimes, if your class path changes, it'll compile the SWF, but not with the real class. I'm not sure if Flash 9 is caching ABC files (AS3) vs. ASO (AS2) or what, but I'll call methods on the class, and Flash compiles, but at runtime claims the method doesn't exist. Go strong-typing! Anyway, you'll go nuts staring at correct code, when in fact, the problem is your class path. I suffered a lot from this since I transfer code back and forth between my Mac and PC as well as re-factoring twice.

Frame rate really can suffer in Flex. There are a plethora of reasons for this, but I'm having a hard time finding the time to make reproducible test cases to track down the issues. Here are some theories. First, I think Flash is better at producing SWFs that "know" how to preload themselves. So, if you have a long PNG sequence, the SWF will playback well because... well... because Flash is good at doing animations. The same animation in Flex, though, is slow. Now, this isn't as clear cut as that sentence reads. For starters, most of the Flash stuff I use is in states. States in Flex utilize the Flash Player 9 DisplayList. The DisplayList allows you to have a MovieClip exist, but not be drawn. My guess is, this violates the typical "Hey, there is a long timeline with a lot of assets about to be played, let's preload it." Now, it's "We don't have to draw anything, so just chill...". Thus, it doesn't preload the required assets, and the animation plays slowly.

States have the benefit of removing children that are not applicable to a state you are in. So, in the case of a LoginForm class that has the states of "signIn", "error", and "register", the actual registration fields are not shown. They can actually exist to support databinding, but the actual vector graphics that represents them aren't drawn. This is great.

For Flash animations, this isn't so great. Especially when they are shown, and it now has to play the animation and preload the assets, thus reducing your intended frame rate. That's my theory, anyway.