I am blown away by how well Adobe is positioned to own the screen. Flash really is everywhere. The product team has done a tremendous job making it available on all these devices and  adapting and optimizing it for the hardware.

Where’s there is Flash there is AIR. If Flash is our trojan horse then AIR is our army. Its ever expanding APIs make it easy to develop applications that are specific for the device by allowing us to leverage their individual capabilities.

It’s just so easy!

You can start building multi-screen applications today by downloading Flash Builder “Burritto”.

There are also significant improvements for designer-developer workflow, which you can use in Flash Catalyst “Panini”.

.

To get an application in to production for the first time requires a lot of resources, especially if compliance is required, for example FDA software validation. However, we rarely stop once the application go-lives. We want to release new features and modules, but we don’t want to re-test the whole application. There is a new version of the Flex SDK that we want to use, but we don’t want to migrate the entire codebase. So we think about using the Marshall Plan.

We are dealing with a lot of complexity and big architectural decisions. Mosaic helps to remove the complexity by providing an application framework for building and deploying composite applications. It also provides tooling for Flash Builder to improve developer productivity.

What follows is three steps to walk you through building your first Mosaic application. From there you can explore Mosaic in more depth so you can start using it as part of your enterprise architecture for building scalable and extensible Rich Internet Applications (RIAs).

Prerequisites

• Flash Builder 4 (I recommend using the Eclipse plugins with Eclipse for Java EE Developers)
• Apache Ant

Step 1: Getting Mosaic running

• Download the Mosaic trial
• Extract the Mosaic download (if not auto extracted)
• Open a command prompt and change directory to where you extracted Mosaic (<MOSAIC_HOME>)
• Change directory to <MOSAIC_HOME>/standalone
• Create a logs directory (e.g. mkdir logs)
• Change directory to <MOSAIC_HOME>/standalone/bin
• Run startup.sh / startup.bat (if running Mac OS X or Linux you may need to change the permissions on your files – chmod 755 *.sh)
• Start a browser and open http://localhost:8080/mosaic/about, when promoted to log in enter designer/password
• If you see the Adobe copyright and Mosaic version then Mosaic is running!

Step 2: Install and run the samples

• At the command prompt change directory to <MOSAIC_HOME>/samples
• Run ant (enter ant at the command line)
• Ant should run for ~9 seconds and you should see BUILD SUCCESSFUL
• In your browser open http://localhost:8080/mosaic/#/applications/Basic
• You should see your first Mosaic application
• Now try the AIR client, run <MOSAIC_HOME>/bin/release/Mosaic.air
• Take the time to explore the other samples, the table at the bottom of this page has all the URLs

Step 3: Build your first Mosaic application

• Download the Mosaic ES2 plugin for Flash Builder 4
• Start Flash Builder (Eclipse)
• Go to Help > Install New Software…
• Press the Add… button
• Enter a name e.g. Mosaic
• Press the Local… button and select the folder containing your Mosaic plugin folder (assuming your download was auto extracted)

• Press the OK button
• Check Adobe LiveCycle RIA Tooling

• Press the Next button and follow the wizard to install the plugin
• Create a new Flex Application (File > New > Flex Project)
• Create a new MXML Tile (File > New > MXML Tile)

• Press the Finish button
• When prompted to Confirm Project Changes press the Yes button

• Update your tile to show the obligatory Hello World:

• Open the Run Configurations (Run > Run Configurations…)
• Select Mosaic Launcher
• Press the New button
• Make sure your Project and Tile are selected

• You should now see your first Mosaic application!
• You will find more details of using the plugin and debugging here

Additional Resources

• Adobe LiveCycle Mosaic home page
• Adobe LiveCycle Mosaic 9.5 Help
• Adobe LiveCycle Mosaic portfolio (which includes a technical guide)
• Adobe LiveCycle Mosaic ships blog (which includes other getting started resources)
• Adobe LiveCycle Mosaic Team blog

You can read more about Adobe and Blue Button here.

The LCDS attack surface is very small, but there are a number of things to consider:

• Use AMF in production (also consider AMF for performance as it is better at handling large complex Object graphs).
• If you are using AMFX use LCDS 3.1, which fixes a number of known XML vulnerabilities. If you are unable to upgrade to LCDS 3.1 then you should apply this security patch.
• Use secure channels (refer to Using LiveCycle Data Services ES2 Version 3.1).
• If you are using the proxy service then secure it as per this post.
• If you are concerned about XSS attacks then validate incoming client data using a custom queue processor (refer to Using LiveCycle Data Services ES2 Version 3.1).
• Try to ensure end users are on the latest Flash player.
• Ensure RDS is not enabled in production (comment out the RDSDispatchServlet in web.xml).
• Make sure your app server is secure per best practices of the vendor (you should also look at Hardening and Security for LiveCycle ES, which provides some general recommendations).

There are a number of useful resources that discuss securtiy:

• Enterprise security for Flex
• Creating more secure SWF web applications
• OWASP Flash Security Project
• Adobe Flash Player 10 Security
• Adobe AIR HTML Security

The following tools can be used to help find and fix security vulnerabilities:

• IBM Rational AppScan
• HP SWFScan

As professionals we have a responsibility to write clean code from the start. The customer may feel we are moving slowly but we are investing in the future maintainability of the software. Through TDD we are building testable software and providing the team with the confidence to Refactor. In turn Refactoring allows us to evolve our design so they remains simple. The story is similar for the other practices of professional software engineering.

As the software grows the teams has pride in the software they are engineering. The quality is high and its easy to change the software as new requirements are implemented. In the end customer satisfaction is high, why wouldn’t you practice TDD and Refactoring from day-1?

**The Cause**When the application is started in its default size there are no scrollbars. If the user resizes the application to be smaller then scrollbars are added. If you look in the **Container** class there is a function called **createContentPane()**. This function is called prior to adding the scrollbars. Its responsibility is to create a content pane (a **FlexSprite**). When it creates the content pane it reparents all the children i.e. it adds each child to the content pane and then tells the child that its parent has changed by calling **parentChanged()**. The net result is we see **removedFromStage** and **addedToStage** fired. On subsequent resizing the content pane remains, once it is created it is never removed or recreated.**Workarounds**I found a couple of workarounds. The first is to put a guard condition in your event handlers for the **removedFromStage** event and the **addedToStage** event. The guard condition can check the **creatingContentPane** property on the parent Container.The second workaround is to create the content pane up-front. The **createContentPane()** function is in **mx_internal** namespace so you can override **createChildren()** on the Container and call **createContentPane()**.The downside to creating the content pane up-front is you will increase the memory footprint, the size of this increase will depend on the size of your application.**Recommendations**My recommendation would be to discourage attaching logic to the **removedFromStage** event and the **addedToStage** event. As was shown here they weren’t expected on resize and unexpected behavior was introduced in to the application. There are workarounds but you need to consider how you enforce the workaround within the team. If you can’t enforce them, then don’t do it.**Test Harness**For the purpose of understanding the behavior and testing the workaround I created the following test harness.

=

If you are a talented software craftsman who has a strong background in enterprise software engineering then we want to hear from you. There is no prerequisite to know Adobe’s technology, although it would be nice, if you are steeped in OO and advocate practices such as Test Driven Development and Refactoring then we will train you in Flex/AIR, LiveCycle Data Services and LiveCycle ES.

We also want to hear from you if you are a leader in Quality Engineering, we need people who can lead the team on process and practice. Ideally you will have strong hands-on experience of all aspects of Quality Engineering such as black-box testing, white-box testing, automation, performance testing and load testing.

In both the above roles a working knowledge of Scrum is a huge plus.

If you want to be part of our team then drop an email to “pmartin@adobe.com”:mailto:pmartin@adobe.com.

I recently read a blog post from Mike Cohn on “The Forgotten Layer of the Test Automation Pyramid”:http://blog.mountaingoatsoftware.com/the-forgotten-layer-of-the-test-automation-pyramid. I thought this was a great way to conceptualize the different forms of testing and their combined value.

**Unit Testing**Unit testing is your foundation for quality, it requires pragmatism and you don’t need a 100% coverage for it to make a difference. I have also found from my own experience it is not necessarily about catching bugs in the future (which it does help) but more about driving out good design and giving engineers the confidence to refactor in the future. Don’t underestimate the value in the latter point, you wrote the code so you understand it, but will someone joining the project in 6 months time have the confidence to change your code?**Integration Testing**The next layer up is integration testing. Before I go any further I want to interject at this point and briefly discuss semantics. A unit test should test the smallest possible piece of software, normally a single class, without any dependancies. An integration test should test a component or a service with its dependancies, for example a call to a remote service or a local database. I tend to reserve integration tests for when there is an infrastructure dependancy. My preference is also to differentiate between the two and put them under different source packages. The intent is different so be explicit.Back on subject. I have found integration tests to be invaluable. They provide you with a huge amount of confidence if you can test a call to a service and assert the expected result. It also helps problem determination if you can isolate the data tier of your application and run the integration test suite. There is a higher cost to integration testing though. The actual test in itself is often easier to write than a unit test, but their dependancies, set-up and tear-down introduce complexity. For example, consider a call to the database, for the test to be repeatable you need to start with a known state, when you complete you need to revert back to that state. You also find your tests are more susceptible to the order in which they run. For example, what if I have a service for creating a user, another for adding a project and third for permissions on a project. You will need to run them in that sequence if they are going to pass. Take a look at the “Cairngorm Persitence Library”:http://opensource.adobe.com/wiki/display/cairngorm/How+to+Use+the+Cairngorm+Persistence+Library for an example of unit tests and integration tests.**Functional Testing**The top of the pyramid is functional testing. If we can automate our functional tests we have huge opportunity to quickly assert the system is working as expected and to catch bugs early. Functional testing requires a lot of manual effort and time from a Quality Engineering team. If we can automate we get a payback on that effort and are able to reduce the testing cycle. When investing in functional testing is also worth considering the customer satisfaction. I am sure we have all been in the position where we deliver a working feature only for it to break it in the next release. This often erodes confidence with the customer who can’t understand why you broke something that was previously working. If we have a repeatable mechanism for running our test suite we can apply a consistent level of testing. The downside to functional testing is typically the cost, the tooling costs (although there are opensource alternatives) and there is the investment in time. I would encourage all projects to invest in functional testing from day-1. Too many projects don’t start with automated functional testing as “they don’t have enough time”. As they reach a critical mass of functionality the value becomes apparent and they do a u-turn. At this stage you are playing catch-up and it difficult to realize the value – it’s often too late. Quality is an investment. Your velocity will be slower at the start but you will gain momentum and you will see payback in terms of effort, a reduction in defects, higher quality and ultimately a happier customer.**Summary**High quality comes from a strategy that combines unit testing, integration testing and functional testing. Doing one on its own doesn’t assure quality. 100% test coverage comes the aggregate.

_”Assertions and the associated concepts, explained in this chapter, provide some of the answers. Although not foolproof, the mechanisms presented below provide the programmer with essential tools for expressing and validating correctness arguments. The key concept will be Design by Contract: viewing the relationship between a class and its clients as a formal agreement, expressing each party’s rights and obligations. Only through such a precise definition of every module’s claims and responsibilities can we hope to attain a significant degree of trust in large software systems.”_

I also want to cite another great book that has gained favor with many of my peers, “Clean Code: A Handbook of Agile Software Craftmanship by Robert C. Martin”:http://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882/ref=sr_1_1?ie=UTF8&s=books&qid=1267554535&sr=8-1. Chapter 7 discusses Error Handling and promotes that we don’t return null from methods and nor should we pass null to methods as both invite errors. As it says in the book _”all it takes is one missing null check to send an application spinning out of control”_.

I first used Design by Contract in the late 90′s and the results were dramatic. We saw a big improvement in code quality as we were thinking about the contract between a method and its caller. In the Java world we now have a number of mature Design by Contract libraries such as Contract4J. Take a look at it discusses the theory in more detail than I am.

A while back I created an over-simplified library for ActionScript. It’s really, really simple. There is one main class, Contract, that you can use to assert pre and post-conditions.

It works off a compiler argument (**-define=CONFIG::debugging,true**), for development set it to **true** and your assertions will be checked. For production, set it **false** and your assertions are not checked.

It’s simple but effective. Download it “here”:http://blogs.adobe.com/pmartin/code/Contract.zip.