Rumor: Google bundles Chrome with Flash?

It’s just a rumor, but it’s being said that there are plans out there that Google will release future versions of Chrome with Flash bundled.

If it’s true, this fact would be really astonishing for me, since Google usually tries to push open-source technologies, which Flash definately isn’t. Further, GWT is a direct rival of the Adobe Flex platform, so it really doesn’t marke sense why Google should increase its support in Flash.

Thus, I can’t believe that this rumor is true, but if it is, it would make me a really happy man :-)

My vision: Get Flash preinstalled on ChromeOS and Android! yay! :-)

Update: It’s true! An official statement confirms the partnership between Adobe and Google by integrating the Flash Player into Chrome:

Paul Betlem (Adobe): Today, Google is releasing the initial integration of Flash Player with Chrome in their developer channel (behind a command line flag). Moving forward, Google will be including Flash Player in Chrome so users will always have the most current release and a safer and more seamless experience. The robust integration between Chrome and Flash Player will serve as a showcase for more consistent, seamless, and efficient Web browsing experiences. We feel that this significant effort by both Google and Adobe will directly improve the speed of innovation and move the Web forward, benefiting the entire community of developers and end-users.

The Chromium authors blogged about the benefits, which are:

  • When users download Chrome, they will also receive the latest version of Adobe Flash Player. There will be no need to install Flash Player separately.
  • Users will automatically receive updates related to Flash Player using Google Chrome’s auto-update mechanism. This eliminates the need to manually download separate updates and reduces the security risk of using outdated versions.
  • With Adobe’s help, we plan to further protect users by extending Chrome’s “sandbox” to web pages with Flash content.

Forward- and back-button support in Silverlight

I noticed in the screencast below, that Silverlight seems to offer a great implicit way of supporting browser’s forward- and back-buttons. The basic idea is to modify the current url by adding or removing tags without forcing a page refresh.

Example: In the video below, a basic Twitter client is being developed using Silverlight. The main part is wrapped into a navigation component which automatically stacks sub-components, similar to the ViewStack component in Adobe Flex. The difference is now, if the displayed component changes, also the current url changes. For example, if the user sees the “home” view and clicks on “search”, the url, displayed in the browser, changes from to

If the user now clicks the back-button, the Silverlight application automatically switches back to the home view.

This truly is a great (and so simple!) way of supporting browser history inside of plugin-based RIA technologies. I wished, there would be something like this for Flex.

My best practice for MVC with Adobe Flex3

I often read in Flex-tutorials and -books, that it’s difficult to completely implement a project using the concept of the MVC (Model-View-Controller) pattern. It is being said that the fact that MXML files inherit both, application logic (through ActionScript) and the declarative way of building graphic user-interfaces using MXML syntax, makes it almost impossible to separate view and controller from each other. Thus, they say, both seem to melt together, which results in a Model-(View/Controller) design.


In order to use the MVC concept in Flex projects, authors often refer to 3rd-party frameworks, like PureMVC.

I say, that’s not necessary, because:

  1. If you use frameworks, you rely on 3rd party code, which I really would only recommend if absolutely necessary.
  2. If you set-up your project correctly and think about its infrastructure before coding, you can easily build a Flex application without breaking with the idea of MVC.
  3. No framework in the world can replace good project planning. If you plan well, your application will automatically go MVC.
  4. KISS

So, in order to use MVC in a Flex application, the following will be a short explanation how I set up my projects. This is not a ultimative best practice guide. It’s just something that I want to share from my personal experience.

The concept itself is based on data-binding. DataProviders are being bound to view components. A controller keeps updating these providers. Thus, there should be no application logic required in any of our view-component files (except for a few lines of event-dispatching).

This is how it works:

  1. Create the model, view and controller components
  2. Assign a controller for each view component
  3. Bind the dataproviders to the view components
  4. Add event-listeners to the view components (e.g. to catch user-interactions), which are being handled by the controllers.

Let’s visualize this with a simple example. Image, you’d want to write a program which lists fruits and their prices in a supermarket. With a click on a buy-button the selected fruit is being removed from the list:

In order to create this, you need the following:

  1. The Model (
    A file, which inherits the two properties name and price.
  2. The View (FruitMarket.mxml)
    A component, which displays the data we want. We’ll use a HBox for this, which wraps a DataGrid and a Button.
  3. The Controller (
    An ActionScript file in order to provide the application logic, which is associated with the view component (FruitMarket.mxml).

The full project structure should look like this:
Project structure for the MVC-Example FruitMarket in Flex

Here is the UML diagram for our mini project:
UML diagram for FruitMarket example
The basic idea is to assign a controller for each view (1:1 relation) and keep a dataProvider (fruits:ArrayCollection) inside the MarketController and bind it to the FruitMarket component. Since one market can have multiple fruits, the relation between controller and model is 1:n.

You might have noticed some additional files:

  • – This is a simple DataGrid, which displays the data (as a part of FruitMarket.mxml).
  • – This event will be fired from the FruitMarket.mxml component when the user clicks the buy-button.

This is all that’s needed regarding project setup.
Let’s have a look at the implementation details.

In order to catch user interactions, the FruitMarket.mxml component needs to fire events, which are being caught by the

FruitMarket.mxml (part)

// Will be called if the user presses the buy-button
private function fruitBoughtEvent(event:MouseEvent):void {
	dispatchEvent(new FruitBoughtEvent(FruitBoughtEvent.FRUIT_BOUGHT_EVENT));

The listens to this event:

market.addEventListener(FruitBoughtEvent.FRUIT_BOUGHT_EVENT, buyFruit);
private function buyFruit(event:Event):void {
	var selectedItem:Fruit = market.fruitTable.selectedItem as Fruit;
	if (selectedItem != null) {
		var fruitToBuy:Fruit = selectedItem;
		removeFruit(fruitToBuy);"Thank you for buying the fruit!");

Now, in order to get this working, we need to assign the controller to the FruitMarket component (in FruitMarket.mxml). In order to do so, our FruitMarket.mxml calls the function below on creationComplete event (like a constructor):

private var marketController:MarketController;
private function creationComplete():void {
	marketController = new MarketController(this);

For this example, it’s not necessary to keep a reference to the controller but you never know. It can become handy in a “real” project.

Last but not least, bind the dataProvider to the view component (shown in the code below). Any changes to the dataProvider (fruits:ArrayCollection) will automatically lead to view-updates. The full controller-source looks like this:

public class MarketController {
	[Bindable] private var fruits:ArrayCollection;
	private var market:FruitMarket;
	public function MarketController(market:FruitMarket) { = market;
		var tmpArray:Array = [new Fruit("Banana", 0.99), new Fruit("Strawberry", 3.99), new Fruit("Ananas", 3.99),];
		fruits = new ArrayCollection(tmpArray);
		market.fruitTable.dataProvider = fruits;
		market.addEventListener(FruitBoughtEvent.FRUIT_BOUGHT_EVENT, buyFruit);
	private function buyFruit(event:Event):void {
		var selectedItem:Fruit = market.fruitTable.selectedItem as Fruit;
		if (selectedItem != null) {
			var fruitToBuy:Fruit = selectedItem;
			removeFruit(fruitToBuy);"Thank you for buying the fruit!");
	private function removeFruit(fruit:Fruit):void {

Now, the controller has full access to the view component. It listens to any user interaction events, which are being delegated from the view component, and reacts on these.

This is basically all. Download the full source here.

The full project is now structured into Model (, View (FruitMarket.mxml) and Controller ( The only ActionScript-code inside the FruitMarket.mxml is for assigning the controller to it and dispatch the event if the user clicks on the buy-button. All the rest of the application logic is done by the controller.
If you ever want to replace the view component with a new one, you just have to make sure, that all necessary events are being dispatched and then assign the controller to the component. That’s it.

Of course you could make this perfect by defining an interface for the view component. For the purpose of this demo I was to lazy, but if you deal with real projects, I’d definately recommend doing so.

Flash is better than Java

Stop! Before you send me a letter-bomb, read this article first :-)

Update: After hearing about some misunderstandings regarding this post, I want to make sure, that the title “Flash is better than Java” is of course targeted at front-ent software engineering, not backend. Although it’s obvious that noone would ever try to build a web application backend using Flash, I just wanted to make sure that you understand what I am talking about :-)

If I talk to people and tell them that I love to use Flex, most say: “Eewwhh! Flex? Isn’t that… Flash? This animation thingy?”.

That’s what often makes me go nuts.

Don’t get me wrong. The Flash Player itself is shitty. It’s slow, unstable and has some serious issues regarding security. On the other side: The developer-side for Flex-coders is absolutely great and professional. ActionScript3 is an awesome object-oriented programming language and the nice features of MXML, like easy data binding, make it possible to create good-looking applications in no time.

If combined with the AIR runtime environment, which makes it possible to compile Flash applications into installable multi-platform desktop programs, I’d even go so far to say that it’s better than Java (on both, Desktop and Web).

Big IT-companies like IBM or SAP currently run experiments in order to verify if it is possible to replace Java (desktop-)frontends using Flex. This would shorten development time (since using Flex is so easy) and thus reduce costs. On top of that, their customers achieve great-looking and modern graphic user interfaces.
This replacement strategy does totally make sense, because Flex works great with common Java-based SOA architectures. Technically seen, it’s no problem to throw away an existing Java-frontend and replace it with a Flex version by simply connecting it to an existing J2EE backend. The reason: Using RPC techniques like class/object-sharing between Java and Flex over distributed networks is no problem since both languages are so similar regarding their object-oriented philosophy, as well as syntax. If you don’t believe me, read this.

Further, with the new Flex 4 platform, it is possible to improve the workflow between UI-designers and programmers using Flash Builder 4 and Adobe Catalyst. The idea is as follows: Before Flex 4, designers created user-interfaces and sent these to the developers, who then started transforming these drafts into actual programs. Now, if the designer wants any changes to the layout, he needs to ask the the developer to implement these changes. This is not very efficient. With Flex 4 and Catalyst the whole workflow has changed: Designers now create the user-interface using Illustrator. Then, they export their drafts into a *.fxb file using Catalyst, which needs to be sent to the developer, who just has to import this file into the project and can thus focus on the actual application logic instead of bothering with the UI. If the designer now wants any changes to the UI, he simply updates his *.fxb file and the developer re-imports it. Done. Can Java do this? No.

I don’t want to start a flame war, this is just my personal opinion from my experience with both worlds of Java and Flash.