:cubicleman.com

Good to see that AIR ‘gets around’. Lifehacker recently listed out 10 apps you should check out.
Top 10 AIR Apps Worth Installing

peas

DK

So, as I continue my trek in Flex Builder Profiler land I discovered a interesting one. Say you have a List used in some component and this List uses a custom itemRenderer and this fancy custom itemRenderer you cooked up uses a inline Style. You crank your application up and with that silly attempt at a sly smile, pat yourself on your back. Then you click that button you have in your app that removes a instance of this component from the display list, yeah, you are working on a pod-like system here, eh? Thinking nothing of it you continue along the trail of happy codeness, that is until you start profiling that app in your most favorite FB Profiler tool. WTF? Your List is never GC’d? I can add 10 of these in the UI as a result of mashing this fancy ‘add new pod’ button and even though that fancy ‘delete me now’ icon, which calls removeChild(), is mashed 10 times, the 10 pods are still hanging out in memory? Yup, shocked me too, actually a good shock as I was falling asleep in front of these memory graphs…hehe.

Assuming my coffee is not laced with the usual ‘make me stupid’ sauce, I filed a bug. Check it out here https://bugs.adobe.com/jira/browse/SDK-15861

peas

DK

I am currently working with a client doing performance profiling and adjustments for a medium sized application. After using the profiler in Flex Builder, a painful experience for me not having worked with such a animal, I found a area that was exhibiting a major memory leak. Well, maybe memory leak is not the correct term, a certain area of the application had a view stack that would add children to it. The user could then remove the children. This removal never released memory. In other words a removeChild() removed the child element, but since the child had some external references to it, this child was never garbage collected.

Now, a few hours digging in the memory profiler didn’t help me find where the nastiness was happening, more on that later maybe. Anyone out there care to shed some tips on this?

Recalling Jun Hieder’s presentation at 360|Flex Atlanta, I started digging into event listener additions, these guys can add a case of the nasties to the situation. That’s when I stumbled upon the use of BindingUtils.bindProperty. The basic approach was that a class A had a property bound to a property in class B using BindingUtils.bindProperty in a util class. This added a hard reference to A in this case, which would keep A from getting GC’d if need be.

This begs the question, why use this? The need here was to inject data into B from A. Probably better to say use A.property = B.property in A or a third party class. If you need it to change at runtime dynamically, have A dispatch a event that can be heard and reacted to, passing the data in the event along the way.

I have attached a sample application that displays the characteristics described above. Use the profiler in Flex Builder to see what happens after manually running a GC. You can grab it here BindingUtils Test

off to refactor!

peas

DK

So, I’m working with a client doing some development and mentoring. A piece of this is implementing the Cairngorm micro-architecture and mentoring duties surrounding this. The client’s developers made full use of the new WSDL import tool in Flex Builder 3 and are really sold on using it. Now, for those not paying attention here, the title did mention Flex Builder’s magical WSDL tool, Flex builder 3 has this really neato, down-and-dirty, quick-and-easy WSDL tool. Look under the Data menu item and choose Import Web Service(WSDL). You’ll get a little wizard GUI where you pick the project and source folder to put the code in, enter a WSDL location, choose what methods in the WSDL you want to include in the magical WSDL import tour, mash a button, and sit back and enjoy. After its done, take a look at the code generated…holy FSCK Batman!!!! Yeah, a whole butt load of code is generated. Totally bad ass, eh? Unfortunately its all generated in one folder, VOs, Events, service, etc. But hey, you can’t have it all in a badd ass world! So, how to use it?

You should see a file called something like Admin.as in there where mainclass is the name of the main class you supplied to the UI wizard a moment ago. Open this file up and you will see a example of how to use the code. As a added touch, the example actually uses one of the real WSDL methods! In AS its three lines of code looking like this
var myService:MyAdmin= new MyAdmin();
myService.addGetSessionEventListener(myResultHandlingFunction);
myService.GetSession(myUserName,myPassword);
where GetSession() is a method in my WSDL. That’s it! Uber kewl eh?

So, in just a few seconds your complete Service layer is written. To add more icing to this cake, all the service calls return TYPED OBJECTS FOR YOU! The type is based on your WSDL scheme. Thus you literally need only bolt on your UI and voila, impress your boss.

The downside: as this code is generated and we live in such a API imperfect world, you may have to regenerate it from time to time when your WSDL changes. So, you can’t really modify the code without worrying about maintaining it. Sure, in some cases you can play extend the class, but not always as some things are private Private! Like most magical gen tools, in my experience, they are always a canned solution. Meaning, they are designed to do one thing, not all the things your client may want. In this case though, things seem pretty cool as its the Service layer after all.

But wait! There’s more? Does it chop and shred lettuce too? ha, afraid not, but there is more. Most likely you will be using a framework in your app and most likely it will be Cairngorm, eh? I know, a bit jaded. So, how to tie in this code to Cairngorm use? Use the Delegate baby! In the generated code, find a file named BaseAdmin.as. This is the low-level layer in the code that handles the actual web service calls. Each method in here actually returns a AsynchToken, yo uknow that class your Delegate likes to work with. Thus we have code in our delegate like so
var service:BaseMyAdmin = new BaseMyAdmin();
var token:AsychToken = service.getSession(username, password);
prepareResponder( token, resultHandler, faultHandler);
you that’s it folks. I’m willing to bet the other frameworks out there PureMVC, ARP, Mate, etc… all work with tokens at this level, so should be just as easy.

To recap, we have a quick and easy way to work with webservices and your favorite framework with two major gains:

1. Typed Objects from WSDL calls
2. Time Savings

Others may see more benefits, but these are key to me, #1 especially as I don’t have to manually parse through XML creating typed objects.

back to coding!

peas

DK

Ok, so I’m no CSS Zen master, far from it actually. The thought of creating good CSS that is cross-browser supported and all just makes me shiver. I had to look at something today concerning links with fancy image backgrounds and rollovers that tweaked this image. After some quick googling, I am a card carrying member of the Google Brain Club, I found this neat article on A List Apart on something they call CSS Sprites. Wow, what a cool deal. Basically you use a single image for all of your links and just reposition this image as a background. What does this gain? Well, for starters only one image needs to be loaded or preloaded. Sure, this one image may be bigger than a single one of the single link backgrounds, but the composite is likely to be smaller and take only one request. It might very well fall into the same number of packets as a single one too depending on image compression and such.

So, how to pull it off? I’ll go over a quick single link example. First, fire up Fireworks (can you tell I’m not a real graphics guy? :} ) and create your two link, or button, states. Here is a sample:

Now, use some simple CSS magic:
#outerCont {top:0px; left:0px; background: url( images/button_states.gif ) 0 0 no-repeat;}
#outerCont a:hover { background: url( images/button_states.gif ) -200px 0 no-repeat;}

Here is a sample page showing it in action:
button_states.html

Back to our regularly scheduled Flex/Air fun!

peas
DK

When creating custom components it is better to defer any processing in your mutators(read setters) to the validation phase(s) of the Flex framework. This can be beneficial for many reasons such as performance, timing, etc. Consider the possibility that x gets set before y but that x needs y when x is set at runtime when you have no control over when these get set due to asynchronicity or some such. Also, it can cut down on the use of bindable variables, a performance bottleneck.

Enter the Flex component life cycle. I’m not going to cover the whole life cycle, but suffice it to say that in the life of a component it can enter a invalidation/validation phase. Flex uses these phases to synchronize changes. Note that this entrance is not necessarily a one-time thing either. So how do we make use of this? One approach is to use a method called invalidateProperties(). This tells the SDK that during the next cycle of the circle of life for the component to call commitProperties(). We do not call commitProperties() directly, rather we let the Flex SDK do that. Hence the notion of invalidation and validation phases. Ok, some code!

This is a typical pattern for coding a mutator in your component for a property called zinger:
//a flag to flag changes, this makes the circle of life more efficient
private var:Boolean zingerChanged;
//the actual var stuff
private var:int _zinger;
public function set zinger(val:int):void {
if( val != _zinger) {
_zinger = val;
zingerChanged = true;
invalidateProperties();
}
}
public function get zinger():int {
return _zinger;
}
//now overrride
override protected function commitProperties():void {
super.commitProperties();
if( zingerChanged ) {
zingerChanged = false;
//do your logic and such here concerning a change in zinger
}
}

Ok, there you have it. Aside from some possible typos, that should get you on your way to better performing components.

Cheers!

DK

We’ve let loose our extensions to the Cairngorm micro-architecture. Have a look and enjoy!
http://code.google.com/p/flexcairngorm/

Jeffry Houser has invited Thomas Burleson to his show to discuss them. You can give it a listen here

DK

Andrew Trice has a really nice sample and write up of using the Drawing API. The sample allows you to write your own code and try it out live. The sample comes with several code examples to choose from that you can also edit and try out live. Check it out over on InsideRIA

Try Drawing API with out Compiling

peas
DK

Check itout, next week is another Adobe Developer Week. What is it? A week of online presos via Adobe. Topics range from CF8 to Flex to BlazeDS. Enjoy!

Adobe Developer Week

peas

DK

Tonight I will be presenting on Flex Debugging at the Atlanta Flex and Flash User Group. I will be covering topics like using the debugger in Flex Builder, using a man-in-the-middle tool like Service Capture, using trace(), mx.logging, and more. Did you know Aptanta has a tail view? neat.

If you are in the Atlanta area, drop in and check it out. If not, below is a link to the presentation. There is a chance it will get recorded too. There are issues with using a proxy tool like Service Capture while using Connect, but I am to try using a VM to run this and see. Stay tuned!

Flex Debugging Presentation Slides

The Connect Recording which is listed among others at UGTV

peas

DK