The application incorporates a number of general features for improved accessibility:

• Support for “keyboard-only” users
• An alternative high-contrast style-sheet for vision-impaired users
• A zoom feature for vision impaired users

We also added features specifically aimed at improving the experience for screen-reader users:

• Focussable static-text to allow screen-reader users to peruse all content using the tab key
• Additional announcements to describe each new view as the user navigates
• Additional verbosity to clarify the meaning of buttons and other controls
• A skip content feature to allow large areas of content (lists, grids, etc) to be jumped

You can view the application here, but only people working in Ireland and registered for PAYE are able to log-in. Otherwise, you can experience many of the accessibility features on the log-in page or the accompanying product-tour.

There are still fundamental problems that can limit the accessibility of applications developed with Flex. We found fixes for some issues, but we often had to resort to monkey-patching to apply them to the framework.  Other issues have workarounds, but these often require an unnatural change in the browsing behaviour of screen-reader  users. This remains a problem for Flash and Flex: Improving accessibility at the expense of usability is nonsensical.

In addition to problems with the architecture and implementation of accessibility features within Flex there is a general lack of good documentation, articles or tutorials on the subject of accessibility. Many of the tutorials and presentations I’ve seen offer simplistic advice that is inadequate for the development of anything but the smallest of applications. Adobe’s own Flex applications do not appear to achieve anything close to a WCAG level of accessibility and I’ve struggled to find any third-party accessible applications online. To help correct this, I hope to share some of our learnings in future blog entries.

However, despite the cheeky title of this post, I doubt this really is the first attempt at an accessible Flex application, so where are all the others?

Looking at the framework source, the changes to DataGridColumn source code do not differ greatly from the community-contributed solutions that already existed. Some optimisations have been introduced such as the parsing of the dataField property once when the property is first set rather than every time the field is evaluated.

Performance concerns appear to be the main reason for omitting this capability from earlier versions. The feature can be expected to be sub-optimal when compared with alternatives such as a labelFunction or custom renderer. However given popular maxims on the evils of premature optimisation, and the availability of more efficient alternatives should the need arise, it seems unnecessary to discard a feature for this reason alone.

My main concern with using dataField for complex expressions is the lack of compile-time checking. A labelFunction may require more code but you’ll get more help from the compiler if the expression is incorrect. An invalid expression in a dataField property is likely to fail silently and may not be noticed until your testing phase, or perhaps even later. However, if you are generating your columns dynamically or binding to an XML data-provider, then the lack of compile-time checking may be less of an issue.

The problem is known to occur for users of Flex Builder version 3.0.1 who are compiling with version 3.2 or later of the Flex SDK. The solution to the problem is to install the Flex Builder 3.0.2 updater available here.

The cause of the issue is a recent change to the flex-config.xml file that ships with the SDK. Both Flex Builder and the mxmlc compiler use this configuration file during compilation. The change in question is the addition of the “targetPlayerMajorVersion” token into a couple of path-elements. This token is substituted with either “9″ or “10″ depending on the Flash player version you are targetting in your build. This in turn causes the compiler to include a particular version of playerglobal.swc during compilation. Although the addition of this token did not prevent earlier versions of Flex Builder from performing builds, it did interfere with code-hinting for many of the core Flash API classes.

If you are unable to install the updater you can also fix the problem by manually removing the targetPlayerMajorVersion token from your flex-config.xml file (located in the frameworks directory) and replacing it with either “9″ or “10″ depending on your target player version.

Challenges

When attempting to unit test views directly, there are numerous challenges to overcome.

Challenge 1 - Isolating the views: Strictly speaking, to unit test an autonomous view class we should be creating stub or mock objects for all of the classes it collaborates with. But a typical autonomous view in Flex could collaborate with numerous Flex framework classes. In my example, the AlbumForm collaborates with three TextInputs, one Checkbox, and two Buttons; not to mention container classes like Form and FormItem. Stubbing all of these is no trivial task and not something I’m going to attempt. So strict unit testing of an autonomous view application is out.

A more sensible approach would be to treat each distinct autonomous view class as a "unit" for testing purposes, and assume that the Flex controls it contains are part of that unit. So I’ll create a unit test suite for AlbumForm and AlbumBrowser since these are distinct autonomous views, and when testing AlbumBrowser I’ll create a stub for AlbumForm.

Challenge 2 - Creating the view: When testing presentation models and supervising presenters I instantiated the "class under test" in my test suite’s setup method. But if I do the same for autonomous views, when I try to access a child of my view instance I get a null pointer exception. This is because my test code is being executed before the view’s CreationComplete event has fired. So to ensure that the CreationComplete event has been dispatched before my test runs, I have added an asynchronous setup method. This method instantiates the autonomous view, adds it to the display list and then uses the FlexUnit "addAsync" method to trigger the unit test code in response to the view’s CreationComplete method.

Challenge 3 - Simulating gestures: A further problem with unit testing my views is that much of their behaviour is driven directly by user activity. For example the change event of the TextInput class can only occur in response to user input. So I have the following options:

• Fake the event by calling dispatchEvent on the control and passing it a suitable Event instance that I’ve created and populated myself..
• Drive the control using the Flex automation library
• Bypass event dispatch and call the event handler directly from my test.

The first of these appears to be the easiest, so that’s the option I’m going with.

Challenge 4 - Stubbing the Alert class: The AlbumBrowser class displays an alert box when the user navigates between albums without saving their changes. I want to test this behaviour, but I don’t want to see pop-ups appearing during a test run. So I’ve extracted the pop-up behaviour into a separate class (called YesNoDialogue), and added a stub class for use during test runs.

Challenge 5 - Stubbing child views: I’ve already said I’ll create a stub for AlbumForm in order to test AlbumBrowser in isolation of AlbumForm’s logic. I’ve done something similar in my previous entries for Presentation Model and Supervising Presenter. In those examples I used a factory method to allow real classes to be substituted with stubs. This works great in ActionScript, but is there a way to swap a real view with a stub when the real view is declared in MXML? Well I gave myself a full 15 minutes to think of one, but nothing came to mind. So in order to stub my AlbumForm, I’m forced to abandon MXML and create my child view in ActionScript. This is a significant compromise.

Example Application

With these challenges overcome or worked around, I could successfully unit test the Autonomous View demo. The unit tested version of the application is available here; right-click to view the source. The test runner for the unit tests is available here.

Thoughts

This isn’t so much a tutorial on how to unit test an autonomous view application as an example of why you should avoid trying to. Although many of the challenges can be resolved or worked-around, one in particular presents a real problem. The autonomous view pattern is attractive because of its simplicity; and a large part of that comes from the convenience of MXML for declarative layout. By abandoning MXML in order to unit test, I am undermining the simplicity of the pattern.

Further work

There may be clever ways to stub views in MXML and I admit I didn’t spend much time looking at how to achieve this. If you’ve found an elegant approach for testing this pattern without abandoning MXML I’d be very interested to hear about it, but I don’t intend to investigate the topic any further myself.

Challenges

The first challenge when unit testing supervising presenters is the dependency they have on the view. Since I am trying to follow a strict unit testing strategy, I want my supervising presenters to be tested independently of other classes, including view classes. So I need to find some way to isolate my presenters from their corresponding views. Besides this unit-testing purism, there are other reasons for isolating my tests from the view:

• Views are generally relatively slow to instantiate and require a disproportionate amount of resources. Having to create views in order to test classes that depend on them may slow down the running of my test suites.
• Animation, deferred instantiaion and modal behaviour could make unit testing challenging.

There are probably many ways to decouple presenters from views, but I’ve decided to follow Martin Fowler’s suggestion of creating a "Gateway" between the view and the presenter. Each gateway will have two responsibilities:

• Act as a facade for a view. Presenters will access and manipulate the view via the facade.
• Observe the view for user events and invoke operations on the presenter.

Each view-dependent gateway will implement an interface to allow it to be substituted with a view-independent stub class for use during testing. This UML diagram illustrates the impact of the gateway approach on the original design.

The second challenge is the collaborative relationship between supervising presenters. In order to isolate one supervising presenter from another I’m going to use the factory method approach described in my previous entry.

Unit testing AlbumFormPresenter

The presenter for AlbumForm does not collaborate with any other presenter objects, but I do need to create a gateway class in order to isolate it from the view. I had to make a few changes to the architecture in order to slot in my gateway, and the end result is a gateway object between the view and the presenter called AlbumFormGateway. This gateway class implements the interface IAlbumFormGateway, so that it can be replaced with a test double called StubAlbumFormGateway. The test double does not require the real view, and the AlbumFormPresenter does not differentiate between the real gateway and the stub gateway because they both implement the same interface. So now I can unit test my AlbumFormPresenter class without needing an instance of AlbumForm.

Unit testing AlbumBrowserPresenter

I also need to create a gateway object for AlbumBrowserPresenter to decouple it from the corresponding view class. This is achieved in precisely the same way as for AlbumFormPresenter. So I’ve added an AlbumPresenterGateway, IAlbumPresenterGateway and StubAlbumPresenterGateway.

In addition to creating the gateway class, I also need to isolate the functionality of AlbumBrowserPresenter from AlbumFormPresenter. If you recall from my previous entry, a similar relationship existed between the AlbumBrowser and AlbumForm presentation models. So I’m applying the same factory method approach approach to allow the real AlbumFormPresenter to be replaced by a stub. The result is a new interface IAlbumFormPresenter, and a new stub class StubAlbumFormPresenter.

A further complexity for AlbumBrowserPresenter is the dependency it has on the PopUpManager. Rather than stub the PopUpManager class I have placed it on the ‘view-side’ of the gateway; so the presenter displays the pop-up by calling a method on the gateway.

Unit testing Album

Unlike the Presentation Model applicaton, the Album VO in the Supervising Presenter example doesn’t have any methods, so it doesn’t need to be tested. Or does it?

In order for my application to work the Album VO class does need to do one very important job: It needs to support binding. Should I write unit tests for bindability? Well strictly speaking I should, and perhaps I could use Tom’s EventfulTestCase for this. But I think I’ll look more closely at this another day.

Unit testing AlbumDelegate

As with the Presentation Model example, I’m not testing this class.

Example Application

The unit tested version of the supervising presenter demo application is available here; right-click to view the source. The test runner for the unit tests is available here.

Thoughts

The supervising presenter’s view dependency does make unit testing more challenging. The gateway approach appears to be a robust strategy for isolating supervising presenters from views, but it comes at a price. The gateway layer adds extra complexity to the application, and the gateways themselves cannot be unit-tested because they still have dependencies on views.

Further work

After going to the trouble of creating gateways I’m left wondering whether it would be simpler to create test doubles for my actual view classes and dispense with gateways altogether. To do this I would have to extract an interface for each view and then create standalone test doubles that contain identical framework controls. For this to work I would also need to find some way to create fake framework events for my presenters to respond to. I’m not going to attempt this because I now want to turn my attention to unit testing autonomous views.

Challenges

By extracting view state and logic from the view, presentation model classes do not have any dependencies on view classes. They do sometimes have dependencies on each other, so test doubles may be required to isolate the functionality in one presentation model from functionality in another.

Unit testing AlbumForm

The AlbumForm class is quite straightforward to unit test as it only collaborates with the Album value object. I’ve decided not to create a test double for the Album VO because of its simplicity. It only has too methods, and I suspect they will be difficult to simulate without duplicating their behaviour.

In the unit test for AlbumForm I have created tests for all of the public methods of the AlbumForm class. Many of the public methods require more than one test in order to exercise every path of execution.

Unit testing AlbumBrowser

The AlbumBrowser class is a little harder to unit test because it collaborates with the AlbumForm class. In order to isolate my AlbumBrowser unit tests from the functionality of AlbumForm, I’ve decided to create a test double for the AlbumForm class. To do this I’ve made the following changes:

• Extracted an interface from AlbumForm - In order to create a test double for the AlbumForm, I’ve created an IAlbumForm interface which the AlbumForm now implements. The test double ‘StubAlbumForm’ also implementes IAlbumForm allowing it to be used as a substitute for AlbumForm.
• Modified AlbumBrowser to work with any IAlbumForm implementation - Now there’s more than one way to do this, and I’ve used a factory method. The AlbumBrowser is modified so that it creates its instance of AlbumForm in a factory method (that’s just an instance method that is reponsible for constructing the AlbumForm). The factory method is marked protected so that it can be overriden in a subclass. In my AlbumBrowser unit test I’ve created a private subclass of AlbumBrowser that overrides the factory method to return an instance of StubAlbumForm*. My unit test for AlbumBrowser tests an instance of the private sub-class rather than AlbumBrowser itself. This allows me to test AlbumBrowser functionality in isolation of the AlbumForm class.
• Added a property to StubAlbumForm to allow me to control the flow of tests - The AlbumBrowser takes different actions depending on the result from the ‘changesToSave’ method on the AlbumForm class. In order to test these different paths I’ve added a ‘pendingChanges’ property to the StubAlbumForm that allows me to specify the return value of the ‘changesToSave’ method.

I’ve also captured these modifications in the form of a UML diagram, so take a look if none of the above makes any sense.

Together, these changes allow me to test AlbumBrowser in isolation of the AlbumForm class. Doing all of this may be considered overkill for such a small application, but it becomes important for larger applications with deeper hierarchies of presentation model instances and more complex collaborations.

Unit testing Album

The Album VO doesn’t collaborate with any other objects, so testing it is very easy. The unit test for the Album class covers the two public methods: clone() and equals().

Unit testing AlbumDelegate

Since this class is a fake delegate, I’m not going to test it. In real applications it will be necessary to create test doubles for delegates.

Example Application

The unit tested version of the presentation model demo application is available here; right-click to view the source. The test runner for the unit tests is available here.

Thoughts

The presentation model’s independence from the view simplifies the unit testing of application-specific user interface logic. The main challenge is isolating the functionality of one presentation model from that of another. I’ve chosen to use a factory method approach in my application, but other creational patterns could also be applied, as could some form of dependency injection.

Further work

The presentation model classes in this application are still not very well encapsulated. Many of the properties the view binds to are public properties; this simplifies binding, but undermines encapsulation. I’d like to tighten up the encapsulation on these classes, but that’s a task for another day.

*A similar approach in Java would be to use Anonymous Inner Classes inside tests or fixtures to create test-specific sub-classes (here’s an example from IBM). EcmaScript and consequently ActionScript do not support this language feature, so I’ve used a private class instead.

What is unit testing?

This isn’t an introduction to unit testing or a tutorial on how to get started with unit testing. So if you’re asking this question you may want to have a look at some of the links below. The test tool of choice for this series is Flex Unit as it is the one we use on our consulting projects. There are others out there, so feel free to shop around.

• Unit testing and Test Driven Development (TDD) for Flex and ActionScript 3.0
• How to use FlexUnit with FlexBuilder 2
• FlexUnit Basics
• The lost FlexUnit documentation
• FlexUnit articles in the Flex Cookbook

The plan

When looking at Presentation Patterns I started with the simplest pattern to implement, but for this series I’m going to start with the pattern that I believe will be simplest to unit test. So here’s the order of business:

1. Presentation Model
2. Supervising Presenter
3. Autonomous View

Why test view logic?

Applying a unit testing strategy to your user interface logic can have more than one advantage:

• Helps uncover defects early - This is the obvious one, unit testing should help you detect bugs as you develop your code. It won’t detect every bug, but it should provide an extra line of defence.
• Facilitates refactoring - Refactoring is something of a buzzword these days and you’re far more likely to hear people talking about refactoring their code than unit testing it. Refactoring is a structured technique for reducing duplication and redundancy in your code, but without automated unit tests it can also be a great way to add defects.
• Helps to communicate intent - Unit tests can help to describe the intended behaviour of a class. This is of particular importance in team-based software development, or for applications with long maintenance phases. Code commenting and technical documentation are still often favoured over unit testing, but it is debatable whether these are more reliable than a comprehensive suite of unit tests.
• Increases the focus on architecture - Adopting a unit test strategy forces you to think more about the architecture of your application. Perhaps most significantly, the need to test each class in isolation of its collaborators encourages a developer to code against interfaces rather than concrete classes. You’re also likely to see fewer global singletons and law of demeter violations in a unit tested application because of the increased emphasis on modularity.

Is this Test Driven Development?

Test Driven Development (TDD) or test-first development is a development practice in which unit tests are written before the code they test. The advantage of TDD is that the test is seen to fail before the code is written, and the code is then written to make the test pass. I’m not following a TDD approach in these entries because the applications I’m testing have already been written.

In my next entry I’ll take a look at unit testing my Presentation Model example.

Why did I want to do this?

Establish a base-line of terminology for future discussions

Over time, terms like View Helper and Code Behind have become somewhat vague. Discussions involving them often go awry because participants do not have a common understanding of these concepts. Having a "pattern language" is beneficial when investigating architecture, but only if the patterns are unambiguously defined. So in future discussions I want to be able to link back to this series if I happen to mention a presentation pattern in passing.

Increase my own understanding

Some of the patterns in this discussion have been applied on consulting projects past and present, while others are architectural curiosities that have piqued my interest. Building a simple application with each one has helped me to come to a better understanding of how they contrast. Before starting to develop the Supervising Presenter I thought it was very similar to the View Helper, but it turned out to be quite different. And despite never being entirely comfortable with the Code Behind pattern, it wasn’t until I saw it side-by-side with patterns like Presentation Model and Passive View that I started to understand the benefits of a more compositional approach.

Explore the possibilities with Flex

Knowing about architectural possibilities is only useful if your target platform is able to support them. Flex has proved itself more than capable of supporting all six of these contrasting patterns. Having said that, some of the patterns do make better use of Flex’s features than others. Both the Presentation Model and Supervising Presenter combine extract-class refactorings with elegant use of MXML bindings and declarative event handlers. On the hand, Passive View and Code Behind sacrifice these features in order to achieve a greater degree of ActionScript / MXML separation.

What Next?

Take a closer look at unit testing

Although I talked about unit testing throughout these discussions, you may have noticed that I didn’t actually do any. The very need to unit test could make or break a pattern, and can become a driving force for architectural decisions. Furthermore, the subject of unit testing is broad enough and important enough to warrant a series of blog entries to itself. So my next job is to look at how amenable some of these patterns are to unit testing.

Further exploration of presentation patterns

I kept the example application for this series very simple because I knew I would have to implement it six times, this is why many aspects of presentation behaviour mentioned in the introduction were not demonstrated. I can see real advantages of moving non-graphical concerns such as navigation, deep-linking and localisation out of the view, so I’d like to take a closer look at this in the future.

Take a look at integrations patterns

In RIA development projects, finding a way to organise your presentation logic in a way that meets your objectives is a great step forward, but not the only challenge. The way in which your application interacts with remote services is also extremely important. So what are the common integration patterns in the Flex world?

The Passive View pattern also has some similarities with Code Behind since both achieve a complete separation of ActionScript and MXML.

Key Features

• State is in the view
• Logic is in the Presenter
• Presenter observes the view
• Presenter updates the view
• Presenter ‘knows’ about the view
• View does not ‘know’ about the Presenter

The key features of Passive View are identical to those of Supervising Presenter. The difference between the two patterns is the degree to which logic is extracted from the view. Views in a Supervising Presenter application are allowed to ‘observe’ domain or value objects in order to display information, but views in a Passive View application are managed entirely by their presenter object.

The Supervising Presenter pattern lends itself to User Interface frameworks that have synchronisation features (eg. bindings in Flex), by allowing controls in the view to synchronise directly with underlying domain or value objects. The Passive View pattern prohibits this kind of behaviour in the view, so synchronisation between the view and the data model is managed by the presenter class instead.

Motivations

The motivations for the Passive View are similar to those of the Supervising Presenter and Presentation Model:

Easier to test

By moving all behaviour out of the view, the Passive View pattern is likely to afford the maximum unit test coverage of all the patterns I’ve looked at. The presenter class has a reference back to the view; so mock objects will be required to test it.

Improved Separation of Concerns

As with the other extract class refactorings, the Passive View pattern can help improve the separation of concerns in an application. By favouring composition over inheritance, Passive View achieves a greater degree of decoupling from the Flex framework than the Code Behind pattern. Presenter classes do not need to extend from Flex containers.

Language Segregation

By moving logic out of the view, the Passive View pattern can achieve similar developer / designer workflow objectives as Code Behind. The resulting view class is free from event handler specifications, binding statements and script blocks.

Issues

I think all of the issues identified for Supervising Presenter also apply to the Passive View. Rather than repeating myself, I’ll just refer you back to that discussion.

Reduced role for MXML

As I suggested when discussing the Code Behind pattern, I don’t believe MXML is just for designers. Although it is primarily targetted at describing the look of an application, it also offers features that support developers. Keeping MXML for designers means developers do not have access to MXML bindings and declarative event handler specifications. This isn’t the end of the world and developers will adapt, but it does mean that some of Flex’s more powerful features are no longer being used.

What about declarative behaviour?

Some presentation behaviour can be achieved declaratively in MXML; effects, transitions and validators are all examples. Whether Passive View permits this kind of declarative logic in the view isn’t clear. It is probably safe to leave graphical behaviour in the view and drive state changes from the presenter if necessary. Non-graphical behaviour such as validation is probably best moved into the presenter class since it is likely to be more closely related to the underlying data model.

Example application

The example application demonstrates the Passive View pattern; right-click to access the source.

Final thoughts

The Passive View pattern goes a step further than Supervising Presenter by placing additional constraints on the autonomy of the view. But what interests me most about Passive View is the way in which it achieves similar goals to the Code Behind pattern through the use of composition rather than inheritance. For me this is a reminder that there is usually more than one way to solve a particular problem, and that the popular or mainsteam approach may not always be the best option.