In August last year we started looking at alternatives for the typical Cairngorm 2 approach, having used it on a number of large projects we didn’t really see it as a framework suited for the kind of applications we develop in Lab49. Some of the issues we were struggling with was the difficulties with integrating with modules, the amount of boiler plate code like events, commands, delegates, responders for every single thing you want to do, etc. Another common problem with Cairngorm 2, and other frameworks, is managing presentation models and the sharing of data without having a hierarchy of objects and passing it down from a parent view to all the children.

The search for a good IoC framework began, but there wasn’t a lot of frameworks out there that supported everything we wanted, but after some investigation the decision landed on Parsley. Parsley supports both Flex Modules and dependency injection, two of our main criteria. We have now successfully used it on a number of projects. If you are looking for an example of building a Parsley based Flex application, have a look at this blog post by Christophe Coenraets alternatively have a look the documentation, Parsley is comprehensively documented: Parsley Developer Manual

After a rather long introduction, here is the presentation: Scaling Flex for Enterprise Applications

Conceptually Slider will hopefully (Adobe says feature set is not final and implementations may change or be removed before the product is launched) work in a similar fashion to our existing Flex based applications, only with a few differences/additions:

• Screen – Navigation in mobile Flex will very likely be screen based, like html, navigate from one screen to the next
• NavigationBar – The screen component has a navigationBar property where a navigation class can be specified
• Toolbar – another mobile specific component which can be used to give the user access to functionality like search and other top level items which can be used at any time while the application is running
• SoftKeyBar – Some phones has softkeys, and this will make it possible for Flex to use these as part of for example navigation, log out etc.
• Mobile specific components like: MobileList
• Conditions – This seems to work very similar to how states in Flex 4 function, using includeIn, where the condition can be for example platform type, e.g. Nokia xxx or iPhone, orientation of the screen.
• ToolBar and Softkeys can also potentially be skinned automatically to blend in with the chrome on the device

Since mobile is a very different platform to desktop and web, with the number of different devices and vendors, it is difficult to create a “one-fits-all” application, therefore Adobe are looking at making it easier to work with for example different screen sizes and screen resolutions. They want to make it easier to specify the size of elements, using touch screens for example will be very difficult if areas are specified in pixels, so instead we should be able to use centimeters, cm units.

One thing that was mentioned a few times were the importance of respecting the device the application was developed for, and how user patterns on mobile devices differ from desktop and standard web applications. With mobile, and iPhone has already proven this, it is important to cache data, so the user can open and close applications without loosing the state, and at any time come back to where they were.

The one thing that was reassuring to hear was that the key goal for Flex Mobile to be successful; was that it has to perform well. There are a couple of ways to look at this, perceived performance and memory consumption. When it comes to memory, they are looking at introducing a destructionPolicy on components, sounds like something we have asked for to get in standard Flex too , basically a component can be set to destruct immediately, later: deferred, or handled by the framework: auto. With the improvements in Flash Player 10.1 which were announced, memory consumption in general also seems to be handled better, with a reduction of up to 50% when certain components are used. Not everything is left to the framework, take view nesting for example, it will still be important to keep the hierarchy as shallow as possible to make the application perform.

As a last note, iPhone was mentioned multiple times, and also used to demo the application they showed in the presentation. And as Ely and Greg Burch said, it will very likely be one of the supported devices.

A recording of the session can be found here Preview: Flex for Mobile Devices

I was introduced to the concept a couple of weeks ago, and I have to say I was a bit surprised at first, but it really makes sense. If it is possible to create native applications in another language, why not, conceptually it is not that far from AIR anyway.

It will be interesting to see the reactions from Apple. Secondly, how easily can we reuse code from already existing projects that we now want to distribute to the iPhone.

• Mosaic – RIA portal
• Cloud deployment on Amazon EC2
• LC ES Collaboration Service (formerly CoCoMo and Flash Collaboration Service)
• Flash Builder 4 and LCDS integration

Mosaic looks really interesting, especially if you already have a number of Flex applications. With Mosaic you can now manage all these in one user interface, and they can be configured to expose business logic. I had a look at the product earlier this year, and it was really interesting to see how easy it was to create a unified application front-end with minimal effort.

From early 2010 it will be possible to get a hosted LC ES2 service in the Amazon Cloud, this should really help on getting projects set up quickly. Leveraging some of the PDF functionality and the collaboration services that easily could be a benefit to a lot of project which only need some of the functionality LC ES2 gives. The collaboration services seems to offer a lot of functionality which is previously not that easy to get; VoIP, Chat, Whiteboarding and live file sharing to mention some.

And last but not least – Data Modeling, the new integration in Flash Builder is very promising, and it is almost like working with Ruby On Rails , at least when it comes to productivity. Not sure how easy it will be to use this for larger scale projects, but so far I haven’t seen anything significant that could let us down.

It is really interesting to see that they too have chosen to use Adobe Flex, and the selling points of using the Flash Platform repeats itself; It is fast, flex(ible) and already available for the majority of clients, with 96.8% of enterprise users having Flash Player 9 or above installed, source Adobe.

With a growing number of financial institutions using Flex, Adobe has really established themselves as a strong competitor in the world of complex RIA’s. With the high technical demands and challenges from investment banking, Adobe has really had to pull up their sleeves, and LiveCycle Data Services 3 is a good example of that. Having added the support for Edge Server deployment, LCDS can really add that extra bit of functionality every complex Flex application needs, multi tier deployment. LCDS adds a lot of value with the ability to use AMF also in banking applications, and we can finally leverage AMF based messaging, RemoteObjects and DataServices, very good to see it coming together.

With all the news in the world of RIA’s 2010 looks really promising

Public voting has started and is available at http://max.adobe.com/awards/finalists/ , the voting will be live until Tuesday, October 6 when winners will be announced at the event.

Presentation is called “Building Matrix – Scaling Flex for a large trading application”. We will give some insight in what it takes to architect and scale a large Flex application. With a large team of Flex developers we have been introduced to technical issues we never before had considered even existed. Some of the areas where we have spent a lot of effort has been performance, scalability, developer productivity and modularization, and we will shed some light in what we have done, and what we have achieved.

“Morgan Stanley have launched a game changing application that aims to provide their customers with the industry leading online trading environment. But don’t just take my word for it…the following micro-site provides valuable insight into what has been delivered (and has some demos too).”

The install works seamlessly, and you are up and running in minutes. You can load a file locally from disk or via an url.

After the .swf file is loaded, and decompiled, you can navigate the complete package structure, and all the classes within a package. It is also possible to view the source for single classes. Quite interesting that HP has made it so easy to have a look at your own and other companies applications

The most interesting feature, and the whole point of SWFScan is analyzing the source to find security issues, and it lists the possible vulnerabilities in your application. A job it seems to do relatively well, considering that I have only used it for a short while and not tested it with code that i know has security issues, it works well. I managed to test it on a large application I’m working on, plus a few modules we are using, and performance for the decompile and the analysis was very good.
It is very eager on reporting issues where it is doing string comparisons, and it’s makes it feel a bit noisy, at least if your application is large, and you use words like “security”, “uid” in your methods or variables. But i would rather see them too often, then not picking up on potential issues. It also reports issues like trace() which you don’t really want in your production code.

After having tested it on both Flash and Flex applications, I would say it works as expected. So far I have “only” found one big showstopper, we have a preloader in one of our Flex applications, and SWFScan is not able to decompile the classes in the whole application, only the ones used by the preloader.

SWFScan also highlights a broader issue with Flex/Flash applications, in the past decompilers haven’t really been as available as it is now, and looking at the code it produces it should give most developers a small wake-up call. It gives other people a good insight to how you code, how it is designed and also what services you are using.

This is absolutely a tool every Flex/Flash developer should have in their toolkit.

• Decompiles and analyzes the application to identify security issues.
• Identifies insecure code, and deployment setup.
• No need for access to the code
• And it is Free

Definitely worth trying, finally someone creates a tool to address Flash security.