Tag: Flex

Specifying headerColors for Actionscript Alert in CSS

spentroseandhip003

 

Simple idea – you want Alert pop-ups in Actionscript to have a header color that is different from the default (which is same color as the background).  The only difficulty comes in knowing the correct syntax, because two colors are necessary.  They can be the same color if you just want a solid color, or two colors if you want one color to fade into the other.  These two colors get converted to an array at run-time.

After trying various combinations with and without quotes, square brackets, squiggly brackets, I finally got the correct syntax.  So just writing it down here to keep track.

mx|Alert
{
dropShadowEnabled: true;
headerColors: blue, blue;
headerHeight: 20;
}

It’s just a comma-delimited list of two colors – no quotes or brackets or anything fancy.  Also the numeric red green blue values may be used instead of color keywords.  The first color in the list is the top of the gradient; the second the bottom.

By the way a low-tech way to get the RGB value of a color is to copy something with that color into Paint, and then use the dropper tool to select the color, then click on “Edit colors”.

 

Advertisements

Debugging BlazeDS Performance

raindropsonrosebud I have a server call that returns a lot of data to the client.  About 80% of the elapsed time for the call is the time after the data leaves the server and before it arrives at the client.

We’re using BlazeDS to communicate between a Flex client and a Java back end.

It is crazy hard to find much information on performance tuning for BlazeDS.  But these two blog posts helped me figure out how to get some statistics about the messaging between server and client – things like elapsed time, size of message, etc.

So basically what you do is, on the server side in your services-config.xml file, in the tag of your tag, you add these two tags:

 <record-message-times>true</record-message-times>
 <record-message-sizes>true</record-message-sizes>

Then on the client side, when you instantiate a new AMFChannel, you add a line like this:

applySettings(customSettings());

And add a new function called customSettings which sets the values for these same properties on the client-side.

 private function customSettings():XML {
 return <channel-definition>
 <properties>
 <record-message-times>true</record-message-times>
 <record-message-sizes>true</record-message-sizes>
 </properties>
 </channel-definition>;
 }

Doing it this way gets around the problem of them being read-only properties.

Now, upon successful completion of service calls, add this code to your result handler:

log.debug(getResource(msg, destination, operationName, elapsedTime)); var performanceDetails:MessagePerformanceUtils = new MessagePerformanceUtils(event.message); log.debug(performanceDetails.prettyPrint());

More information on MessagePerformanceUtils here: http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/mx/messaging/messages/MessagePerformanceUtils.html#methodSummary

What this does is get you a bunch of information to help with figuring out why the call is taking so long.

Original message size(B): 1685
Response message size(B): 6987918
Total time (s): 8.402
Network Roundtrip time (s): 3.584
Server processing time (s): 4.818
Server adapter time (s): 3.708
Server non-adapter time (s): 1.11

Don’t leave this in your production code.  You’re trying to improve performance, not make it worse!