Flex

   Most of us are familiar with CPU consuming problem in Flash applications. There are cases, when you have nothing to do with, but in few cases you can use well known solution – cacheAsBitmap. It prevents object re-rendering in case a shape and content are never changed.



  There is a case when caching of Sprite object doesn't always solve the problem. What if your sprite contains different types of elements and all elements are static (no shape or position changes)? Does caching as bitmap of the Sprite will help to improve object rendering performance? The answer is yes, but there is a little nuance.

vladislavm 16/03/2011 - 01:23

Hey guys,

 

Few notes I took from the Yakov Fain lecture that took place last week:

 

When loading modules: you don’t have to load RSL in the main app, only link it as such to the module itself

 

Merge into Code – Yakov reminded us that in this linkage option, only classes I used will be compiled into the swf

 

Fonts slow the compilation – so always compile your css which embed the fonts as a separate SWF file, and load it dynamically.

 

Preloader as a flash content  – In his book “Enterprise flex application” he gives and example of using a flash preloader swf who looks like the initial login page in your application, and on the background he loads the rsls while the user verify his details.

 

shair 07/02/2011 - 15:38
I have a situation, where I have 2 internal properties, with the relevant setter/getter functions (say _a + aChanged, _b and bChanged).
Each setter calls invalidateProperties if the value has changed.
 
sefi 20/09/2010 - 07:22

Lately I was dealing with a massive refactoring effort in a large scale application. I desperately needed a way to understand the code flow before and after the refactor.

Using the debugger is quite exhausting, and besides, looking at stack trace at a certain point does not reveal the full path of nested calls the runtime went through.

The ideal visualization would be a sequence diagram describing code execution.
Looking for a solution, I discovered several tools that provide this exact functionality.
Enterprise Architect and Architexa are two of them.
 

But alas, none of those supports actionscript.

ilan 05/08/2010 - 12:10

In previous posts in the series we discussed new features in Flex 4 that are basic in nature (namespaces, an introduction to the new Spark components architecture and the new mxml tags to name a few).

In the next few posts we will discuss the more interesting stuff new with Flex 4 like FXG, states, layouts, effects and skinning.
So, without further ado, View States!

 

sefi 29/06/2010 - 08:56



In the current application I am working on, we are using a Flex client that communicates with a Web service on the server side. The client's VOs are automatically generated.

One of the things that bothered me in that model is – how can I implement polymorphysm in this model?

 

Let's assume that in the wsdl there is a complex type A.

Two types extend it (using xsd:extension) – B1 and B2.

yoav.moran 24/06/2010 - 08:49

Flex 3 had some language tags we are all familiar with like <fx:Binding>, <fx:metadata>, <fx:script> and <fx:style> to name a few.

Flex 4 introduces some new mxml tags you can use when writing mxml classes. They are <fx:Declarations>, <fx:Definition>, <fx:Library>, <fx:Private> and <fx:Reparent>.

 

sefi 14/05/2010 - 09:00

While the Flex 4 SDK includes the MX component architecture provided with previous releases of the Flex SDK (mainly for backwards compatibility), it introduces a new set of components that utilize the new SDK features, named Spark.

 

In most cases, the changes between Spark and MX components are not visible, but rather involve the component’s interaction with the Flex 4 frameworks (i.e. layouts, skins, states etc).

 

In Spark architecture, Visual components are "split" up to several classes. For example, the Button class in Flex 3 is built up of Button class and in addition the ButtonSkin class in Flex 4. Components are typically contained in the spark.* package, while skin classes are typically contained in the spark.skins.* package.

 

sefi 10/05/2010 - 13:43

In short:
When using Parsley's Context for dependency injection, You should call destroyObject() on each getObject() call, otherwise you may have a memory leak.
 
Long story:
Lately I was dealing with some memory leaks issues in one of our client's systems which use Parsley for dependency injection via its Context .
Turns out that calling Context.getObject(id) internally creates references to the objects used for creating the injected object.
These references are not released, and may cause a memory leak.
The profiler (FB4) looks something like this (namespaces ommited for client's privacy sake):

 

 

ilan 09/05/2010 - 23:47
Syndicate content