The infamous callLater()

At my first posts I wrote about my favorite Flex feature: Databinding
Now I will take a look at the opposite, IMHO the most precarious “feature” in Flex: callLater()

If you have a dodgy problem that a certain property is not available when it already should be and you ask someone at flexcoders you often get the advice, “try callLater” for a quick work-around. Sometimes this helps, but it leaves a bad smell, because often it´s just hiding some other problems in the code.
So when we worked on a large-scale Flex application we have used it sometimes in the beginning, but after a while we decided to avoid callLater. To find and solve the real problem is simply the better solution – and we never needed it again – there was always another solution to solve a particular problem (maybe we just have had luck).

Unpleasantly we get confronted with the fact that callLater is used inside the Framework at the heart of the layout engine.
We struggled with some strange problems. For instance we got a NullPointer exception in the updateDisplayList method of a custom component, which has already been cleaned up properly and removed from the displayList. It turned out that the layout mechanism delayed with callLater an invocation of updateDisplayList but our stuff there has already been removed and threw an exception.
It was not hard to fix, but it demonstrated us that some asynchronous stuff was going on behind the scenes which was out of our direct control.

So for me callLater leaves always a certain bad smell.

Unfortunately I never found time to really investigate how it´s implemented and what are the concepts behind it.
So it was time to catch up with this issue:
CallLater is basically a method in UIComponent which delays a passed function to the next EnterFrame OR Render event.
Often in den docs it´s just described that it will delay to the next frame, which is not correct because it could be that your function is executed already at the Render Event, which happens in the same frame and is the last opportunity where User code can be executed before the screen is rendered.

For more details about the internal concept of a frame in Flash and the relevant events see the great article by Sean Christmann:

Here is a good illustration from his article about the anatomy of a frame in Flash:

All functions passed to callLater are queued up in an array and are executed at the EnterFrame event or Render event. It is possible that the executed function has some other callLater invocations again, so the final execution sequence could be delayed over several frames.

CallLater is used inside the Flex Framework in several classes. The main use case is probably inside the LayoutManager.
There is a concept called phased instantiation which means basically that at application start-up the 3 phases in the UIComponents life-cycle (validate properties, validate size and validate displayList) are not executed in one pass, but are delayed with callLater to 3 half-frames. Half-frame because the Render event happens in the same frame as the EnterFrame event.
This should reduce performance peaks at application-startup and should increase the UIs responsiveness.
You can also use it later on in your application if you have to render heavy stuff, to balance the load across frames.

So far so good. But…
First let me emphasis that I am sure that the SDK architects has had some good reasons for implementing callLater, but it introduces an asynchronism which could be hard to control. Normally with async stuff you have an event driven approach, so you get informed when the async task is done.
With callLater it´s not so clear when the last callLater is really finished. There is an UpdateComplete event in UIComponent and LayoutManager which helps to get informed when the last callLater is executed, but in-between, you don´t have control about the distinct moments of your function calls.

Another issue is that you cannot control if your heavy load is really spread over 2 frames. It could be that it is just executed inside one frame at the EnterFrame event and at the Render event, so it could be that you don´t win anything from the load-balancing perspective.

Performance-wise there could also be perceptible delays caused by repeatedly callLater executions.

I guess there are many special situations in the framework code (probably mostly measurement stuff) which are difficult to handle, but i guess it should be possible (maybe I am too optimistic?).

There seems to be a problem to get the correct measurement when you set a new text in a TextField before the frame is actually rendered (see this post at flexcoders), but if this is an unsolvable problem then it should be urgently fixed in the Flash Player.

References@livedocs:
callLater()
usePhasedInstantiation

Comments (4)

Category: Actionscript,Flash,Flashplayer,Flex,SDK

Sorry, the comment form is closed at this time.