If you want more than a quick introduction check out a recording of my presentation at JavaZone. And visit heroku.com/java for more details on how to get started running Java apps on Heroku.

Developing Java Cloud Apps
The cloud makes it easy to deploy highly scalable apps in an instant. This session will walk you through the steps to build your first Java app for the cloud. You’ll also learn best practices for building mission-critical and horizontally scalable Java cloud apps.

Then on Friday, September 2, from 10:00 am to 11:00 am I will be hosting a panel discussion:

Fireside Chat: Java on the Cloud
Come join the Java on the cloud product managers, architects, and experts for a casual, unscripted chat to find out how Java developers can best take advantage of the cloud. The session will be a mix of preselected and audience-provided questions. So bring all your tough, interesting, and quirky questions to this Fireside Chat.

I hope to see you there!

EJB Component Architecture

I remember back in the early days of enterprise Java everyone was talking about “Components.” Application complexity would be greatly reduced because there would be components for everything! Need to connect your app to Exchange? Well, there’s a component for that. Does your app need to send email? No problem, there are twenty components for that! Component marketplaces flourished with VC funding galore.

The official way to build reusable Java components became standardized as Enterprise Java Beans (EJB). These “beans” could be accessed either locally or remotely! Vendors led us to believe this was the panacea of Lego-style application development. Just grab pieces from every-which place and hook them together. Hooking the components together required a heavyweight “Middleware” server. Here is what Monolithic Middleware with EJBs looks like:

But the EJB Component Architecture didn’t work. Billions of dollars were spent on components and the middleware to tie them all together. And now I bet you can’t find a single person that doesn’t regret going that route. Why? Three primary reasons…

1. The programming model was too hard. The EJB programming model consisted of too much boilerplate code (“solved” through code-gen tools like xdoclet). EJB’s also required configuration which was often middleware server-specific. The EJB Component Architecture creates too many layers of indirection (Core J2EE Patterns anyone?).
2. Scalability was too hard. EJBs can either run inside your container (using what is called a “Local Interface”) or somewhere else (a “Remote Interface”). Using Local Interfaces is fast but causes middleware to run into memory limits and scaling bloated app servers is challenging. Using Remote Interfaces leads to massive serialization and routing overhead and whatever is on the remote end of the wire is still a pain to scale.
3. Deployment was too hard. Remember the days when starting up an app server / middleware container took minutes not seconds?

If you need further proof that the middleware model didn’t work then just try to name one place you can still go to buy an EJB component today. Obviously we needed another way to compose the parts of an application.

POJO Component Architecture

SpringSource deserves a lot of credit for pulling us out of the EJB muck. They created a model where the application pieces are Plain Old Java Objects (POJOs) injected into an application. This led to better testability, much easier deployment, and a much better programming model. Essentially the revolution of Spring was to make all those app pieces injectable dependencies. This was a huge step forward. But there are still some limitations with this model that are currently being addressed by the next revolution. The three primary challenges with the POJO Component Architecture are:

1. Isolation is too hard. It is now very easy to throw a bunch of components together into a single Web application ARchive (WAR). But at some point all of these pieces being stacked on top of each other make our application brittle and difficult to piece together. What do you do when the version of Hibernate you want to use requires a different version of an Apache Commons library than the version of XFire that you want to use? Or when two libraries that your app needs actually require conflicting dependencies. Sometimes isolating the pieces of an application is actually simpler than injecting them. And unfortunately with POJOs you may not be able to easily switch from using a “Local Interface” to an external “Remote Interface” like you can with EJBs.
2. Polyglot is too hard. The POJO components we use today in our systems are not inherently supportive of a Polyglot world where different parts of a system may be built using different technologies. Suppose your system has a rules engine and you want to access it from a Java-based application and a Ruby-based application. Today the only way to do that is to proxy that component and expose it through an easily serialization protocol (likely XML or JSON over HTTP). This will likely add unnecessary complexity to your system. When the high-level functional pieces of a system are technology-specific the entire system may be forced to use that technology or those pieces may exist multiple times to support the Polyglot nature of today’s systems.
3. Scaling is still too hard. As we continue to stack more pieces on top of each other it becomes harder to stick with simple, lightweight share-nothing architectures where each piece is individually horizontally scalable.

Cloud Component Architecture

The emerging solution to the challenges we have faced with the EJB and POJO Component Architectures is the Cloud Component Architecture. Instead of bundling components for things like search indexing, distributed caching, SMTP, and NoSQL data storage into your application those high level functions can instead be used as Cloud Components. There are already numerous vendors providing “Component as a Service” products like MongoDB, Redis, CouchDB, Lucene Search, SMTP, and Memcache.

SMTP / outbound email is a simple example where the Cloud Component Architecture makes a lot of sense. With the EJB and POJO Component Architectures I’d find a SMTP component that simply sends email. Then configure my server to be able to send emails that aren’t considered spam. I’d also need to deal with constant blacklisting challenges and a larger management surface. Or in a Cloud Component Architecture I could simply sign-up with one of the SMTP as a Service providers like AuthSMTP or SendGrid and then just use the Component as a Service.

Here is what the new Cloud Component Architecture for application composition looks like:

The top six benefits of the Cloud Component Architecture are:

1. Simple scalability. By making each functional piece of an application an independent and lightweight service they can each be horizontally scaled without impacting the overall application architecture or configuration. If you chose to use a vendor’s Component as a Service then they will handle the scalability of those pieces. Then you only need to scale a very thin web layer. Composing Cloud Components also makes it easier to stick with a share-nothing architecture that is much easier to scale than the traditional architectures.
2. Rapid composition. Cloud Components are flourishing! Most of the basic building blocks that applications need are now provided “as a Service” by vendors who maintain and enhance them. This is a much more erosion-resistant way to assemble applications when compared to the typical abandon-ware which is prevalent with many Java components. Many of the emerging Cloud Components also provide client libraries for multiple platforms and RESTful APIs to support easy composition in Polyglot systems.
3. Reduced management surface. With Cloud Components you can reduce the number of pieces you must manage down to only the stuff that is unique to your app. Each Cloud Component you add doesn’t enlarge the management surface like it does in typical component models where you own the implementation of the component.
4. Simple Deployment. One of the biggest benefits of using the Cloud is the ease of deployment. Partitioning the functional pieces of an application makes it thinner and easier to deploy. With Cloud Components you can also setup development and staging instances that make it easy to simulate the production environment. Then moving from one environment to another is simply a matter of configuration.
5. Better Security. In most application architectures today there is one layer of security. This would be like a bank without a vault. There are a few ways into the bank that are wrapped with security (doors with locks) but as soon as someone has found a way in, they have access to everything. With Cloud Components security can be more easily distributed to provide multiple layers of security.
6. Manageable costs. With Cloud Components your costs can scale with your usage. This means it’s easy to get started and grow rather than make large up-front investments.

The Cloud Component Architecture may seem similar in ways to the old EJB and POJO Component Architectures because it is similar! The wheel has not been reinvented, just improved. The dream of Lego-style application assembly is now being realized because we’ve come full circle on some old ideas from twenty years ago (CORBA anyone?). This time around those ideas are reality thanks to the evolution of many independent pieces like REST, Polyglot, and the Share-Nothing pattern. Cloud Components are the foundation of a new era of application development. My only question is… How long before we see the UDDI idea again? ;)

(If you have already signed up for Heroku, installed the heroku command line client, and installed git then skip ahead to Step 6.)

Step 1) Sign up for Heroku

Step 2) Install the heroku command line client

All of the Heroku management tasks are exposed through a RESTful API. The easiest way to call those APIs is using the heroku open source command line Ruby app. To install the heroku command line I first had to install Ruby. I’m on Ubuntu Linux so this process will be slightly different if you are on Windows or Mac but the Heroku Dev Center provides more information on how to do this on Windows and Mac. On Ubuntu you can install Ruby with apt-get (or various other tools):

sudo apt-get install ruby

Now download RubyGems, unpack, and then install it:

sudo ruby setup.rb

This installs the gem utility at /usr/bin/gem1.8 but I also created a symlink to it so I can run it with just the “gem” command:

sudo ln -s /usr/bin/gem1.8 /usr/bin/gem

Now the heroku gem can be installed:

sudo gem install heroku

Heroku should now run from the command line:

heroku

You should see something like:

Usage: heroku COMMAND [--app APP] [command-specific-options]
 
Primary help topics, type "heroku help TOPIC" for more details:
 
  auth      # authentication (login, logout)
  apps      # manage apps (create, destroy)
  ps        # manage processes (dynos, workers)
  run       # run one-off commands (console, rake)
  addons    # manage addon resources
  config    # manage app config vars
  releases  # view release history of an app
  domains   # manage custom domains
  logs      # display logs for an app
  sharing   # manage collaborators on an app
 
Additional topics:
 
  account      # manage heroku account options
  db           # manage the database for an app
  help         # list commands and display help
  keys         # manage authentication keys
  maintenance  # toggle maintenance mode
  pg           # manage heroku postgresql databases
  pgbackups    # manage backups of heroku postgresql databases
  plugins      # manage plugins to the heroku gem
  ssl          # manage ssl certificates for an app
  stack        # manage the stack for an app
  version      # display version

Step 3) Login to Heroku via the command line

You can verify that everything is setup correctly by logging into Heroku through the heroku command line. This will save an API key into a ~/.heroku/credentials file. That key will be used for authenticating you on subsequent requests. Just run the following command and enter your Heroku credentials:

heroku auth:login

Step 4) Install git

The git tool is used to transfer apps to Heroku. On Ubuntu I installed it by doing:

sudo apt-get install git

Step 5) Setup your SSH key

Heroku uses SSH keys to authenticate you when you push files through git. If you don’t already have a SSH key then you will need to generate one (I used ssh-keygen).

Step 6) Create an app on Heroku

A new app needs to be provisioned on Heroku. Since Heroku supports multiple application provisioning stacks you will need to tell it the stack you want to use, unless it’s the default. For Node.js we need to use the “cedar” stack which is not the default since it’s still in beta. To do that run:

heroku create -s cedar

A default / random app name is automatically assigned to your app. It will be somethingunique.herokuapp.com. You can change the name either through the Heroku web admin or via the command line:

heroku apps:rename --app somethingunique hellofromnodejs

When the app was created your SSH key should have also been uploaded to Heroku for git access. You can manage the keys associated with an app using the “heroku keys” commands. Check out “heroku help keys” for more details.

Now that the app is provisioned it needs something to actually run! So lets build a Node.js app and then upload it to Heroku.

Step 7) Install Node.js

On Ubuntu I installed Node.js through apt-get. But first I had to add a PPA so that I could get the latest version.

sudo apt-add-repository ppa:jerome-etienne/neoip
sudo apt-get update
sudo apt-get install nodejs

For other platforms, check out the Node.js Download page.

Step 8) Create a Node.js app

I started by building a very simple “hello, world” Node.js app. In a new project directory I created two new files. First is the package.json file which specifies the app metadata and dependencies:

{
  "name": "heroku_hello_world",
  "version": "0.0.1",
  "dependencies": {
    "express": "2.2.0"
  }
}

Then the actual app itself contained in a file named web.js:

var express = require('express');
 
var app = express.createServer(express.logger());
 
app.get('/', function(request, response) {
  response.send('hello, world');
});
 
var port = process.env.PORT || 3000;
console.log("Listening on " + port);
 
app.listen(port);

This app simply maps requests to “/” to a function that sends a simple string back in the response. You will notice that the port to listen on will first try to see if it has been specified through an environment variable and then fallback to port 3000. This is important because Heroku can tell our app to run on a different port just by giving it an environment variable.

Step 9) Install the Node.js app dependencies

My simple Node.js app requires the Express Node.js library. In order to install Express, the Node Package Manager (npm) is required. Installing npm on Ubuntu was a bit trickey because I didn’t feel the regular method followed good security practices. So I followed the alternative install instructions by just cloning npm from github and then installed it from source:

git clone git://github.com/isaacs/npm.git
cd npm
sudo make install

Now we can install the node dependencies into the local project directory. Just run:

npm install .

This uses the package.json to figure out what dependencies the app needs and then copies them into a “node_modules” directory.

Step 10) Try to run the app locally

From the command line run:

node web.js

You should see “Listening on 3000″ to indicate that the Node.js app is running! Try to open it in your browser:
http://localhost:3000/

Hopefully you will see “hello, world”.

Step 11) Create a Procfile

Heroku uses a “Procfile” to determine how to actually run your app. Here I will just use a Procfile to tell Heroku what to run in the “web” process. But the Procfile is really the foundation for telling Heroku how to run your stuff. I won’t go into detail here since Adam Wiggins has done a great blog post about the purpose and use of a Procfile. Create a file named “Procfile” in the project directory with the following contents:

web: node web.js

This will instruct Heroku to run the web app using the node command and the web.js file as the main app. Heroku can also run workers (non-web apps) but for now we will just deal with web processes.

Note: Once you have a Procfile you can run your application locally using Foreman. This allows you to simulate locally how Heroku will run your app based on your Procfile.

Step 12) Store the project files in a local git repo

In order to send the app to Heroku the files must be in a local git repository. Of course you can also put them in a remote git repo (like github.com). To create the local git repo run the following inside of your project directory:

git init

Now add the three files you’ve created to the git repo:

git add package.json Procfile web.js

Note: Make sure you don’t add the node_modules directory to the git repo! You can have git ignore it by creating a .gitignore file containing just “node_modules”.

And commit the files to the local repo:

git commit -m "initial commit"

Step 13) Push the project files to Heroku

Now we need to tell git about the remote repository on Heroku which we will push the app to. When you provisioned the app on Heroku it gave you a web URL and a git URL. If you don’t have the git URL anymore you can determine it either by running the “heroku apps” command or by navigating to the app on heroku.com. The git URL will be something like “git@heroku.com:somethingunique.git” where the “somethingunique” is your app’s name on Heroku. Once you have the git URL add the remote repo:

git remote add heroku git@heroku.com:somethingunique.git

Note: If we had created the git repo before creating the Heroku app then the heroku command line client would have automatically added the remote repo to your git configuration.

Now you can push your app to Heroku! Just run:

git push heroku master

You should see something like:

Counting objects: 6, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (4/4), done.
Writing objects: 100% (6/6), 617 bytes, done.
Total 6 (delta 0), reused 6 (delta 0)
 
-----> Heroku receiving push
-----> Node.js app detected
-----> Vendoring node 0.4.7
-----> Installing dependencies with npm 1.0.8
       express@2.2.0 ./node_modules/express 
       ├── mime@1.2.2
       ├── connect@1.4.4
       └── qs@0.1.0
       Dependencies installed
-----> Discovering process types
       Procfile declares types -> web
-----> Compiled slug size is 3.1MB
-----> Launching... done, v4
       http://somethingunique.herokuapp.com deployed to Heroku
 
To git@heroku.com:somethingunique.git
 * [new branch]      master -> master

Now you should be able to connect to your app in the browser! You can also get some diagnostic information out of the heroku command line. To see your app logs (provisioning, management, scaling, and system out messages) run:

heroku logs

To see your app processes run:

heroku ps

And best of all, if you want to add more Dynos* just run:

heroku scale web=2

* Dynos are the isolated containers that run your web and other processes. They are managed by the Heroku Dyno Manifold. Learn more about Dynos.

That increases the number of Dynos running the app from one to two. Automatically Heroku will distribute the load across those two Dynos, detect dead Dynos, restart them, etc! That is seriously easy app scalability!

There is much more to Heroku and I’ll be continuing to write about it here. But in the meantime, check out all of the great docs in the Heroku Dev Center. And please let me know if you have any questions or problems. Thanks!

In 2004 I started getting into Macromedia Flex. I was amazed at how easy it was to retrieve and nicely render data from a Java back-end. In 2005 I began evangelizing Flex + Java. Following the acquisition of Macromedia by Adobe, Flex has really flourished. Adobe Flex is now the dominant RIA technology and it has been so fun to be a part of that!

Over the past seven years I’ve had so many great adventures on the client-side, but when a new opportunity on the server-side came my way I couldn’t pass it up. Starting June 6th I’ll be stepping back into the Java world to evangelize the Cloud for Salesforce.com. I’m excited to dive into some of the emerging Java/JVM technologies like Scala, Play Framework, and Clojure!

This change is certainly bittersweet for me. Flex continues to make app development easier. With things like Android support in Flex 4.5 and iOS support coming soon, the future of Flex is bright. I’ve been very privileged to be a part of the Flex community for the past seven years. This group of passionate and creative developers have taught me so many new things. Learning how to do runtime bytecode modification and co-creating Mixing Loom has certainly been one of the highlights!

As I begin this new adventure on the Cloud I’m excited about what lies ahead for Flex and for the Cloud. Both continue to help us developers build better software. I’ve hopefully helped you learn how to build great UIs with Flex. Now I will help you learn how to build solid and scalable back-ends on the Cloud!

Preceding Dreamforce is the Cloudstock event where you can see some other great presentations related to Flex and RIAs. Lee Brimelow will be doing a presentation on “Flex and Flash Platform on the Cloud” that is guaranteed to entertain and educate. There will also be presentations from Nigel Pegg on Real-time Apps and Keith Sutton on “Adobe’s Cloud Offerings for Developers and Enterprises”.

It’s going to be a great week! I hope to see you at Dreamforce 2010!

• September 28, 2010 | 6:00 a.m. PDT | 2:00 p.m. GMT | 6:30 p.m. IST
• September 28, 2010 | 10:00 a.m. PDT

This session will walk through how you can get started building applications for the web, desktop, and mobile devices using Flex and Force.com. Salesforce.com and Adobe have worked together on an extension to the Flash Builder tool which enables developers to quickly build applications on top of the Force.com Cloud platform. I hope you can join me tomorrow! Sign up now!

But no one wants to go back to the Client / Server architecture. We want to embrace Cloud Computing architectures but not lose the client capabilities. What we really need is the Client / Cloud architecture. We need a web deployment model that provides ease of deployment but also the ability to install applications on our desktops and mobile devices.

This is why I’m so excited about the new Adobe Flash Builder for Force.com. In a nutshell this is a tool that Adobe and Salesforce.com built together to enable developers to build great software using Flex for the UI and Force.com for the Cloud back-end. It’s a wonderful combination of technologies that will help many Client / Server apps make the switch to Client / Cloud.

Applications created with Flash Builder for Force.com can be run in the browser, on the desktop, and on mobile devices. These applications can be assembled from the hundreds of Flex components that are out there (check out many of them in Tour de Flex).

Check out this video to see how to use Flash Builder for Force.com to build a simple app:

As you can see, it’s very easy to get started. But I wanted to go a step further and try to build something real–something that shows a genuine use case for extending beyond the out-of-the-box Salesforce.com UI. I wanted to keep it really simple so that I could post the code here. What I came up with is this (in user story form):

• As a Salesforce.com user I want to take a photo, using my phone, of one of my contacts so that the photo can be saved to their contact record for future reference.
• As a Salesforce.com user I want to see photos I’ve taken of my contacts so that I can be reminded of what they look like.

Simple enough. So here is what I came up with:

To build these two apps I first downloaded and installed Flash Builder for Force.com. I used the Adobe AIR for Android prerelease to build the mobile app. Here is how I created these apps.

First I added a new field to Contact to store the photo. Salesforce.com doesn’t have a binary field so I used a large text field (32k limit). I’ll store the photo Base64 encoded.

Then in Salesforce.com I saved my enterprise.wsdl file. Check out a great video from Dave Carroll to see how to do this.

Now in Flash Builder for Force.com I created a new Force.com Flex Project for the mobile app. If you do this on your own and want to run on a mobile device then you will need to overlay the AIR for Android SDK on top of a Flex 4.1 SDK. Select Desktop Application as the app type. Replace WindowedApplication with just Application. And replace the F3DesktopApplication with F3WebApplication since F3DesktopApplication uses APIs that are not available on AIR for Android. (BTW: Flash Builder, Flex, and Force.com Flex Projects do not officially support mobile deployment yet. It works but there is no support and no guarantees.) If you are building a standard Web Application or Desktop Application then you can just leave the generated code as is.

Using the Data/Services wizard I connected to Salesforce.com using my enterprise.wsdl file. After the services and value objects have been generated I modified the Contact object and added a Bindable account property. The generated application already included the F3DesktopApplication Declaration used to connect to Salesforce. Due to an incompatibility with that API and AIR for Android I switched it to use F3WebApplication. In F3WebApplication’s loginComplete event handler I query Salesforce.com for Accounts and then Contacts, associate contacts with their account, and then store the contacts:

app.wrapper.query("select Id, Name from Account", new AsyncResponder(function(data:ArrayCollection, token:Object):void {
    accounts = data;
    app.wrapper.query("select Id, AccountId, FirstName, LastName, Phone, MobilePhone, Email, Title, Department, MailingCity, photoData__c from Contact", new AsyncResponder(function(data:ArrayCollection, token:Object):void {
        for each (var contact:Contact in data)
        {
            for each (var account:Account in accounts)
            {
                if (account.Id == contact.AccountId)
                {
                    contact.account = account;						
                }
            }
        }
        contacts = data;
    }, handleError));
}, handleError));

Notice in the query that I’m fetching photoData__c, which is the custom field I created on Contact to store the photo.

In the renderer for a contact I need to either display the photo if there is one or let the user add one. Here is the simple UI code to handle that:

<s:Group width="92" height="92" top="8" right="8">
    <s:Rect width="92" height="92">
        <s:fill>
            <s:SolidColor color="#cccccc"/>
        </s:fill>
    </s:Rect>
    <s:Label id="addPhoto" text="Add a photo" width="92" height="92" verticalAlign="middle" textAlign="center"/>
    <s:BitmapImage id="photo" width="92" height="92"/>
</s:Group>

When the contact is set I check to see if there is a photo and if so display it:

if (contact.photoData__c == null)
{
    photo.visible = false;
    return;
}
 
var decoder:Base64Decoder = new Base64Decoder();
decoder.decode(contact.photoData__c);
 
var loader:Loader = new Loader();
loader.contentLoaderInfo.addEventListener(Event.COMPLETE, function(event:Event):void {
    photo.source = event.target.content;
    photo.visible = true;
});
loader.loadBytes(decoder.toByteArray());

The data from the photoData__c field is Base64 decoded and then displayed using the Flex BitmapImage component.

Now when the user clicks on the photo or empty photo box I use the AIR for Android CameraUI to grab a photo, resize it, covert it to a PNG, Base64 encode it, set it on the contact, and then save the contact to Salesforce.com:

if (CameraUI.isSupported)
{
    cameraUI = new CameraUI();
    cameraUI.addEventListener(MediaEvent.COMPLETE, function(event:MediaEvent):void {
        var loader:Loader = new Loader();
        loader.load(new URLRequest(event.data.file.url));
        loader.contentLoaderInfo.addEventListener(Event.COMPLETE, function(event:Event):void {
            var bitmap:Bitmap = event.target.content as Bitmap;
 
            var result:BitmapData = new BitmapData(46, 46, false);
            var matrix:Matrix = new Matrix();
            matrix.scale(46 / bitmap.width, 46 / bitmap.height);
            result.draw(bitmap, matrix);
 
            var pngEncoder:PNGEncoder = new PNGEncoder();
            var pngBytes:ByteArray = pngEncoder.encode(result);
 
            var base64Encoder:Base64Encoder = new Base64Encoder();
            base64Encoder.encodeBytes(pngBytes);
            var encodedImage:String = base64Encoder.flush();
 
            contact.photoData__c = encodedImage;
 
            displayPhoto();
 
            F3WebApplication.getInstance().wrapper.save(contact, new AsyncResponder(function(data:Object, token:Object=null):void {
            }, FlexGlobals.topLevelApplication.handleError));
        });
    });
    cameraUI.addEventListener(ErrorEvent.ERROR, function(event:ErrorEvent):void {
        FlexGlobals.topLevelApplication.handleError(event);
    });
    cameraUI.launch(MediaType.IMAGE);
}

That’s it for the mobile app! I compiled it, exported it to an Android app, and then copied it to my phone. Pretty simple and as you can see it works! One limitation with my approach is the 32k limit of the photoData__c field. However, I think I could easily get around that by striping the Base64 encoded data across multiple fields. It’s not ideal but it would work.

To display the photo when I view a contact on Salesforce.com I created a very simple Flex app using another Force.com Flex Project. I could have also added photo upload to this application but chose to keep it simple. All it does is display the selected contact’s photo. Here is the complete code (after generating the required services in Flash Builder):

<?xml version="1.0" encoding="utf-8"?>
<s:Application xmlns:fx="http://ns.adobe.com/mxml/2009"
    xmlns:s="library://ns.adobe.com/flex/spark"
    xmlns:mx="library://ns.adobe.com/flex/mx"
    xmlns:flexforforce="http://flexforforce.salesforce.com">
 
    <fx:Script>		
    import mx.rpc.AsyncResponder;
    import mx.utils.Base64Decoder;
    </fx:Script>
 
    <fx:Declarations>
        <flexforforce:F3WebApplication id="app" requiredTypes="Contact">
            <flexforforce:loginComplete>
                app.wrapper.query("select photoData__c from Contact where Id = '" + this.parameters.contactId + "'", new AsyncResponder(function(data:Object, token:Object):void {
                    if (data.length == 1)
                    {
                        if (data[0].photoData__c == null)
                        {
                            photo.visible = false;
                            noPhoto.visible = true;
                            return;
                        }
 
                        var decoder:Base64Decoder = new Base64Decoder();
                        decoder.decode(data[0].photoData__c);
 
                        var loader:Loader = new Loader();
                        loader.contentLoaderInfo.addEventListener(Event.COMPLETE, function(event:Event):void {
                            photo.source = event.target.content;
                            photo.visible = true;
                        });
                        loader.loadBytes(decoder.toByteArray());
                    }
                }, function(fault:Object):void {
                    // ignored
                }));
            </flexforforce:loginComplete>
        </flexforforce:F3WebApplication>
    </fx:Declarations>
 
    <s:applicationComplete>
        app.serverUrl = this.parameters.serverUrl;
        app.loginBySessionId(this.parameters.sessionId);
    </s:applicationComplete>
 
    <s:Rect width="92" height="92">
        <s:fill>
            <s:SolidColor color="#cccccc"/>
        </s:fill>
    </s:Rect>
 
    <s:Label id="noPhoto" text="No Photo" width="92" height="92" textAlign="center" verticalAlign="middle" visible="false"/>
 
    <s:BitmapImage id="photo" width="92" height="92"/>
 
</s:Application>

Finally I created a custom S-Control to run the Flex app:

<object classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000" id="ContactPhoto" width="92" height="92" 
codebase="https://fpdownload.macromedia.com/get/flashplayer/current/swflash.cab"> 
    <param name="movie" value="{!Scontrol.JavaArchive}" /> 
    <param name="flashvars" value="sessionId={!API.Session_ID}&serverUrl={!API.Partner_Server_URL_90}&contactId={!Contact.Id}" /> 
    <embed src="{!Scontrol.JavaArchive}" width="92" height="92" name="ContactPhoto" 
flashvars="sessionId={!API.Session_ID}&serverUrl={!API.Partner_Server_URL_90}&contactId={!Contact.Id}" 
type="application/x-shockwave-flash" 
pluginspage="http://www.adobe.com/go/getflashplayer"> 
    </embed> 
</object>

I uploaded the compiled Flex app to the S-Control and added it to the Contact page. And that’s it! In just a few hours I extended Force.com and built a cool mobile app. I could also have easily created a desktop widget for browsing contacts and adding photos. If you are looking for a fun project to use as a way to learn this stuff that would be a good one! :)

Here are some resources to help you get started with Flash Builder for Force.com:

• Force.com Flex Quick Start Tutorial
• Force.com Flex Project APIs for Web Applications
• Force.com Flex Project APIs for Desktop Applications
• Numerous other demo applications and tutorials
• Source code for my mobile contacts demo
• Source code for my web contact photo viewer demo

Have fun building the next generation of software! Let me know how it goes.