This article is truly interesting click to read at Smashing Magazine

The sad thing is not able to find some time to swim in Flex 4 !
Seriously considering to involve in communities again !

This is an interesting question. Interesting less because of the problem itself, and more because it demonstrates just how webified we have become. So, let’s step back a bit …

Web apps (powered by ColdFusion, ASP, JSP, PHP, or just about anything else) often need to maintain session state. If a user logs in you need to maintain that information so that it persists across requests or else the user will be prompted to login on each and every request, if a user puts items in a shopping cart that cart must be stored within a user session or else the cart will be empty each time the page changes, and so on.

The reason that session state needs to be maintained is because the web is stateless, each request stands on its own two feet, and within a request there is no awareness or knowledge of prior requests. Each time a page is requested a connection to the server is made (often multiple connections) to retrieve the needed elements, and then that connection is broken. This allows HTTP servers to respond to lots of traffic (far more so than if connections were always kept open), but the down side is that web pages are not aware of any activity performed by the same client previously.

To allow data to persist in the stateless web we’ve grown accustomed to taking advantage of what might be best described as a hack. In web apps, data to be persisted is stored on the server, so that it’ll be present on subsequent requests. Of course, this necessitates that there be a way to associate a specific block of data on the server with a specific client, and so web applications (or application servers) create session identifiers which are sent to the client, and which must be sent back to the server on every subsequent request. These identifiers are most frequently stored in cookies or embedded in URL tokens or hidden form fields. But where they are stored is less important then the fact that they are needed, and must be submitted from the client (the web browser) back to the server on every subsequent request or else session state will be lost.

Life was not always this convoluted, things used to be simpler. Desktop applications and client-server apps never had to rely on state being maintained on the server. In those apps the client itself is stateful – it is not a set of loosely coupled scripts sitting on a server, rather it is an actual application running on the client, an application which does not completely reload when items are selected or clicked on. Requests are indeed made back and forth between the client application and the server as needed, but the client is always present and always running. And so preferences can be stored on the client, as could shopping cart contents, as could login details.

In other words, session state management is not preferred behavior at all. Rather, it is an unfortunate side effect of how the web operates, a way to compensate for the statelessness of the web.

Now back to Flex. Flex applications (or more rightly, Flash applications) are usually served by web servers and run inside of web browsers. But Flex applications are functionally a lot more like client-server applications than they are web applications. Like desktop client-server applications, Flex applications are loaded and the remain running as long as the app is in use. Like desktop client-server applications, Flex applications connect to back-ends and request or interact with data as needed. Like desktop client-server applications, Flex applications do not suffer the limitations of running in a too-thin client. And like desktop client-server applications, variables defined once in the app can remain defined, and objects instantiated can remain so (until you kill them, or until the application terminates).

In other words, Flex apps are stateful, much like desktop applications and client-server applications. If you need to remember user preferences, just create a variable or object to store these in and keep it around for the duration of the application execution. If you need to track shopping cart contents, keep these locally within the Flex app until checkout time when they’ll be submitted to the server. And so on.

(As a side note, if you need to maintain values across application usage, then you can even store values locally in local shared objects – the Flash Player’s equivalent to browser cookies).

So, the answer to the question “how do I maintain session state in a Flex application?” is “as a rule, don’t!”.

Adobe® Flash Catalyst® Beta Features
Wednesday, June 10, 2009 11:00 AM PT

In this seminar you’ll get a look at the features of Flash Catalyst Beta. See how you can convert artwork into Flex components, how to create states and transitions, and how to share a Flash Catalyst project so it can be opened inside of Flex Builder “Gumbo”.

Adobe Flash Builder 4 Beta (formerly Flex Builder) Simplifies Flex for ColdFusion Developers
Thursday, June 11, 2009 11:00 AM PT

In this seminar you’ll get a chance to see some of the productivity enhancements we’ve made for developers in the next version of Flex Builder. You’ll see how easy it is to connect your Flex application to a ColdFusion application and you’ll also discover how to take advantage of the power of ColdFusion right inside of your Flex applications.

So why late get register for the e-seminars, its free.

Adobe – Online events : Event Details

View Original Article

public static function copy(value:Object):Object
{
var buffer:ByteArray = new ByteArray();
buffer.writeObject(value);
buffer.position = 0;
var result:Object = buffer.readObject();
return result;
}

Then why its not working… reason is simple
Copies the specified Object and returns a reference to the copy. The copy is made using a native serialization technique. Confused.

Use the [RemoteClass] metadata tag to register the class with Flex so that Flex preserves type information when a class instance is serialized by using Action Message Format (AMF).
We have two ways to add the type information to the class:
1 . using [RemoteClass]
2. registerClassAlias(“my.pkg.class”,class);

This will resolve the problem.