3 Replies Latest reply on Feb 4, 2015 12:39 PM by Ned Murphy

    Best practices in structuring a large Flash project?

    capicue

      I'm building an educational site in Flash. A student works through a series of activities, either watching an animated video or answering a question. You can get a good idea of the basic functionality with this mockup: http://imgur.com/Mi4JyHN.


       

      After a student logs in, the server responds with their current activity and progress. The activity displays, and all student interaction is sent to the server to record (time spent on questions, buttons clicked, correct and incorrect answers, etc). When the student is done with an activity, the server is notified and responds with the next activity to present.

       

       

      I'm fairly new to flash and would love to hear how people with experience would structure this project. I can think of the following possibilities.

       

      1. One enormous SWF. All audio files and movie clips are embedded in the SWF and swapped out as necessary. This is not a reasonable option because the size of the resulting SWF would be huge.
      2. Exactly one SWF for each activity. The control buttons and progress bars are obviously shared between each activity, and it seems like a lot of duplication to have them in each compiled SWF. Also, if a button is changed, this requires re-compiling everything, right?
      3. One main SWF that loads others. The main SWF contains the buttons and progress bars and fetches external SWFs from the server to replace the stage area. I don’t know enough Flash to predict how this will go.
      4. Part JavaScript, part Flash. The buttons and progress bars are done in HTML + JavaScript. The page fetches external SWFs from the server to replace the stage area. This is the current system, and the problem is the ugliness/difficulty of managing the communication between JS and AS3.
      5. HTML5. While I would love for this to be a possibility, I don’t feel like it is. Animation is still way easier in Flash and we are still targeting some fairly old browsers. The best part about Flash is the consistency in experience.


       

      Extra questions:

       

      • Which options leave us open to publishing to mobile using Adobe AIR?
      • Which options are best for automated testing / accessibility / version control / general code layout?

       

      Thanks so much for any advice!

        • 1. Re: Best practices in structuring a large Flash project?
          Ned Murphy Adobe Community Professional & MVP

          For a Flash-based design I would go with option 3.  The general controls and objects common for use with each activity would be in the main file.  Whether or not the main file would be responsible for sending activity data to the server could depend on there being determinable similarities between data collections...  otherwise it might fall on individual activity swfs to interact with the database.  There are too many unknowns in this regard for me to offer much.

           

          If this was going to be a loaded application, such as an AIR app, then option 1 might be more reasonable since you only have to install once for everything to be available.

           

          When it comes to mobile you are likely to hit a snag if you rely on using AIR/Flash to try to deal with a main and activity swfs approach... mainly in the Apple realm...  unless I forgot a lot of what I was involved with some time ago, a loaded swf cannot contain any code when it comes to iStuff.  So you end up having to make the main file contain all of the coding to deal with each activity's processing.  Every interface/interactive element can only exist by name and the main file has to target them and assign listeners and processing and etc....a mess in my view.  That's why having the one huge AIR file is possibly a tad more reasonable.

           

          I have nothing to offer in the HTML5 end of things.  I have not yet journeyed down that path.  Since HTML5 is basically wingless without javascript and CSS, it might come to pass that the current system (option 4) is the way to go.

          1 person found this helpful
          • 2. Re: Best practices in structuring a large Flash project?
            capicue Level 1

            Thanks so much for the thorough response, Ned! It's especially helpful to know about the concerns with AIR.

            • 3. Re: Best practices in structuring a large Flash project?
              Ned Murphy Adobe Community Professional & MVP

              I consider them concerns with Apple myself... they are costing me a career.