firstrow RIA

[AS3] Application wide event broadcasting

Bernd — Tue, 04 May 2010 21:46:09 +0000

Sometimes you need the ability to send events “through” the entire application. This can be useful, especially when you have a module-based architecture.

Imagine following situation: Multiple modules, one of them is periodically checking some server state. If this module detects an important change, maybe the user has logged out on the server side, or whatever, the other modules need to know about that change. So we need a component that broadcasts this change and anybody who is interested in that change listens for it. The change is broadcasted via Flash-Events and for the broadcasting itself, there is already the EventDispatcher. So the idea is to build a class that is simply holding a private static instance of an EventDispatcher and provides a dispatchEvent and addEventListener function, just like the EventDispatcher itself does.

package com.firstrowria
{
import flash.events.Event;
import flash.events.EventDispatcher;

public class GlobalEventBroadcaster
{

private static var dispatcher:EventDispatcher = new EventDispatcher();

        public static function addEventListener(type:String, listener:Function, useCapture:Boolean = false, priority:int = 0, useWeakReference:Boolean = false):void
        {
            dispatcher.addEventListener(type, listener, useCapture, priority, useWeakReference);
        }

        public static function removeEventListener(type:String, listener:Function, useCapture:Boolean = false):void
        {
            if (dispatcher)
                dispatcher.removeEventListener(type, listener, useCapture);
        }

        public static function dispatchEvent(event:Event):void
        {
            if (dispatcher)
                dispatcher.dispatchEvent(event);
        }

}
}

That’s it, dispatch and listen to your own Events as you need it. Since this is a very simple approach there is a lot of space for improvements. Just a few ideas:

Channel support. Could be a huge improvement when you have a lot of listeners already
Store the current listeners in an array so the removement of all listeners at once for a specific event is possible
Check if there are listeners for a specific event, if not, do not dispatch the Event since this is ridiculous slow and totally useless
Remove the possibility for weak references in the addEventListener function. More info on this topic? See Joe Berkovitz’s blog entry why weak references can be dangerous

[AS3] Introducing the OddFormatter class

Bernd — Thu, 28 Jan 2010 19:27:19 +0000

If you need a formatter that supports the European, British and even American odd format, have a look at the following piece of code. If you have no idea about the different formats you might check the Odd Article on Wikipedia first.

Please note that for the UK format, the odd is always converted to the lowest possible term. Wikipedia says that 3/2 is usually represented as 6/4, 10/3 is 100/30, but I’m pretty sure that this is not commonly used, at least for the online bookmakers where the odds are automatically converted in the different formats.

You can also download the source here.

As usual, this code is free, use it wherever you want

package com.firstrowria.formatters
{
   public class OddFormatter
   {
      public static const EU_FORMAT:uint = 0;
      public static const US_FORMAT:uint = 1;
      public static const UK_FORMAT:uint = 2;

      public static function format(v:Number, f:uint = 0, c:String = “,”, p:int = 2):String
      {
         var formattedValue:String = “”;

         if (f == UK_FORMAT)
         {
            var hundretValue:Number = Math.round(v * 100) – 100;
            var ggt:int = ggt(hundretValue, 100);
            formattedValue = (hundretValue / ggt) + “/” + (100 / ggt);
         }
         else if (f == US_FORMAT)
         {
            if (v >= 2)
               formattedValue = “+” + Math.round(100 * (v – 1));
            else if (v == 1)
               formattedValue = “-0″;
            else
               formattedValue = “” + Math.round(100 / (1 – v));
         }
         else if (f == EU_FORMAT)
         {
            formattedValue = v.toFixed(p)
            if (c != “.”)
               formattedValue = formattedValue.replace(”.”, c);
         }

         return formattedValue;
      }

      private static function ggt(u:int, v:int):int
      {
         return ((u > 0) ? ggt(v % u, u) : v);
      }
   }
}

[AS3] Precise Timer approach #1

Bernd — Thu, 24 Sep 2009 12:00:08 +0000

If you need to implement a ordinary countdown in your Flex/AIR or plain Flash application there is no way around the Flash built in Timer (flash.utils.Timer, since 9.0). Unfortunately this Timer isn’t accurate, not even close. Even worse, the longer it runs, the more it will be off time. Traced out the first 20 seconds of a simple Timer which fires every 1000ms, we are 1800ms off!

1001
2110
3262
4340
5583
6678
7757
8836
9908
10986
12081
13149
14235
15312
16383
17460
18543
19633
20712
21837

So I did some tests with setInterval, a hangover function from AS2, which lead me to the same result. Since I needed a timer that runs accurate my idea was to calculate the gap on every cycle and adjust the internal timer. Use it just like the normal Timer.

package
{

import flash.events.EventDispatcher;
import flash.events.TimerEvent;
import flash.utils.Timer;
import flash.utils.getTimer;

public class PreciseTimer extends EventDispatcher
{

private const INSPECT_TIME:int = 100;

private var _timer:Timer;
private var _startTime:int = 0;

private var _delay:int = 0;
private var _repeatCount:int = 0;
private var _continueForever:Boolean;

public function PreciseTimer(delay:int, repeatCount:int)
{

_delay = delay;
_repeatCount = repeatCount;
_continueForever = repeatCount <= 0;
init();

}

private function init():void
{

_timer = new Timer(INSPECT_TIME, 0);
_timer.addEventListener(TimerEvent.TIMER, onTimer);

}

public function start():void
{

_startTime = getTimer();
_timer.start();

}

public function stop():void
{

_timer.stop();

}

private function onTimer(event:TimerEvent):void
{

var timer:int = getTimer();
var durations:int = timer – _startTime;

if (durations > _delay)
{

if (_continueForever)
{

dispatchEvent(new TimerEvent(TimerEvent.TIMER));

}
else if (_repeatCount -- == 1)
{

stop();
dispatchEvent(new TimerEvent(TimerEvent.TIMER));
dispatchEvent(new TimerEvent(TimerEvent.TIMER_COMPLETE));

}
else
{

dispatchEvent(new TimerEvent(TimerEvent.TIMER));

}

_startTime = timer – ((durations – _delay))

}

So far, so good, here are the figures. For my purposes, this is close enough!

1093
2044
3069
4003
5025
6077
7044
8054
9002
10070
11116
12022
13040
14084
15003
16046
17049
18094
19020
20056

[AS3] Let’s LOOP FOR a WHILE, a short performance comparison over loops in Actionscript 3

Bernd — Wed, 22 Jul 2009 22:40:36 +0000

Months ago someone pointed me at Joa Ebert’s wiki, which has a interesting category: Code Optimization. In this post I want to test some performance statements made in the loop article

I tested for and while loops with different data types (uint and int, Number is 4-5 times slower) and counting mechanisms (i++ or ++i), with and without accessing the counter variable. All loops had 268435455 (int.MAX_VALUE/8) iterations on my tripple core 2,1Ghz machine, 32bit WinXP, Flash player 10. The y-axis shows us the average time in milliseconds of at least 10 iterations. The highest and lowest value is not included.

We can see that for is faster than while. Why? Well .. I just don’t know, if you have any idea, please leave a comment!

So the fasted two loops, nearly head to head, were:

//for uint i++
private function f1():void
{

var i:int = 0;

var n:int = int.MAX_VALUE/8;

for( i = 0; i < n; i++ ) { }

}

//for int ++i
private function f3():void
{

var i:int = 0;

var n:int = int.MAX_VALUE/8;

for( i = 0; i < n; ++i ) { }

}

Then I took a closer look on the for loops. Why is the ordinary loop with int as data type and i++ value increase slower?

What if the loop body is not empty and the value of the counter is needed? Well, here are the results. At this time 17895697 (int.MAX_VALUE/120) were enough.

Ok, now we are nearly at the same level, regardless of which data type or counting style is used. The only (negative) abnormality is the uint while, which is about 9% slower than the fastest loop.

Here we have the slow performer:

//while uint –n
private function f8():void
{

var i:uint = 0;

var n:uint = int.MAX_VALUE/120;

while( –n >= i )

{

}

Conclusion: It’s totally up to you which loop you prefer (if you have to access the counter variable). For me I will continue to use the ordinary for loop, just like I ever did.

[Flex] Top 5 memory leaks in Flex, #5:

Bernd — Fri, 13 Mar 2009 10:23:30 +0000

Issue: When using states in mxml, components that have been added with the tag, can not be cleanly removed and therefore they stuck in memory

Tested version: Flex Milestone 3.2

Workaround: Unfortunately there is none. Either you do not use States any more or you compile your own Flex-SDK and fix the classes DeferredInstanceFromFunction and DeferredInstanceFromClass, which holds instances of your added component, even when the corresponding state is not active any more. Another possibility would be to create your own AddChild class that does not use the DeferredInstance classes, see Nick Bilyk’s blog post: Flex states retaining memory

Note: These is the (shortened) source code of DeferredInstanceFromClass (nearly same source in DeferredInstanceFromFunction), where I’ve highlighted the retained reference to the instance that has been created. I have no idea why they store the instance in a private variable, must be some performance intentions.

package mx.core
{

public class DeferredInstanceFromClass implements IDeferredInstance
{

[..]

private var instance:Object = null;

/**
* Creates and returns an instance of the class specified in the
* DeferredInstanceFromClass constructor, if it does not yet exist;
* otherwise, returns the already-created class instance.
*
* @return An instance of the class specified in the
* DeferredInstanceFromClass constructor.
*/

public function getInstance():Object
{

if (!instance)
instance = new generator();

//this should be: return new generator();
return instance;

}

[Flex] Top 5 memory leaks in Flex, #4: effects

Bernd — Mon, 23 Feb 2009 17:01:23 +0000

Issue: Running effects prevent components from being garbage collected

Tested version: Flex Milestone 3.2

Workaround: Call end()-method of effect before removing the component.

Note: This example consists of 2 files and extends the example from the previous post by a simple effect. The main application (nothing changed here), seen in the first box, adds the self made-component from box 2. It uses a move effect, that restarts automatically and a timer to demonstrate how this combination could lead to memory leaks. Like in the previous blog post, it is also necessary to nullify the component after removing it from the display list, otherwise it will remain in memory, even when listeners are correctly removed and effects are not running any more!

private function remove():void
{

myComponent.destroy();
removeChild(myComponent);

//IF NOT NULLIFIED, then no garbage collection!!!
myComponent = null;

}

]]>

package
{

import flash.events.TimerEvent;
import flash.utils.Timer;
import mx.controls.Label;
import mx.core.UIComponent;
import mx.effects.Move;
import mx.events.EffectEvent;

public class MyComponent extends UIComponent
{

private var myTimer:Timer;
private var myMoveEffect:Move;
private var label:Label;
private var i:uint = 0;

public function MyComponent()
{

label = new Label();
label.setActualSize(100,20);
addChild(label);

myTimer = new Timer(100,999);
myTimer.addEventListener(TimerEvent.TIMER, onTimer);
myTimer.start();

myMoveEffect = new Move();
myMoveEffect.addEventListener(EffectEvent.EFFECT_END, onEffectEnd);
myMoveEffect.duration = 3000;
myMoveEffect.xBy = 100;
myMoveEffect.play([label]);

}

private function onTimer(event:TimerEvent):void
{

i++;
label.text = i.toString();

}

private function onEffectEnd(event:EffectEvent):void
{

if (myMoveEffect.xBy > 0)

myMoveEffect.xBy = -100;

else

myMoveEffect.xBy = 100;

myMoveEffect.play([label]);

}

public function destroy():void
{

if (myTimer)
{

myTimer.removeEventListener(TimerEvent.TIMER, onTimer);
myTimer.stop();

}

if (myMoveEffect)
{

myMoveEffect.removeEventListener(EffectEvent.EFFECT_END, onEffectEnd);
myMoveEffect.end();

}

[Flex] Top 5 memory leaks in Flex, #3: event listeners

Bernd — Fri, 06 Feb 2009 23:33:00 +0000

Issue: Open listeners prevent components from being garbage collected

Tested version: Flex Milestone 3.2

Workaround: Add and remove listeners by yourself. Implement somekind of destroy-function, that clears all listeners. Other possibility is to use weak references when adding listeners. For further information see this blog post from Ted Patrick: useWeakReferences:Boolean = false

Note: This example consists of 2 files. The main application, seen in the first box, adds the self made-component from box 2. It uses a timer to demonstrate listener functionality. If the timer is still running, it is stopped and the event listener is removed manually. It is also necessary to nullify the component after removing it from the display list, otherwise it will remain in memory, even when listeners are removed correctly!

private function remove():void
{

myComponent.destroy();
removeChild(myComponent);

//IF NOT NULLIFIED, then no garbage collection!!!
myComponent = null;

}

]]>

package
{

import flash.events.TimerEvent;
import flash.utils.Timer;
import mx.controls.Label;
import mx.core.UIComponent;

public class MyComponent extends UIComponent
{

private var myTimer:Timer;
private var label:Label;
private var i:uint = 0;

public function MyComponent()
{

label = new Label();
label.setActualSize(100,20);
addChild(label);

myTimer = new Timer(100,999);
myTimer.addEventListener(TimerEvent.TIMER, onTimer);
myTimer.start();

}

private function onTimer(event:TimerEvent):void
{

i++;
label.text = i.toString();

}

public function destroy():void
{

if (myTimer)
{

myTimer.removeEventListener(TimerEvent.TIMER, onTimer);
myTimer.stop();

}

[Flex] Top 5 memory leaks in Flex, #2: skinning of components, e.g Button

Bernd — Wed, 07 Jan 2009 19:59:33 +0000

Issue: Embed skins does not get removed and stays in memory

Tested version: Flex Milestone 3.2

Workaround: Clear the style by yourself by setting the styleName property to null

Note: See the example how to clear the style exactly. Download the style swf here to get this application working. This probably works with every skinable component. ~~Be aware that every skin you define in css has to be cleaned~~ You can clean all skins at once with styleName=”null”

private function remove():void
{

/*
myButton.setStyle("overSkin", null);
myButton.setStyle("upSkin", null);
myButton.setStyle("downSkin", null);
*/

//better and faster version than above
myButton.styleName = null;

removeChild(myButton);

}

]]>

.myButton
{

over-skin:Embed(source=”button.swf”, symbol=”buttonover”);
up-skin:Embed(source=”button.swf”, symbol=”buttonup”);
down-skin:Embed(source=”button.swf”, symbol=”buttondown”);

}

[Flex] Top 5 memory leaks in Flex, #1: background-image in containers

Bernd — Wed, 07 Jan 2009 18:11:09 +0000

I know, I’ve been lazy in blogging in the last months, but this is changing now. I was involved in a huge Flex3 project (not allowed to name it right now). The size of the application made it impossible to develop in a classical way, so the team decided the following points:

Build a own lightweight framework that fits our needs in widget handling
Build components from scratch by extenting UIComponent and handle the life-cycle by ourselfs
Do not use flex components if not necessary, this also includes containers, e.g. boxes
Use MVP Pattern
CodeBehind Classes for enabling inheritance in MXML

and in general:

Save performance wherever possible
Save memory wherever possible

In the end stage of the project we had to deal with several memory leaks, so we started to investigate in this topic. With help of the Flex Builder Profiler (see this link how to use the profile) we could identify the leaks and solve most of them. This and following posts point out the top 5 memory leaks, starting with the most common leak we had.

background-image in containers

Issue: Background image stays in memory after removing container from display list

Tested version: Flex Milestone 3.2

Workaround: Clear the style by yourself

Note: See the example how to clear the style exactly. Choose any background image you like. This also works with every container not just Canvas, e.g HBox, VBox,..

Adobe Bug: SDK-1893

private function remove():void
{

//has no effect
//myCanvas.clearStyle("background-image");
//myCanvas.clearStyle("backroundImage");
//myCanvas.setStyle("background-image",null);

//works
myCanvas.setStyle("backgroundImage",null);
removeChild(myCanvas);

}

]]>

.myCanvas
{

background-image: Embed(source=”bgImage.jpg”);

}

[AS3] Accessing private/protected properties via wrapper or mx_internal

Bernd — Sun, 10 Aug 2008 20:29:26 +0000

Ever wanted to access a private or protected property of a class, for example the internal flash.text.TextField of an Label?

Since the textField is protected you have the option of extending the class and create a wrapper class as seen in the following lines:

package com.firstrowria.mxInternal
{

import mx.controls.Label;
import mx.core.IUITextField;

public class WrapperLabel extends Label
{

public function WrapperLabel()
{

super();

}

public function get internalTextField():IUITextField
{

return super.textField;

}

But there is another method, the usage of an internal namespace mx_internal. The only requirement is that the function/property has to be marked. If you step through the source of the Label component you can see that the textField property itself is not in this namespace but there is a function getTextField which is.

This is an quick example, which demonstrates the things that need to be done:

import mx.core.IUITextField;
import mx.core.mx_internal;

use namespace mx_internal;

private function bla():void
{

var tf:IUITextField = myLabel.mx_internal::getTextField();

}

Make sure that you first do the import (it should also be the last one). Please note that there is no code hinting in Flex Builder when using this method of accessing functions/properties.