Here’s what everyone said.  I think you’ll start to notice a theme.

• Raja Rao DV — Go through the workbooks, understand the system, then start developing.
• Ryan Upton — Workbooks. Force.com first, then Apex. Hang out on the developer boards.
• Pat “Metadaddy” Patterson — Do the workbooks, read the multitenant white paper.
• Samantha Ready — Get a Developer Edition org, hang out on Stack Exchange, and remember to Google.
• Peter Chittum — Get to know how our metadata (api overview) and security settings work.
• John Stevenson — Go to your local Force.com developer user group and build relationships with other developers.
• Josh Birk — Developer edition: get it, love it. Get to know developer.force.com and watch Force.com Fridays.
• Sandeep Bhanot — Bookmark developer.force.com & follow the @ForceDotCom Twitter account.
• April Nassi — Do the workbook, talk to Dave Carroll and attend Force.com Fridays and other webinars.

Questions? Comments? More advice on how to get started?  Post below or @ReidCarlberg.

Over the last several weeks we’ve had the great pleasure of working with Ken Krogue and Thomas Oldroyd at InsideSales.com on our third Sponsor Success Webinar, Campaign Planning is Key (click to listen to the recording).

I’ve been pretty fascinated with their smart marketing moves since I encountered their crew filming customer stories onsite at Dreamforce ‘12 and getting customer feedback while they’re at an event (when they’re already there and charged with Dreamforce energy). That’s SO SMART. And incredibly efficient.

When I came across Ken’s Forbes blog about Tradeshow Secrets, I knew we had to dig deeper into their story as part of our efforts to help partners succeed as sponsors. What got me? They had 1,057 meetings onsite and 5X ROI before they even stepped on the floor.

What we discovered was incredible discipline that everyone should emulate in one way or another. If you plan to spend a dime on an event sponsorship, or even plan to attend an event, take 30-minutes to listen to Ken’s insights.

One of my next blog posts will be an interview with Jay Baer, the author of “Youtility, Why Smart Marketing is About Help, Not Hype.” He’s going to help us think about Youtility as it applies to event participation. If it’s possible to personify this concept, Ken and his team do! Just days after we asked him to expand upon the 17 Skills they train their event teams on, he posted another blog on Forbes to share that formula. Thank you Ken and team!

On another note, the InsideSales.com team is trying to break a world record for the ‘Largest Online Seminar’ this week. Can they do it? Looking at the lineup, and knowing this crew, my bet’s on “YES”: Guy Kawasaki, Jeff Gitomer and other top sales experts and authors, and business leaders from many of the most successful companies in the salesforce.com ecosystem. Check it out –June 20th 8AM-3PM pacific.

And just as those users might prefer to have data sets in straightforward, well-defined chunks so that they can find particular results, you might prefer reading through straightforward, well-defined criteria so that you can choose the best pagination tool.

The Salesforce Pagination Tools

Fortunately, Salesforce offers several pagination tools—the query and queryMore API calls, the StandardSetController, and the OFFSET clause—and each of these tools is suited to its own use cases.

In Sean Regan‘s newest article, Paginating Data for Force.com Applications, you can find:

• What those use cases are and how they might relate to your own project(s)
• The benefits and drawbacks of each tool
• Code examples showing what the tools look like in action
• “Under the hood” explanations of how the tools work
• Common pagination misconceptions

The Technical Enablement Message

Whether you’re deciding which pagination tool to use or how to configure your sharing architecture, one key Technical Enablement message remains the same: To make the most appropriate and well-informed architectural decisions, it’s important to understand the Salesforce concepts and mechanisms supporting both what is and what isn’t seen by your users. Getting a fuller Salesforce picture makes you a more well-rounded Salesforce architect.

As this new article explains, the “best” pagination tool depends on several considerations, including whether your users typically move past the first page of results. If you read this article, and visit or revisit the following related resources, you can improve both how you and your pages perform for your organization and its users.

Related Resources

• Paginating Data for Force.com Applications
• Inside the Force.com Query Optimizer
• Database Query & Search Optimization Cheat Sheet
• Best Practices for Deployments with Large Data Volumes
• Working with Very Large SOQL Queries
• Force.com Apex Code Developer’s Guide
• Long- and Short-Term Approaches for Tuning Force.com Performance
• Architect Core Resources

About the Author and CCE Technical Enablement

Alex Dimitropoulos is an associate technical writer dedicated to the Technical Enablement team of the salesforce.com Customer-Centric Engineering group. The team’s mission is to help customers understand how to implement technically sound salesforce.com solutions. Check out all of the resources that this team maintains on the Architect Core Resources page of Developer Force.

@future
static void doFutureCall(List<AddressHelper> addresses) {
  //do something
}

But thankfully there is a way you can do. The secret sauce is the JSON serialize|deserialize methods.

Take the example of an AddressHelper object referred to above. This is encapsulated convenience object to help me pass around address details. (note:For simplicity, this helper object just includes strings, but it could easily include other types including objects, sobjects, collections etc.)

/**
 * Sample encapsulated class
 * $author: qwall@salesforce.com
 */
public with sharing class AddressHelper {

	public String street {set; get;}
	public String city {set; get;}
	public String state {set; get;}
	public String zip {set; get;}

    public AddressHelper(String s, String c, String st, String z) {
    	street = s;
    	city = c;
    	state = st;
    	zip = z;
    }
}

Using the JSON serialize method I can easily pass this to an @future method.

public with sharing class AddressFuture {

    public AddressFuture () {

	List<String> addresses = new List<String>();
	AddressHelper ah1 = new AddressHelper('1 here st', 'San Francisco', 'CA', '94105');
	AddressHelper ah2 = new AddressHelper('2 here st', 'San Francisco', 'CA', '94105');
	AddressHelper ah3 = new AddressHelper('3 here st', 'San Francisco', 'CA', '94105');

	//serialize my objects
	addresses.add(JSON.serialize(ah3));
	addresses.add(JSON.serialize(ah2));
	addresses.add(JSON.serialize(ah3));

	doFutureCall(addresses);

  }

And then, within my future method, all I need to do is deserialize the object, and you are good to go.

  @future
    static void doFutureCall(List<String> addressesSer) {

    	AddressHelper currAddress = null;

       for (String ser : addressesSer)
       {

       	 currAddress = (AddressHelper) JSON.deserialize(ser, AddressHelper.class);
       	 System.debug('Deserialized in future:'+currAddress.street);
       }
    }

That’s it. JSON.serialize|deserialize makes it amazingly simple to pass objects, even ones with complex nested relationships, to @future annotated methods. There are time though that a particular object can not be serialized due to the underlying inheritance structure. One such example is the Pattern class in Apex.

To handle these outliers, I often create my own custom getSerializable() method on my custom object. For example, I use this strategy within the Chatter Blacklist app to pass a patternHelper object to an @future method.

/**
     * return a serializable version of the patternhelper
     */
    public PatternHelperSerializable getSerializable()
    {
    	//instead of passing the Pattern object, let's just pass the regex string from
        //via Pattern.pattern() method
    	return new PatternHelperSerializable(blacklistedWord, p.pattern(), origPostBody, postCreatedById);
    }

That’s about it. You can grab the complete code for the examples above as a gist here.

The new widgets feature, available in Summer ’13, takes advantage of the same time-saving model. By combining existing Site.com page elements, such as panels, content blocks, custom code, and data repeaters, you can build widgets—in essence, your own custom page elements—to suit your unique requirements. And just like any other page element, you can reuse custom widgets on any site page or page template in your site.

In addition, when you edit the widget, your changes are reflected immediately on every page that references it. So one quick modification, such as changing the widget’s background color, could update tens of pages in your site. (Just imagine if you had to edit every…single…page!)

When you open a site in Site.com Studio, you’ll notice we’ve added a new Widgets view to the Overview tab, where you can add and manage your site’s widgets.

When you create a widget, it’s also added to the Page Elements pane, where you and your team can easily drag it onto the page.

Real-World Example: Creating a Twitter Follow Button Widget

Let’s look at a real-world example by creating a Twitter Follow Button widget that allows users to follow a Twitter account easily from any page in your site.

First, import a 16×16 pixel icon that will represent the widget in the Page Elements pane—for example, .

Then, in the Widgets view on the Overview tab, click New Widget and enter a name. Also add a description and select the imported Twitter icon.

The widget isn’t ready to use just yet, so deselect Available in the Page Elements pane and save the changes.

That’s the first step to creating a widget, but it doesn’t yet contain any content or page elements, so click the widget to open it in a new tab. Your work area is the same whether you’re building pages or widgets, so the usual Page Elements pane, Properties pane, and so on are available on either side of the canvas.

Drag a Custom Code page element from the Page Elements pane onto the canvas, and paste the following code into the dialog box:

<a href="https://twitter.com/twitterapi" class="twitter-follow-button" data-show-count="false" data-lang="en">Follow @twitterapi</a>

This code creates the button when the page loads, so to specify which user profile to follow, replace twitterapi in the URL with the profile you want to link to—for example, https://twitter.com/bitswest.

Now you need to include Twitter’s JavaScript library, so click Configure in the Edit Head Markup section of the Properties pane.

Paste the following JavaScript into the dialog box:

<script>!function(d,s,id){var js,fjs=d.getElementsByTagName(s)[0];if(!d.getElementById(id)){js=d.createElement(s);js.id=id;js.src="//platform.twitter.com/widgets.js";fjs.parentNode.insertBefore(js,fjs);}}(document,"script","twitter-wjs");</script>

And that’s it—you’ve built a simple Twitter widget! To test the widget, preview it and click the button to ensure it links to the Twitter profile page you specified.

The final step is to make the widget available for use, so in the Properties pane, select Available in the Page Elements pane.

Now you and your team can use the widget on any site page or page template in your site. You can even use it to create other widgets, such as a page header widget that contains your company logo and the Twitter widget. How you decide to combine page elements, custom code, CSS, or other widgets to create new widgets is entirely up to you!

Top Tips for Working with Widgets

• Wherever possible, use widgets to reduce duplication in your site design. This is particularly important when working with complex designs or site elements, where maintenance can be time consuming.
• Use widgets to store commonly used pieces of text, such as company names, addresses, legal text, and so on. Simply create a widget that contains a content block with the relevant text.
• When using CSS to style widgets, add the styles to the Site Style Sheet, which is the site’s global style sheet. Because every page automatically references the style sheet, you can ensure each widget will appear correctly on the page.
• If you plan to use the same widgets across several sites, consider creating a basic site to contain all the required widgets. Then, for each new site you need, just create a copy of that site. That way, each new site automatically includes all of the widgets you created.

Related Resources

• For more information about widgets, see “Widgets Overview” in the online help, and check out the Salesforce Summer ’13 Release Notes.
• For information about customizing the Twitter Follow Button widget further, check out the Twitter Developer documentation.

Simple and Complete Responses

The Connect API is a presentation layer REST API. When you issue a request, what comes back is a representation that’s easy to consume when you’re building a UI. For example, if you want to display a user’s Chatter news feed in your app, it only takes a single call to the /chatter/feeds/news/me endpoint to get everything you need to render a page—it returns the feed items, comments, likes, information about the users, and much more. Minimizing the number of network round trips is essential for mobile app performance. The more complete the representation is, the fewer round trips you need to make.

Property filtering

There’s a tradeoff in providing so much information in a response. If some of the data isn’t needed, it’s overhead: it consumes bandwidth and processing power. To address this, we introduced the ability to filter response bodies in v27.0 of the Connect API. This feature allows you to specify exactly which properties you require in the representation. For example, if you only want to include the bodies of feed items within a feed, you can make this request for a compact response:

GET /chatter/feeds/news/me/feed-items?include=/items/feedItem/body

You can also specify properties to exclude. For example, if you have no need for the clientInfo property of a feed item, you can exclude it from the response with:

GET /chatter/feeds/news/me/feed-items?exclude=/items/feedItem/clientInfo

These examples filter a single property, but you can also filter multiple properties.

Generic batching

It’s not always possible for us to provide everything you need to build a UI screen in a single API call. In v28.0 of the Connect API, we introduced a new endpoint, /connect/batch, that allows you to combine multiple subrequests into a single request. Our mobile development team loves using this feature to minimize the number of round trips their apps require.

Taking an example from our API documentation, here’s how to like a Chatter feed item (the first subrequest) and then get the total number of likes on that feed item. Notice that the second subrequest uses an inclusion filter to get only the data it needs, as described above.

POST /connect/batch

With a JSON request body:

{
  "batchRequests" : [
   {
      "method" : "Post",
      "url" : "/v28.0/chatter/feed-items/feedItemId/likes"
   },
   {
      "method" : "Get",
      "url" : "/v28.0/chatter/feed-items/feedItemId?include=/likes/total"
   }
  ],
  "haltOnError" : "false"
}

Batching for specific object types

The Connect API also offers optimized batch endpoints for files, group memberships, groups, motifs, and users. They allow you to specify a list of IDs and get information about them in one call—the data is “bulk loaded”, which means that it’s retrieved optimally from the database. Bulk loading is much faster than issuing individual calls for each ID, even if they’re done in a generic batch. Here’s an example that shows how to get information about three Chatter groups:

GET /chatter/groups/batch/0F9B000000000W2,0F9B000000005Px,0F9B000000006Tu

Paged Collections

Many of our endpoints can return a very large amount of data that a client doesn’t need. Examples include getting a user’s news feed and querying for information about the Chatter groups in an organization. Rather than returning everything, we return paged data and use opaque tokens for going to the next page and the previous page. Clients can specify the page size for greater flexibility, and we’ve chosen reasonable defaults such as 25 feed items per page.

Try the Connect API

These are some of the ways the Connect API team is enabling mobile app developers to improve the responsiveness of their apps, and we’re working on many more! Remember that even though these features are particularly well-suited for mobile apps, they’re generally applicable and have benefits for traditional web and desktop apps too. Everybody loves a performance gain.

To get started with the Connect API, see the landing page on Developer Force and the API documentation.

There’s another huge milestone Apple has passed: apps in the Apple App Store now average more than $10K total revenue per app.  There is of course a distribution with some runaway hits and a long tail. An expected payout of $10K, and an exciting blowout head of multi-million dollar apps will inspire many long nights of developers hacking to build the next big thing.

We love the app revolution, and we are convinced it’s already hit the enterprise as well.  Salesforce.com has built the leading business apps marketplace with the AppExchange, touting more than 1800 apps for business to date.  We don’t do Angry Birds. But we do know that enterprises want social, mobile and connected apps and they are willing to pay for them.  The average developer on the AppExchange makes $392,000 per app.  That’s right, almost $400K from companies including 70% of the Fortune 100. And what’s great about selling these next generation apps to businesses is that a single install in our world can sometimes account for tens of thousands of users!

We are embracing the enterprise app revolution, and we love developers. That’s why we’ve paid more than $750M to developers since we launched the AppExchange.  And it’s accelerating.  If you want to be part of this revolution, you can start today for free.

But when it comes to dealing with millions of records in a limited time frame, you might need to take extra steps to optimize the data throughput.

Optimizing Data Extraction in Force.com

Here’s a common scenario: Your business analysis team is architecting an external business intelligence (BI) system, and you want both to integrate data from your Salesforce organization into this new system and to run a daily integration. Although you have built application logic to extract only the deltas (i.e., newly inserted or updated records since the last extraction), you still have hundreds of thousands of records you need to extract from tens of millions of records in your Salesforce object. You also have a limited window in which you can complete this task as a nightly batch job, and you can’t use the weekly export service because you need to extract the data more than once per week.

Trying to get everything out from a large object in a single transaction is a problem because the query takes too long and, in most cases, times out. We recommend both architecting data extractions to retrieve only the delta (i.e., updated, newly inserted, and deleted) rows and updating those rows in the external system. However, if the number of records you need to extract is still in the millions, the first step in resolving this issue is to split or “chunk” the transaction into smaller pieces so that each request does not time out. After doing that, make each of the smaller requests complete faster, then run the requests in parallel to compress the overall time it takes to extract all of the data.

Chunking the Data into Smaller Sets

Using a date range to group data into sets can be easy and clean, but the total number of records that could fall within a given range might go above the Force.com query optimizer’s selectivity threshold. When this happens, the underlying query must do a full object scan, often leading to timeouts. (Refer to the  Database Query and Search Optimization Cheat Sheetto see what the selectivity thresholds are.) If you are certain that filtering by the date range alone will always be selective, you can use this field to chunk your data. Otherwise, using a unique ID is more reliable, and can be easily implemented by following these steps.

1. Create or use an existing auto-number field. Alternatively, you can use any number fields that can make up a unique value, as long as they are sequential.
   Note: If you are adding a new auto-number field, make sure to enable the “Generate Auto Number for existing records…” option.
2. Create a formula field that converts the auto-number field text value into a numeric value—you cannot use an index with comparison operators such as “<=” (less than or equal to) or “>” (greater than) for the text-based auto-number field. In this example, we’ll name this field “ExportID.”
3. Place a custom index on the formula field by contacting salesforce.com Customer Support.
   Hint: Depending on the characteristics and distribution of your data, adding another selective filter, such as “CreatedDate,” and placing a compound (or two-column) index might help group the data sets in a more meaningful, manageable way.

4. Run pre-queries to determine the boundaries. For example:

• To find the lowest boundary:

Select ExportID__c From YourObject__c order by ExportID__c asc null last limit 1;

• To find the highest boundary:

Select ExportID__c From YourObject__c  order by ExportID__c desc null last limit 1;

Hint: Although you should have no records with the “ExportID__c” field empty (i.e., null), look for them before running your queries so that you don’t miss them before the extraction.

5. Add a range filter to your extraction (i.e., a WHERE clause in your SOQL) to limit the number of targeted rows so that they are below the selectivity threshold. For example:

SELECT Field1__c, Field2__c, [Field3__c …]
FROM Account
WHERE  ExportID__c > 1000000
AND ExportID__c <= 1200000
;

When submitting the subsequent requests to retrieve the data, simply replace the “ExportID__c” values by incrementing the ranges until you have gone through all of your data. Things get a little more complicated if you mass delete records often. While the approach described above still works, the gaps created by deleting records reduces the number of records included in each range, making it less optimal from a performance perspective. In other words, you could have a “chunk” that returns only a few or even no rows. There is a solution to this problem, which I will cover in a later Technical Enablement post.

Increasing Data Throughput

Increasing data throughput not only shortens the time it takes to retrieve the data, but it also increases the quality of the extracted data at a specific moment in time. For example, by running the extraction during off-peak hours and within a shorter window, you are less likely to have data discrepancy issues, such as having an extracted child record in one of your queries turn into an orphan record because someone deleted its parent record before the subsequent query ran.

Here are some best practices for increasing throughput.

• Run your requests in parallel.
• Have an administrator with access to all the data perform the extraction. This practice can help you minimize sharing calculation overhead.
• Always use the Bulk API or batch Apex when dealing with large data volumes.
  Note: Your requests might not always be returned in the order that you submitted them.

If you need an extra boost to increase throughput, consider using a skinny table, which can reduce the database table joins and parallel processing that happens under the hood. It can be a good fit if you are extracting a subset of fields (fewer than 100 fields) from the base table, and if those fields’ types are supported by the skinny table. If you decide to use a skinny table, you must first create an Apex trigger to take the auto-number field (or the sequence ID field) and store its value in a static custom field because formula fields cannot be included in skinny tables.

Additional Data Extraction Considerations

• Remember that idempotence is an important design consideration in successful extraction processes. Make sure that your job is designed so that resubmitting failed requests fills in the missing records without creating duplicate records for partial extractions.
• When testing and measuring the performance of your extraction, beware of the effects of the Force.com platform’s caching. The more tests you run, the more likely that the data extraction will complete faster because of the underlying database cache utilization. While it is great to have better performance, don’t schedule your batch jobs based on the assumption that you will always see the best results.
• Be aware of the Force.com governor limits. Follow best practices for deployments with large data volumes to reduce the risk of hitting limits when executing jobs and SOQL queries.

Summary

When extracting large data volumes, consider splitting requests into smaller sets to avoid timeouts and using techniques such as indexed filtering, parallel requests, and skinny tables to maximize data throughput. In addition, when you’re designing your extraction process, keep idempotence in mind—it’s a key part of every successful integration implementation.

Related Resources

• Long- and Short-Term Approaches for Tuning Force.com Performance
• Best Practices for Deployments with Large Data Volumes
• Database Query and Search Optimization Cheat Sheet
• Architect Core Resources

About the Author

Daisuke Kawamoto is an Architect Evangelist within the Technical Enablement team of the salesforce.com Customer-Centric Engineering group. The team’s mission is to help customers understand how to implement technically sound salesforce.com solutions. Check out all of the resources that this team maintains on the Architect Core Resources page of Developer Force.

This sample shows how to load and update a chart using two different methods, highlighting how to use JavaScript Remoting to smoothly load new data and update the chart. The example chart is a simple pie chart, and updates happen when the user selects a new year to display from a menu.

“Traditional” Visualforce loads the chart data using an expression to call a controller method, and updates the data using an <apex:actionSupport> component to re-render the chart’s section of the page in response to choosing a different year. The technique is well explained in the Visualforce Developer’s Guide.

The JavaScript Remoting version relies on some JavaScript code that I’ve written myself, instead of the automatic behaviors built into Visualforce. It’s a bit more code, but it’s also more flexible, with a smoother transition when the chart is updated. The following sample is more comprehensive than any currently in the Visualforce documentation.

To start with, here’s the controller code, a straightforward expansion of a pie chart controller from the Visualforce Developer’s Guide:

public class PieChartRemoteController {

    // The year to be charted
    public String chartYear {
        get {
            if (chartYear == null) chartYear = '2013';
            return chartYear;
        }
        set;
    }

    // Years available to be charted, for <apex:selectList>
    public static List<SelectOption> getChartYearOptions() {
        List<SelectOption> years = new List<SelectOption>();
        years.add(new SelectOption('2013','2013'));
        years.add(new SelectOption('2012','2012'));
        years.add(new SelectOption('2011','2011'));
        years.add(new SelectOption('2010','2010'));
        return years;
    }

    public List<PieWedgeData> getPieData() {
        // Visualforce expressions can't pass parameters, so get from property
        return PieChartRemoteController.generatePieData(this.chartYear);
    }

    @RemoteAction
    public static List<PieWedgeData> getRemotePieData(String year) {
        // Remoting calls can send parameters with the call
        return PieChartRemoteController.generatePieData(year);
    }

    // Private data "generator"
    private static List<PieWedgeData> generatePieData(String year) {
        List<PieWedgeData> data = new List<PieWedgeData>();
        if(year.equals('2013')) {
            data.add(new PieWedgeData('Jan', 30));
            data.add(new PieWedgeData('Feb', 15));
            data.add(new PieWedgeData('Mar', 10));
            data.add(new PieWedgeData('Apr', 20));
            data.add(new PieWedgeData('May', 20));
            data.add(new PieWedgeData('Jun',  5));
        }
        else {
            data.add(new PieWedgeData('Jan', 20));
            data.add(new PieWedgeData('Feb', 35));
            data.add(new PieWedgeData('Mar', 30));
            data.add(new PieWedgeData('Apr', 40));
            data.add(new PieWedgeData('May',  5));
            data.add(new PieWedgeData('Jun', 10));
        }
        return data;
    }

    // Wrapper class
    public class PieWedgeData {

        public String name { get; set; }
        public Integer data { get; set; }

        public PieWedgeData(String name, Integer data) {
            this.name = name;
            this.data = data;
        }
    }
}

The code is pretty ordinary, except perhaps in that it supports getting chart data via two different methods. getPieData() is intended to be used in a Visualforce expression as {! pieData }, while getRemotePieData() is, as you might guess by the @RemoteAction annotation, intended to be called directly using JavaScript Remoting.

Here’s the Visualforce page, with the two different charts in separate <apex:pageBlockSection>s:

<apex:page controller="PieChartRemoteController">
    <apex:pageBlock title="Charts">

         <apex:pageBlockSection title="Standard Visualforce Charting">

            <apex:outputPanel id="theChart">
            <apex:chart height="350" width="450" data="{!pieData}">
                <apex:pieSeries dataField="data" labelField="name"/>
                <apex:legend position="right"/>
            </apex:chart>
            </apex:outputPanel>

            <apex:form >
                <apex:selectList value="{!chartYear}" size="1">
                    <apex:selectOptions value="{!chartYearOptions}"/>
                    <apex:actionSupport event="onchange" reRender="theChart"
                        status="actionStatusDisplay"/>
                </apex:selectList>
                <apex:actionStatus id="actionStatusDisplay"
                    startText="loading..." stopText=""/>
            </apex:form>

        </apex:pageBlockSection>

        <apex:pageBlockSection title="Visualforce Charting + JavaScript Remoting">

            <apex:chart height="350" width="450" data="retrieveChartData"
                name="RemotingPieChart" hidden="true">
                <apex:pieSeries dataField="data" labelField="name"/>
                <apex:legend position="right"/>
            </apex:chart>

            <div>
                <select id="theYear" onChange="refreshRemoteChart();">
                    <option value="2013">2013</option>
                    <option value="2012">2012</option>
                    <option value="2011">2011</option>
                    <option value="2010">2010</option>
                </select>
                <span id="statusDisplay"></span>
                <span id="remoteResponseErrors"></span>
            </div>

        </apex:pageBlockSection>

    </apex:pageBlock>
</apex:page>

The “normal” Visualforce chart is on lines 4-23, and the Remoting-based chart (well, most of it) is on lines 25-46. You can see that they have similar forms: both <apex:pageBlockSection>s have two blocks of their own, the chart block and the year selection menu form. The two chart blocks are nearly identical, the only meaningful difference is the data attribute for the <apex:chart> tag. The Visualforce chart uses an expression to call a controller method that provides the data. The Remoting chart data attribute is…well, it looks like just a string. I’ll get right back to that. The year selection form for the Visualforce chart uses the expected Visualforce tags, including <apex:actionSupport> to provide the refreshing and <apex:actionStatus> to display a simple “loading” message during a refresh. In contrast, the Remoting version uses static HTML, more to show that you can than because it’s required, and has no apparent way to trigger a refresh.

In the above code sample, the two charts appear to have roughly the same number of lines of code. The thing is, I left off part of the Remoting chart’s code. The JavaScript part of JavaScript Remoting. This part goes between the opening <apex:page> and the <apex:pageBlock> tags:

    <script>
    function retrieveChartData(callback) {
       var year = document.getElementById('theYear').value;
       Visualforce.remoting.Manager.invokeAction(
           '{!$RemoteAction.PieChartRemoteController.getRemotePieData}',
           year,
           function(result, event) {
               if(event.status && result && (result.constructor === Array)) {
                   callback(result);
                   RemotingPieChart.show();
               }
               else if (event.type === 'exception') {
                   document.getElementById("remoteResponseErrors").innerHTML = event.message +
                       '<br/>' + event.where;
               }
               else {
                   document.getElementById("remoteResponseErrors").innerHTML = event.message;
               }                   
           },
           { escape: true }
       );
    }
    function refreshRemoteChart() {
        var statusElement = document.getElementById('statusDisplay');
        statusElement.innerHTML = "loading...";
        retrieveChartData(function(statusElement){
                return function(data){
                    RemotingPieChart.reload(data);
                    statusElement.innerHTML = '';
                };
            }(statusElement)
        );
    }
    </script>

This is the most interesting part of the page, at least for understanding how to combine Visualforce charting and JavaScript Remoting. These two JavaScript functions are the glue between the Visualforce chart and the @RemoteAction controller method that provides the data. There are three links between the functions and the chart component you should notice:

1. The chart component’s data attribute is the string “retrieveChartData”, which is the name of the first JavaScript function. This tells the chart component to use the JavaScript function to load its data. retrieveChartData() is only invoked once by the chart component directly, when the chart is first created and the data is initially loaded.
2. Reloading happens when the second JavaScript function, refreshRemoteChart(), is called. This is the second link, and it’s actually from the year menu item, a static HTML element, which has an onChange attribute of refreshRemoteChart();. When you make a change to the menu, refreshRemoteChart() is invoked, and it re-invokes the retrieveChartData() function to load a new set of data.
3. When refreshRemoteChart() invokes retrieveChartData() it provides an anonymous function as a callback, which handles the result of the @RemoteAction call when it returns. This callback is what actually updates the chart, by calling RemotingPieChart.reload(data). RemotingPieChart is the name I gave to the chart component, on line 29 of the first sample, and reload() is a JavaScript function available on it that accepts new data and then redraws the chart.

Here’s a more visual way to see these links between the different components of the page:

The sequence for the initial loading of the chart is simple: the <apex:chart> named RemotePieChart calls retrieveChartData() to get its initial data, and retrieveChartData() calls RemotePieChart.show() when it has the data. And, the chart appears.

Updates are more complicated. When a new year is chosen from the theYear menu, the menu’s onChange event fires, which calls refreshRemoteChart(). refreshRemoteChart() in turn calls retrieveChartData(), and when that returns new data, it (via the callback it created) calls RemotePieChart.reload(). And, the chart updates.

The structure of this code sample may seem complicated at first, but it provides a great deal of flexibility in what to display or change at various points in the update cycle. Once you study it a bit, and spend some time writing JavaScript user interface code, you’ll find that it’s perfectly natural.

Here are a couple of other items to note.

• The <apex:chart> uses the hidden="true" attribute to prevent the chart from displaying before there’s data to display. The retrieveChartData() function calls RemotingPieChart.show() to display the chart once the chart data is loaded. This and RemotingPieChart.reload() provide for much smoother chart animations than what is achieved using <apex:actionSupport>. Add this code into your own org and compare the two.
• The refreshRemoteData() function sets the statusElement HTML <span> to a “loading…” message before it attempts to update the data by calling retrieveChartData(), and then the anonymous callback function sets it to an empty string to hide the message once the data is returned and the chart updated. It’s a bit more work than using <apex:actionStatus> for basically the same effect. You could easily show a “busy” animation or graphic using the same technique.

This article was inspired by a recent post in the Visualforce discussion forum, which asked about using JavaScript Remoting to load and update chart data, and how to get the chart to draw with that data. We answered the question in the discussion, but I wanted to also expand the existing documentation on the topic. The code sample in this article, and the explanation (in substantially different form), will appear in a future edition of the Visualforce Developer’s Guide. I hope it’s useful, and interesting, to get a preview of that documentation a little early.