0
votes

We are developing a big piece of software that has a main SWF of more than 30mb. In order to reduce the loading time, we are using external SWFs that are loaded on demand (e.g. when a certain GUI Button is clicked or at a certain stage of the application is reached). In order to connect the logic of the SWFs with the main application we are loading the external SWF with all its class definitions first and set graphics and localized texts later. The data and logic is set blindly - we (as programmers) do not see which public member and variables are used by the SWF (created by GUI designers) so we are really prone to typos on both sides of GUI development and AS3 programming. However - we do have the source code available and the troubles we are having seem to be unnecessary.

How do we connect source code of Adobe Flash Pro with AS3 code which works with the corresponding SWF in a way that code assistance features of Flash Builder are enabled? When you import the code of the .fla, certain members are unknown since they only exist within the .fla. What is the recommended workflow?

3
It sounds like you are looking for a technical solution to a social problem. I think you might find it worth the effort to have unit tests or automated spot checks on the UI designers' files, and other checks on the code. There should be standards that everyone on the team is responsible for.mfa
not being able to see the class structure of a class you have to work with as a programmer looks like a technical problem to me. the public member and methods are currently organized within a document - problems with typos and high maintenance costs are associated and need to be resolvedSchifty

3 Answers

1
votes

The easiest way to connect would be to use a SWC instead of loading the SWF at runtime, as I understand from your question this solution is not allowed due to size constraints.

What you could try is to ask the designers to deliver as SWC and create your own project (in flash builder) for every SWC that you get. Now you get autocompletion, and you can still create a SWF that you now build from flash builder instead of flash cs6 and can be loaded at runtime.

You probably will want to use (parts of) the same code in multiple projects if you set it up like this, so make sure you create a library/main project that all your 'swc projects' are using.

Now make sure that the main/library project is compiled using -link-report and the modules use -load-externs to exclude classes that are already in the main project.

1
votes

Here's how I used to do this when working on a smaller scale project and then I'll write thoughts on how it could be scaled.

These were the steps taken in the process of developing the GUI:

  1. Have the general concept (programmer not involved, the designer decides this with UI/UX or the customer).

  2. Designer and programmer review the general scheme that was created during the previous step and the programmer creates necessary definitions for symbols and other assets that must be present in the SWC that the designer produces as the result of her work.

  3. The designer receives the "dummy" definitions, connects them to the project. Whenever she creates a new symbol or imports an asset, she links that asset to an existing definition.

  4. After a stage, when some of the symbols are already in the SWC, the designer hands the SWC to the programmer. The programmer uses his own definitions (from which the designer has derived hers). The programmer used those definition to write the functional parts of the interface and to connect them to other parts of the program.

By cycling through these steps we were able to gradually add more components to the project and develop parts of it independently of one another. (It is possible to split the workload between designers such that each one will produce their own SWC with the set of definition they previously choose to work on).

The pitfalls:

  1. Designers need to be trained to use the forklfow (very few know how to connect symbols to existing definitions, how to compile SWC). But the functionality is there in Flash CS.

  2. Human errors (if a designer makes a typo when linking - she won't notice it until the library is handed to the programmer).

Avoiding human errors

In my smaller scale project I was just running the SWF extracted from SWC through the swfdump utility and piping it to grep to see if the symbol definitions are present. Given there aren't many, it was possible to do it by hand.

However, since the project you describe is larger, I'd go for writing a script that takes for the input the created outline (ActionScript source file) and the SWC library. Decompresses the SWC, extracts, SWF from it, runs it through swfdump and verifies that all definitions from source file exist in the SWF. The designer would be responsible for running this script before sending the SWC and ensuring that at least those symbols / assets she has added during the last update indeed made it into the library.

There are still several technical problems with the analysis: duplicated names, possible high level of "noise", it would still rely on a human to run this check instead of making it analogous to commit hook for example. But none of these seems unsolvable - given enough effort and inventiveness it must be possible to come up with an application that'd ensure integrity.

0
votes

Maybe not very helpful, but I would suggest that your main application should be responsible for all application-critical functions. Especially navigation.

When you load an external SWF, that SWF should operate inside its own 'sandbox' and only communicate with the main application in limited ways: - tell the main app that the SWF is completely loaded. - tell the main app when a user has completed/done something that the main app needs to know.

The main app should never expect functions to exist without checking if the SWF is there and if it has these functions. The loaded SWF should only call a limited number of functions in the main app, that have all been predetermined.