I gave a talk last week at the Flex and the City conference in London, England about the leading streaming technologies that are on the market to do "push" at scale and at low-latency on a high concurrency Flex project. I focused on the scale of the challenge, the requirements that you need to look for in a solution and the risk mitigation strategies that should be adopted to ensure you end up using a technology that best meets your requirements.
Most streaming solutions (such as Kaazing, Nirvana and Lightstreamer) focus on providing high performance duplex data communication to clients built in a range of different technologies such as Silverlight, AJAX, Java and C# but not much else. Adobe's LiveCycle Data Services on the other hand also provides higher-level abstractions such as managed collections designed to minimize the plumbing effort required to integrate Flex and Java. Unfortunately LCDS currently only supports Flex clients, doesn't support some of the channel types supported by other products and doesn't provide much support on the server for monitoring and managing active sessions. For that reason comparing the leading streaming products on the market is a bit like comparing apples with oranges. It would be great if we could take the best features of each of these products and combine them together.
In my talk I suggested Adobe should seriously consider collaborating with third parties such as My-Channels and Kaazing to provide support for those vendors' channel implementations (such as Kaazing's innovative Web Socket and Nirvana's nhps protocol) in the LCDS product. Imagine how cool it would be to be able to take advantage of Flex managed collections over a reliable (and more manageable) Nirvana channel!
I'd be interested to hear your experiences with these solutions on large-scale Flex projects or indeed any other full-duplex solutions you've used.
Monday, October 25, 2010
Sunday, August 29, 2010
Is Catalyst CS5 ready for prime time?
At Rule Financial we're still using the traditional tools and workflow to create static and dynamic wireframe mockups for customer projects (i.e. Photoshop, Illustrator and Flash Pro). Since Catalyst CS5 would appear to offer significant productivity improvements over the traditional workflow, I've been spending some time checking out whether it's ready for prime time.
These are some of the issues I found:-
When you add multiple instances of the same Custom Component to the stage:-
a) the "instance" name is automatically set by Catalyst as the same as the class name (MidLevelComponent in my example). This can be confusing since you can't easily tell the difference between a reference to the class and a reference to the instance in the rest of the UI.
b) because the class name is used all the automatically generated "instance" names are identical!!! This can be confusing when you come to add an interaction. For example, the "Choose State" dropdown shows an unhelpful list of instance names, all of which are identical, making it difficult to choose the correct instance. To confuse further the instance names all look like class names since the first letter is in upper case.
Neither of these issues is a problem in a trivial demo type application but in any serious application this will be confusing. The good news is that the code generation engine assign unique instance ids for each custom component instance. The bad news is that the engine appears to use a completely different set of rules for generating the ids. Worse still the generated ids don't follow ActionScript naming conventions either. Instead they're all lower case (e.g. id="customcomponent112", id="customcomponent113").
It would be better if the generated instance names of custom components were the same as the generated ids and if they used the camel case naming convention (i.e began with a lower case letter).
Since Catalyst's vision is to improve the designer-develop workflow, encouraging designers to use the same naming conventions as developers (instance names that begin with a lowercase letter and class names that begin with a uppercase letter) might be a good idea.
Vote for this feature to be included in the next release of Flash Catalyst: http://tinyurl.com/2fxcw7z
In the current build of Catalyst CS5 the only way to implement what would be called a "mask" in Flash Pro is to create a rectangular custom component and to turn on "clip to component bounds". Unfortunately this option is only enabled for components with a manually sized bounding box. It would be nice to have support for clipping to component bounds for components with autosized bounds (which is the default for new custom components).
These are some of the issues I found:-
When you add multiple instances of the same Custom Component to the stage:-
a) the "instance" name is automatically set by Catalyst as the same as the class name (MidLevelComponent in my example). This can be confusing since you can't easily tell the difference between a reference to the class and a reference to the instance in the rest of the UI.
b) because the class name is used all the automatically generated "instance" names are identical!!! This can be confusing when you come to add an interaction. For example, the "Choose State" dropdown shows an unhelpful list of instance names, all of which are identical, making it difficult to choose the correct instance. To confuse further the instance names all look like class names since the first letter is in upper case.
Neither of these issues is a problem in a trivial demo type application but in any serious application this will be confusing. The good news is that the code generation engine assign unique instance ids for each custom component instance. The bad news is that the engine appears to use a completely different set of rules for generating the ids. Worse still the generated ids don't follow ActionScript naming conventions either. Instead they're all lower case (e.g. id="customcomponent112", id="customcomponent113").
It would be better if the generated instance names of custom components were the same as the generated ids and if they used the camel case naming convention (i.e began with a lower case letter).
Since Catalyst's vision is to improve the designer-develop workflow, encouraging designers to use the same naming conventions as developers (instance names that begin with a lowercase letter and class names that begin with a uppercase letter) might be a good idea.
Vote for this feature to be included in the next release of Flash Catalyst: http://tinyurl.com/2fxcw7z
In the current build of Catalyst CS5 the only way to implement what would be called a "mask" in Flash Pro is to create a rectangular custom component and to turn on "clip to component bounds". Unfortunately this option is only enabled for components with a manually sized bounding box. It would be nice to have support for clipping to component bounds for components with autosized bounds (which is the default for new custom components).
Monday, April 12, 2010
Don't buy Flash Builder - it's now included in CS5!
Flex Builder has always felt a bit like like Adobe's "ugly duckling" product. I'm used to licensing Flex Builder and Creative Suite separately. Yesterday I tried to buy Flash Builder 4 but failed only 'cos Adobe's UK on-line store was down for maintenance. Wow that was lucky! Today I discover that Flash Builder 4's bundled in CS5 Web Premium now. So I can upgrade my Creative Suite license and I get Flash Builder for free!
Sunday, April 04, 2010
Configuring a default application-wide channel set in Spring BlazeDS
The Spring BlazeDS Integration project provides a very elegant framework for Flex-Java development. However the project documentation (as of 1.0.3) encourages the decoupling of the BlazeDS channel configuration in the client from the channel config in the server. While in many cases this is the right thing to do, in other cases developers may prefer to define the configuration in one place (in services-config.xml) and compile the client(s) against service-config. Developers using the joint Java-Flex project support in Flash Builder, for example, (provided under the hood by Eclipse WTP) will find this approach convenient, especially in the early stages as they are learning the framework.
Unfortunately neither the Spring BlazeDS Integration documentation (as of 1.0.3) nor Adobe's LCDS documentation (as of 3.0) provides an example of how to define an application-wide default channel set in services-config.xml.
You can define a default application-wide channel in service-config.xml as follows:-
With an application-wide default channel set in services-config you can define mx:RemoteObjects, mx:Producers and mc:Consumers in the client as follows without having to specify a channel configuration explicitly. (This assumes the client is compiled against service-config.xml which has been the default in Flex/Flash Builder for projects set up with BlazeDS support since WTP support was introduced in v2.0.1).
and also allows a simpler Spring config as follows:-
Additionally BlazeDS remoting endpoints annotated as Spring BlazeDS endpoints work too without having to specify a channel explicitly as follows:
While it may not always be the right thing to do, configuring an application-wide default channel set in service-config and compiling the client against services-config significantly reduces the complexity of the Spring BlazeDS config in the simple case.
Unfortunately neither the Spring BlazeDS Integration documentation (as of 1.0.3) nor Adobe's LCDS documentation (as of 3.0) provides an example of how to define an application-wide default channel set in services-config.xml.
You can define a default application-wide channel in service-config.xml as follows:-
With an application-wide default channel set in services-config you can define mx:RemoteObjects, mx:Producers and mc:Consumers in the client as follows without having to specify a channel configuration explicitly. (This assumes the client is compiled against service-config.xml which has been the default in Flex/Flash Builder for projects set up with BlazeDS support since WTP support was introduced in v2.0.1).
and also allows a simpler Spring config as follows:-
Additionally BlazeDS remoting endpoints annotated as Spring BlazeDS endpoints work too without having to specify a channel explicitly as follows:
While it may not always be the right thing to do, configuring an application-wide default channel set in service-config and compiling the client against services-config significantly reduces the complexity of the Spring BlazeDS config in the simple case.
Thursday, February 18, 2010
Can FlexUnit4 test Parsley applications?
One of the challenges you face when adopting a dependency injection framework for Flex development is how to test classes that use features of the DI framework. For example when you use the Parsley framework a Command class is typically implemented as follows:-
Here the command dispatches a CommandCompleteEvent message when the service returns a result using Parsley's MessageDispatcher. If you want to test this implementation you need to be able to write a test class that can handle Parsley's CommandCompleteEvent message. You'd probably write the test class like this:-
and you'd probably run it in the normal way as follows:-
Sadly since the test class is not in the Parsley context the [MessageDispatcher] and [MessageHandler] decorators are ignored, the test will never run the command and the test will always fail. Additionally you probably want to be able to [Inject] the test classes dependencies rather than instantiating them programatically in the setUp method. Clearly for this work the test class needs to be a "managed" object (i.e. an object in the Parsley context). It's easy to put the test class into the context but getting FlexUnit4 to use the managed object is easier said than done. What we really need is a Parsley-aware test "runner" (like Spring Java's context-based test runner) that you could use as follows:-
but unfortunately at the time of writing there's no such Parsley test runner.
If you declare the test class in a Parsley ApplicationContext.mxml and instantiate it using Parsley's FlexContextBuilder, the Parsley [MessageDispatcher], [MessageHandler] and [Inject] decorators will work but the challenge is to get FlexUnit4 to use the "managed" instance of the test class. Unfortunately the way FlexUnit4 works at the moment you specify the class names of the test classes to FlexUnit4 and FlexUnit4 goes off and creates its own instances of the test classes. Major disconnect.
If you take a look under the hood of FlexUnit4 you'll find that the parameters to FlexUnitCore's run method can be instances as well as classes. So you might expect the following to work:-
but don't try that at home because this undocumented feature of FlexUnit4 isn't fully implemented yet and it doesn't work. That's a shame since this would make FlexUnit4 much easier to use with dependency injection frameworks.
Time to give up? The good news is that Parsley 2.2 includes support for generic "short-lived" objects (originally included to support the command pattern) that we can leverage to insert the test class into the Parsley context programatically with createDynamicContext().addObject(this). The following works:-
I guess one day we might have test runner support in Parsley and Spring ActionScript. Until then I guess we have to make do with these workarounds.
Here the command dispatches a CommandCompleteEvent message when the service returns a result using Parsley's MessageDispatcher. If you want to test this implementation you need to be able to write a test class that can handle Parsley's CommandCompleteEvent message. You'd probably write the test class like this:-
and you'd probably run it in the normal way as follows:-
Sadly since the test class is not in the Parsley context the [MessageDispatcher] and [MessageHandler] decorators are ignored, the test will never run the command and the test will always fail. Additionally you probably want to be able to [Inject] the test classes dependencies rather than instantiating them programatically in the setUp method. Clearly for this work the test class needs to be a "managed" object (i.e. an object in the Parsley context). It's easy to put the test class into the context but getting FlexUnit4 to use the managed object is easier said than done. What we really need is a Parsley-aware test "runner" (like Spring Java's context-based test runner) that you could use as follows:-
but unfortunately at the time of writing there's no such Parsley test runner.
If you declare the test class in a Parsley ApplicationContext.mxml and instantiate it using Parsley's FlexContextBuilder, the Parsley [MessageDispatcher], [MessageHandler] and [Inject] decorators will work but the challenge is to get FlexUnit4 to use the "managed" instance of the test class. Unfortunately the way FlexUnit4 works at the moment you specify the class names of the test classes to FlexUnit4 and FlexUnit4 goes off and creates its own instances of the test classes. Major disconnect.
If you take a look under the hood of FlexUnit4 you'll find that the parameters to FlexUnitCore's run method can be instances as well as classes. So you might expect the following to work:-
but don't try that at home because this undocumented feature of FlexUnit4 isn't fully implemented yet and it doesn't work. That's a shame since this would make FlexUnit4 much easier to use with dependency injection frameworks.
Time to give up? The good news is that Parsley 2.2 includes support for generic "short-lived" objects (originally included to support the command pattern) that we can leverage to insert the test class into the Parsley context programatically with createDynamicContext().addObject(this). The following works:-
I guess one day we might have test runner support in Parsley and Spring ActionScript. Until then I guess we have to make do with these workarounds.
When is a Cairngorm command not a command?
Answer: When it's a Cairngorm 3 command
Cairngorm 2, notwithstanding the architectural weaknesses it inherited from EJB2, included an implementation of a pattern that's become widely used in Flex applications; the command pattern.
In this patten a command object is used to represent a request to perform a unit of work. Typically in a Flex application command instances represent calls to the service layer on the server where each command object stores the paramenters to perform its unit of work. Since Flex's I/O framework is fully asynchronous, several requests to the same operation on the service layer may be be underway at the same time. The command pattern with a separate instance for each request provides a elegant way to manage concurrency in a Flex application. In a Cairngorm 2-based Flex application, each time you dispatch a Cairngorm event, a fresh instance of the event's corresponding command object is created by the Cairngorm framework. If the same Cairngorm event is dispatched again while the first operation is still in progress you'll end up with another instance of the same command, each one representing a specific call, each with its own specific parameters.
As a conseqeunce of this design Cairngorm 2-based applications can safely assume that each command object is specific to each request and may store state in instance variables of the command object. That’s a safe assumption since that’s how the command pattern is defined.
One of the most remarkable features of the collection of libraries that Adobe have chosen to call “Cairngorm 3” is that it doesn't provide an implementation of the command pattern. In Cairngorm 3's "integration library" (implemented as a Parsley extension), commands are now singletons that are re-used by concurrent requests. While in many cases Flex applications will ensure the serialization of requests to the same operation, in general this means that applications written for Cairngorm 2 can't be easily migrated to Cairngorm 3. Cairngorm 3 simply doesn't provide an implementation of the command pattern that's compatible with previous versions of Cairngorm. In fact it doesn’t provide an implementation of the command pattern at all. Worse still the [Command] decorator is used in Cairngorm 3 to decorate these singletons implies that these decorated classes are implementations of the command pattern when they’re not.
Parsley appears to have replicated this mistake in its most recent release (2.2) which now also supports the [Command] decorator to decorate these singletons. This decorator would have been better named [Operation] or something else that doesn’t imply that the decorated class is an implementation of the command pattern. The good news is that the latest release of Parsley does provide an implmentation of the command pattern in what it calls “short-lived commands" and “dynamic commands”. These “dynamic commands", like in Cairngorm 2, are created each time a request event is handled. Unfortunately Cairngorm 3 doesn’t currently support Parsley’s implementation of the command pattern yet so if you’re thinking of upgrading an existing Cairngorm 2 application to Cairngorm 3 I’d think twice about using Cairngorm 3 in its current state.
If you’re keen to add presentation models to an existing Cairngorm 2 application while leveraging a dependency injection framework (to get rid of all the references to Model.getInstance() etc…), then Spring ActionScript is a great choice since (ironically) it includes much better support for Cairngorm 2’s command pattern (in its optional Cairngorm 2 support library) than Cairngorm 3.
Cairngorm 2, notwithstanding the architectural weaknesses it inherited from EJB2, included an implementation of a pattern that's become widely used in Flex applications; the command pattern.
In this patten a command object is used to represent a request to perform a unit of work. Typically in a Flex application command instances represent calls to the service layer on the server where each command object stores the paramenters to perform its unit of work. Since Flex's I/O framework is fully asynchronous, several requests to the same operation on the service layer may be be underway at the same time. The command pattern with a separate instance for each request provides a elegant way to manage concurrency in a Flex application. In a Cairngorm 2-based Flex application, each time you dispatch a Cairngorm event, a fresh instance of the event's corresponding command object is created by the Cairngorm framework. If the same Cairngorm event is dispatched again while the first operation is still in progress you'll end up with another instance of the same command, each one representing a specific call, each with its own specific parameters.
As a conseqeunce of this design Cairngorm 2-based applications can safely assume that each command object is specific to each request and may store state in instance variables of the command object. That’s a safe assumption since that’s how the command pattern is defined.
One of the most remarkable features of the collection of libraries that Adobe have chosen to call “Cairngorm 3” is that it doesn't provide an implementation of the command pattern. In Cairngorm 3's "integration library" (implemented as a Parsley extension), commands are now singletons that are re-used by concurrent requests. While in many cases Flex applications will ensure the serialization of requests to the same operation, in general this means that applications written for Cairngorm 2 can't be easily migrated to Cairngorm 3. Cairngorm 3 simply doesn't provide an implementation of the command pattern that's compatible with previous versions of Cairngorm. In fact it doesn’t provide an implementation of the command pattern at all. Worse still the [Command] decorator is used in Cairngorm 3 to decorate these singletons implies that these decorated classes are implementations of the command pattern when they’re not.
Parsley appears to have replicated this mistake in its most recent release (2.2) which now also supports the [Command] decorator to decorate these singletons. This decorator would have been better named [Operation] or something else that doesn’t imply that the decorated class is an implementation of the command pattern. The good news is that the latest release of Parsley does provide an implmentation of the command pattern in what it calls “short-lived commands" and “dynamic commands”. These “dynamic commands", like in Cairngorm 2, are created each time a request event is handled. Unfortunately Cairngorm 3 doesn’t currently support Parsley’s implementation of the command pattern yet so if you’re thinking of upgrading an existing Cairngorm 2 application to Cairngorm 3 I’d think twice about using Cairngorm 3 in its current state.
If you’re keen to add presentation models to an existing Cairngorm 2 application while leveraging a dependency injection framework (to get rid of all the references to Model.getInstance() etc…), then Spring ActionScript is a great choice since (ironically) it includes much better support for Cairngorm 2’s command pattern (in its optional Cairngorm 2 support library) than Cairngorm 3.
Friday, January 29, 2010
Why isn't it ActionScript10?
One of the things that's obvious when you start building applications with Flash Builder 4 is that there's a new component architecture. One of the other things that's obvious is that the ActionScript language and the Flash foundation class library have both been changed for version 10 of the Player. For example the new version of ActionScript includes a new strongly-typed Vector datatype and the Flash foundation class library includes support for 3D transforms etc.. That's progress I guess. However applications written in the "new version" of AS3 supported by Player 10 won't work in Player 9. It's always like that with new releases of the Player and it's no different from in Java and .NET with one key difference. When Sun releases a new version of the JRE which supports a new language features or additions to the Java foundation class library they increment the version of Java. JRE5 runs Java 5, JRE6 runs Java 6 and so on. It's obvious that code written in Java 6 won't run in the JRE5. That's software release management 101, right?
It seems Adobe doesn't want to play by the same rules. The reality is that the version of the ActionScript language is closely coupled to the version of the Player. Player 10 includes a Flash VM that runs applications written in "AS10" and "AS9" and a Flash interpreter that runs applications written in "AS8" and earlier versions of the language. So why doesn't Adobe come clean and call the new version of the language "ActionSctript 10". Better still, since ActionScript's not a "scripting" language and hasn't been one for a long time now, why not just call it "Flash 10"?
It seems Adobe doesn't want to play by the same rules. The reality is that the version of the ActionScript language is closely coupled to the version of the Player. Player 10 includes a Flash VM that runs applications written in "AS10" and "AS9" and a Flash interpreter that runs applications written in "AS8" and earlier versions of the language. So why doesn't Adobe come clean and call the new version of the language "ActionSctript 10". Better still, since ActionScript's not a "scripting" language and hasn't been one for a long time now, why not just call it "Flash 10"?
Subscribe to:
Posts (Atom)