All Things Flex, Flash, and ActionScript

The problem domain: An issue exists where in a modular application you want to be able to share events from different modules without creating a dependency between the two. Deeply nested objects make this even more apparent when you realize you can’t use bubbling since they don’t reside within the same branch line down to the root trunk.

(more…)

http://help.adobe.com/en_US/AS3LCR/Flash_10.0/flash/sampler/package-detail.html

It’s interesting to see, not necessarily from a backward compatibility model, but interesting none the less for those of us who are leading enterprise applications which are still stuck at “lowest common denomenator” just due to their tremendous size and expected reach.

I can certainly see how many applications can expect to reach a better performance vs cost (engineering man hours, legacy patch costs, etc) ratio for their intensive parts which either have the best chance for memory or cpu utilization management. Lets face it, none of our applications can be so brazen to run on a Cray with unlimited resources (although it sure as hell would be a lot easier on reducing Engineering constraints or getting “Pixel Nazi’s” off our backs).

This one crept on me and while I thought I was on the right track it wasn’t until I came across a tech-note on Adobe’s site that finally led me down the right path which incidentally I only found by accident. The main issue was a SecurityViolation Error which is common place in dealing with accessing data in different domains. Usually we all know about this, and is fixed in implementing the correct subdomain accessor in the crossdomain.xml however even after it was deployed the app was still throwing this error, which made me now think the wildcard initiator doesn’t work as intended.

It turns out that not only does your crossdomain need to have the allow access from node, if the page and requested data use different protocols that a secure attribute must be added.

When your application is in HTTP and you want HTTPS data use:

WHen your application is in HTTPS and you want HTTP data use:

There are times when it becomes important that we step back from our work to really understand when / where / how patterns are applied. However, where I think many of us fall short, is more importantly is when NOT to.

Like any great pattern that is meant to simplify and organize, they can abused and overused. Remember, a pattern is really nothing more than a general solution to a particular problem set that has been previously solved. So for many cases, this is a godsend, because it means less time can be spent on the implementation and more time can be spent on the UI, aesthetics, and over all product improvements. (more…)

Depending on your specific responsibilities, in most cases, most of us programmers do not have to hash out the ideas of what becomes an effective design or work flow in the project or product of what we work on. Thankfully. However, if it is, then the following becomes a lot more common: where Engineering will say to Marketing, this idea just isn’t going to work and we’ll need another 2 weeks further from our already tight deadline. OK so I’m not dealing with any sort of hard deadline other than just wanting to have some sort of completion to the first stage, I did have to go back and come up with ‘a better way to use things.’ Notice I didn’t say ‘do things.’ (more…)

Flex 2 Development Guide (PDF): Styles : Pg 742

This one I know gets missed.A LOT. The key here is if you want set styles dynamically where it’s dependent upon conditions or states, the key is not to use the creationComplete event instead use preinitialize. This becomes even more true if the styles you set are on components that are either at or near the root level of the application tree.

Now for the majority of the application that only needs to be styled at startup, the best approach is similar to the way most Web Designers / Web Developers take the approach of style sheets: external or otherwise. Now if you use external css like I do, and your intent is to allow others either recompile your source (developers, enhancers) or dynamically pull from a well-known style sheet (application users), be nice and not only organize it but add comments as well where needed.

A common mistake that impacts performance is overusing or unnecessarily using the setStyle() method. In general, you only need the setStyle() method when you want to change styles on existing objects. Do not use it when setting up styles for an object for the first time. Instead, set styles in an

block, through an external CSS style sheet, or as global styles. It is important to initialize your objects with the correct style information, if you do not expect these styles to change while your program executes (whether it is your application, a new view in a navigator container, or a dynamically created component). Some applications must call the setStyle() method during the application or object instantiation. If this is the case, call the setStyle() method early in the instantiation phase. Early in the instantiation phase means setting styles from the component or application’s preinitialize event, instead of the creationComplete or other event. By setting the styles as early as possible during initialization, you avoid unnecessary style notification and lookup. For more information about the component startup life cycle, see Chapter 6, “Improving Startup Performance,” in Building and Deploying Flex 2 Applications.

Arrays: every, filter, map, some

Nearly all callback methods to a filter-based method only specify that the type of object to be inspected be of type Object. While this certainly allows for the greatest flexibility in what is stored in the ordinal list, this doesn’t give you much control over chasing down RTE’s or allow for IDE ease of use in auto-completion. (more…)

One of the things that I’ve noticed with the SDK that is hit or miss, and can probably be attributed to a slew of different developers working on various aspects, is most event handlers are written in the private space especially if it’s a top level component.

This is not good design especially in light of the news that Adobe has announced it will make the SDK apart of its open source initiative with staring with Flex 3. The simple reason why is extensibility. Most projects are made up of at least 1 and probably up to several dozen custom components that extend off the SDK architecture. FlexLib is a prime example of this. With privatized event handlers, this makes it impossible to write an extended object that needs to intercept and enhance a given event. Duplicating the event by assigning the same event to a different handler achieves a work around however this essentially only adds overhead and to the overall confusion of trying to keep track of duplicated events.

Writing the handler to the protected space is a far better solution. It offers the same security protections of not allowing other objects to mistakenly execute the method, but allows the integration of an event hierarchy to become seamless. It also gives one added underrated benefit: event polymorphism. The encapsulating owner now has conditional execute privileges over the super method, which gives rise to writing controllers a lot easier to manage.