Thursday, May 14, 2015

Crossing Over To The Dark Side Through Salesforce View State

Over a year ago I decided to make the plunge from the world of .NET development over to the world of Salesforce development. At the time it seemed to be something that no .NET developer would ever dream of doing and I wasn’t quite sure why. Everyone gets comfortable with what they know, but I think the largest misperception at the time was the understanding of the complete Salesforce stack. Whenever I heard the word Salesforce, I immediately thought of CRM. I believe this misperception exists not only among developers, but spreads all the way up through sales people.

Yes, Salesforce has CRM capability through the Sales and Service cloud, but this is a small subset of what the entire stack offers. While the CRM portion of Salesforce is handled by configuration experts, two other sections of the stack create an ample amount of customizations that are implemented through standard development practices. offers custom development across applications that can be sold through the app exchange or private code for organizations. Virtually everything that can be built on the .NET platform can be built using Another area is around products such as Salesforce Communities. This is an example where you get a combination of some out-of-the-box configuration options, but have the ability to write as much custom code and functionality as needed. Salesforce Communities currently competes with SharePoint and Sitecore as you can now expose content publicly on your community.

When I first began my Salesforce development, one of the first things I had exposure to was the view state and asynchronous apex. Although this only scratches the surface of writing custom code within Salesforce and these examples are primarily client-side, it’s a glimpse into Salesforce development. As we go through the following examples, you will find a lot of similarities that coincide with other development.

Assumptions before we get into everything:

…you should have a general understanding of view state. should have a general understanding that Visualforce code is front-end and Apex is back-end. should understand HTML, JavaScript, and AJAX concepts and know this all works within Visualforce.

View State - What is view state?

The view state is a way for Salesforce to capture the current state of the controller that backs the page as well as all the content entered by the user on the front-end. Other items that exist within the view state as well are the number of components on a page and number of expressions. All of this is encrypted and is found through a hidden input field and since it’s encrypted and manages a lot of items on a page, it can get quite large. One final thing to remember is you need to have an apex:form tag on the page for it to exist.

The View State Life Cycle

A. URL Requested (URL of a VF page does a get request to a page.)
B. Apex Controller Instantiated on Server (That page is backed by a controller which creates all the variables.)
C. Controller State Serialized & Encrypted to View State (That snapshot from the controller is sent via the encrypted hidden input field down to the page.)
D. Page Markup Sent to Browser & Rendered (That gets sent down to the browser.)
E. View State Decrypted & Deserialized (for Postbacks) (The cycle continues with partial page updates and restarts if you do a full postback.)


Source: Wilson, E. Advanced Visualforce Webinar

View State Pros - The view state is great for keeping track of field values that users put on a page as it maintains the state for you automatically. All you have to do is include a re-render component and you’re good to go.

View State Cons - What to watch out for is the larger your view state, the slower your page will load. The size limit that corresponds to view state is 135k. You can’t do anything like conditional re-rendering, send it to one endpoint or another, or pass up parameters.


Below are a few ways to manage the view state

● Reduce Number of Components
● Use the Transient Keyword
● JavaScript Remoting
● Use Streaming API

1 - Reduce Number of Visualforce Components That Auto-Build Code - MMM…Having all Visualforce tags are bad.

● <apex:outputPanel - Remove output panel for a span or div.
● <apex:panelGrid - Remove panel grid for a table.
● <apex:outputLink - Remove output link for an anchor tag.

By doing this, the view state size will be reduced and you will increase speed.

2 - Transient Keyword - Allows you to take any member variable of your controller out of your view state = Amazeballs

If you know that a variable from your controller doesn’t need to be exposed or used by your front-end code, there is no point in making it available. You’re simply passing more data than you need. Take a lesson from The Big Lebowski and don’t let the plan get too complex. Make that controller variable transient and problem solved.

3 - JavaScript Remoting - Stateless way to call Apex Controller Methods


Before JavaScript remoting was available, you had to use action tags. JavaScript remoting is very similar to action tags as far as the life cycle goes, but what you get back from JavaScript remoting is simply what you need. A list of contacts or accounts in a JSON string. In comparison, the action tags transmit everything.

The way JavaScript remoting works is some event calls a function and rather than getting a standard HTML table, you end up with a data table. You tag an Apex or controller method within the back-end code with @remoteaction and Salesforce automatically creates some JavaScript to send down. This is a big deal since you can now pass in arguments where the action function previously would not allow you to do so. You can pass any single parameters you want or a comma separated list of them while your callback method gets the results and the event parameter gives you any possible errors. Another performance difference with the action tag versus JavaScript remoting is with action tags everything is within the global namespace and with remoting, separate objects exist for each of the controllers so you can nest them within those namespaces. The key thing to remember here is the remoting example is simply sending what we need. The action function passes the entire markup and equals a massive savings in time.

4 – Streaming API - A highly performant way to get near real-time updates from a Salesforce instance without polling.


Source: Wilson, E. Advanced Visualforce Webinar

Before the streaming API, action poller allowed for similar functionality, but it required more markup and an inefficient way of receiving real-time updates. The bottom line is action poller was not very good for performance, was limited with what you could do, and had conditional re-rendering. You can see in the example above that this is going to check for an update every fifteen seconds regardless of whether their is new data to receive or not.

The streaming API requires a little more JavaScript knowledge, but is a lot simpler on the markup side. The streaming API makes you include a few libraries such as jQuery and the comedt library, which is a JavaScript implementation of a protocol. You initialize a method and then subscribe to a push topic, which holds a soql query that contains whatever data you’re looking to get out. The major difference here is the action poller always keeps a connection open whether you have data to receive or not while the streaming API says hey, you have new data waiting, request it from me. Overall to implement the streaming API you want to determine your SOQL query, create a push topic record, include necessary JavaScript libraries on your VF page, call cometd and subscribe, and watch real-time updates flow in.

Hopefully this gives you a glimpse into the world of Salesforce development. Recently, our team at Rightpoint used the streaming API example to combine .NET applications and Salesforce Communities. We exposed .NET applications using something called Canvas within Salesforce, which is basically an advanced iframe. We could then pass information back to Salesforce from these applications and have a streaming API wait for any real-time updates to display to the Salesforce Community user. This is just one example where this can be used to write some interesting code and in this example, even bring together the worlds of .NET and Salesforce.

***Resources I have used to learn this information and have sourced some in this article.

Advani, Sonia
Advani, S. (2014). Master Visualforce. [Blog] Salesforce Developers Blog. Available at: [Accessed 15 Jan. 2015].

Battisson, Paul
Battisson, P. (2015). Best Practices for Improving Visualforce Page Performance. [Blog] Salesforce Developers Blog. Available at: 01/best-practices-improving-visualforce-page-performance.html [Accessed 13 Jan. 2015].

Wilson, Eric
Salesforce, (2012). Advanced Visualforce Webinar. [video] Available at: PZkbM#t=1187 [Accessed 13 Jan. 2015].