Just because you can do something, does not mean that you should. Tip 3:

This may seem obvious to some, but many of the users who contact support are actually trying to do things Flash was never designed for. We have had users who have hacked the ActiveX plug-in, attempted to circumvent security, tried to combine their C++ application Flas in a way that does not work within the limits of the API, and the most common issues are expectations of performance given applications of enormous scale or the application or built with no mindfulness of system resources. (People tend to forget that Flash is a browser plug-in.)

Before you start a project and before you call support do your research and ask yourself, are you trying to make Flash do something it is not designed for?

Don’t get me wrong, Flash is a wonderful tool capable of almost anything. The key being ALMOST! If your application has too many levels of recursion, or if you are trying to provide custom controls to the print dialog with the print class; if you are trying to get Flash to control or work with some 3 rd party technology or if you demand that Flash be capable of loading one hundred thousand records in a datagrid in less then a second you are going to be in for a disappointment. Remember the Flash Player is a tiny little plug-in. (Asking support for ways to disable error messages is not a solution to the problem.)Flash very is powerful for its size but hardly invincible. When you spec out your project always check to make sure that there are no required features that even might be outside of the scope of possibility. If there is any question in your mind as to if a feature is or is not something Flash is capable of then build an isolated test case and find out before your project begins. Call support and ask us, “hey is there any way to do this?â€? trust me we are much happier pointing you in the right direction at the beginning of your project then struggling with you to help you fit a square peg in a round hole at the end of your project. More often then not there is a way to get at least some aspect of the less typical features a developer may need into their application, but it often requires a fair development effort, and especially with performance issues, rebuilding the application architecture in a way that optimizes the application from the ground up, may be required. That is just not a luxury most of us have with a deadline looming over head so contact support early.Also promising something you can’t deliver is not a happy situation to be in so don’t make any promises. Tell the client you are doing research into the possibility and that you are checking with Macromedia support. Trust me they will respect your honesty. Most companies who have hired freelances in the past have been burned at least once by people who have over promised and under delivered. On several occasions I have had to help developers with the details of reports to bosses and clients explaining the limitations of Flash and the resources required for alternative approaches. We don’t mind doing this. We understand that managers and clients will generally ask for the moon without any real understanding of how or if you can bring it to them. Sometimes they are more willing to accept the truth coming from Macromedia then their developers and again we are here to help.Don’t assume you found bug and that Macromedia will just get that fixed for you.When I did more freelance in my days before Macromedia there was one phrase I heard pretty commonly. “Oh that looks like a bug; we will just put that aside for now and get Macromedia to take care of that for us after we get the rest of these line items done.â€? Being on the support side of the fence now I can tell you that is NOT a proper expectation to have. Just because you think it is a bug does not mean that is, and if a feature or approach is not supported, Macromedia not likely develop the feature to accommodate your application design requirements within the timeline of your project. In regards to client side tools it is simply not what we do. If you are at the end of a big project and you have waited to address the “bugâ€? of a critical feature to the project you could very well have wasted most of your development time. That is not to say that workarounds are not available or that Macromedia never fixes bugs. Macromedia certainly provides both, but you have to understand that bug fixes require development/testing/documentation resources and scheduling. Custom fixes are more common in the Enterprise space where customers can pay for dedicated resources required for custom features and bug fixes that can be applied between longer release cycles. But in the majority cases bugs get fixed on our own schedules which may not work will with that Friday night deadline. Honestly I have seen people connected enough to get their requests in through 4 levels of management and three separate departments in Macromedia and willing to throw thousands of dollars at the problem. Their unwilling to listen to support when we say their request is simply not possible has often resulted in less the favorable outcomes. If you need to do something with Flash it was not designed for then contact support. We can get you in touch with the right people for any consulting or SDKs you may require, and we can help you set a realistic expectation for how long a project of that nature may take.I hope you find this advice helpful.-Ken

3 Responses to Just because you can do something, does not mean that you should. Tip 3:

  1. boosie says:

    Dude, thats one stressful job.

  2. Ken says:

    LOL which job? Flash Support or the people who call us for help?

  3. Danny says:

    I’d say they both must be!-Danny