Blog

  • Job: Client Side Programmer – HTML, JavaScript, CSS, AJAX

    Title: Senior Presentation Code Developer

    Description: Pragmatic Client-Side Programmer Be an expert at coding HTML and Javascript. Ability to implement AJAX solutions. Have an in-depth knowledge of and experience with browser behavior, HTML and design, table structure, style sheets, systematic layouts, and components.

    Interested? Contact Kevin Petti.

  • 4 Flash Jobs in Manhattan, New York

    3 openings, 4 positions available for FT employees for a large Interactive Advertising Agency based in Mid-town Manhattan (5 minute walk from Penn Station NY) Salary range is open and depends on experience.

    Position ID: -T7.5

    Title: Senior Flash Developer and Solutions Architect

    Description: Master Flash implementation. Serve as senior Flash application architect with particular emphasis on establishing flexible, reusable, frameworks that are well documented, accessible to less experienced developers, and meet current and anticipated client requirements. Be particularly adept at Actionscript coding and Actionscript/XML interaction. Have in-depth experience integrating Flash with other technologies, plus knowledge of Flash limitations and workarounds.

    Position ID: -T7

    Title: Senior Flash Developer

    Description: Master Flash implementation. Serve as senior Flashapplication architect. Be particularly adept at Actionscript coding and Actionscript/XML interaction. Have in-depth experience integrating Flashwith other technologies, plus knowledge of Flash limitations andworkarounds.

    Position ID: -T8

    Title: Flash Developer

    Description: Be proficient in Flash implementation, Actionscript coding, and Actionscript/XML interaction. Have experience integrating Flash with other technologies. Be knowledgeable about Flash limitations and workarounds. Take direction from senior flash developers.

    If Interested, contact Kevin Petti.

  • Using DataSelector & the modelChanged Event in the Same Class

    As I’ve mentioned before, DataSelector is a helpful class when dealing with dynamic components that you want to have react to ever-changing data. Shove a dataProvider in your DataSelector-empowered component, and watch it work it’s magic.

    However, what my aritcle didn’t mention was how to utilize DataSelector & modelChanged in the same class. Since DataSelector is a mixin, both in Flex and Flash, it adds methods and properties at runtime. So, if you define a method called “modelChanged”, it’ll get overwritten after you compile; when the SWF runs. You can add an event listener, but this only gets triggered when you initially set the dataProvider to the component, now when the dataProvider itself actually changes.

    There are 3 solutions. You can either do what I used to do in Flash, and that is create a base class that implements DataSelector for the sole purpose of being extended; like the List component does via ScrollSelectList.

    That solution isn’t very practicle in Flex. Because of the elegant way inhertiance is implemented in Flex, you would lose a lot of the power from extending some of the other container classes, such as VBox, Panel, etc. One way to solve that is to use composition with proxy functions; import your DataSelector-empowered component (like a Lits for example), and merely proxy all function calls. That would require, however, ardous amounts of coding which is redundant since the mix-in already adds those methods at runtime.

    The third way, which is more relevant for Flex, is to simply re-direct the modelChanged event to point to your own. Since mixins by their very nature affect the prototype, you might as well play by the same rules since you are already pretty low-level. They will not be such big players in AS3, but until Spring of 2006, here’s what you can do for deployable apps right now.

    public static var mixinModifyCall = mixinModify();
    
    private static function mixinModify():Void
    {
            YourMXMLComponent.prototype.oldDataSelectorModelChanged = YourMXMLComponent.prototype.modelChanged;
            YourMXMLComponent.prototype.modelChanged = function()
            {
                    this.oldDataSelectorModelChanged.apply(this, arguments);
                    this.onModelChanged.apply(this, arguments);
            };
    }
    
  • mx.effects.Fade vs. mx.effects.Dissolve

    These 2 effects in Flex accomplish the same basic task; fading something in or out. The difference is, Fade utilizes a true alpha fade; meaning the alpha value of whatever object you tell it to fade will gradually change it’s alpha setting.

    The cons are, this is very processor intensive, and device text, what all of Flex controls use by default, does not fade by changing it, or its parent’s alpha value. The pros are that for some designs, this looks very cool, and is a must for fading certain elements out without affecting other areas of the design unecessarely.

    Dissolve on the other hand simply draws a fill over the object, defaulting to white, and fades that rect. The cons are, this looks pretty bad where you only want one object or irregulary shaped area of your design to fade since you can see the fill as a box when fading in our out in some transparent design situations. The pros are, if you use the default containers and do not use transparent backgrounds, this produces the same type of fade as a Fade, only less CPU intensive. Additionally, it allows device text to fade in and out since it’s a cover that is fading over top of the text, not the text itself.

    For most Flex applications, a Dissolve is usually more appropriate to use vs. a Fade.

    Hope those at MAX are having a fun time!