View State and Associated best practices

Few days back i gone through a very interesting article on view state. I putting some its contents as part
of this post. This post will be really very help full for the developers who are new to salesforce and
looking for good development practices.

The salesforce Summer '10 release introduced a very good feature which will really make the life of a
visualforce developer easier. Especially for those who are working on creating some big pages having
lots of fields, components and action buttons and facing the challenge of improving the performance of
the page. Each visualforce page that contains a form component also contain a encrypted form field that
encapsulates the state of the page know as view state. This view is automatically created and holds the
state of the page.

This post is to give a brief overview to view state and the best practices for optimizing the view state in
order to improve the page performance.

View state Overview:

While working on a page we are either submitting or retrieving the data to or from the server. The page
is initially retrieved with a GET request and form submissions happen via POST requests. From users
perspective all this is a state full interaction since the page state is changing based on its previous state.
But as we know HTTP is a stateless protocol, which means that the initial GET and the subsequent POSTs
requests are treated as independent requests for the page. As a result, some other mechanism is
needed to persist state information across HTTP requests.

Here come the role of view state mechanism. In view state mechanism page state is persist as a hidden
form field that is automatically created in the form when the page gets generated. View state capture
the complete state page. The view state is summited back with other form data, which gives the server
enough information to recreate the page state to which new changes can be applied.

Note: View state data is encrypted and cannot be viewed with tools like Firebug.

Getting the View State Inspector:

The Summer '10 release includes a pilot of a tool called the View State Inspector, which lets you view
the contents of the view state.This information can help you in optimizing the view state size. This
feature needs to be enabled by support - please file a support ticket to get it enabled for your
organization. Once enabled, it shows up as a tab in development mode.

Image showing view state tab:

Best practice for optimizing the view state:

As view state is associated with each page page and it has to be transferred back and forth between the
browser and Force.com, there could be a potential performance impact in terms of increased page load
times when the view state becomes large. So here are some best practices with can help one optimize
the view state size.

Minimize number of form on a page: Assume a page contains two forms - form 1 and form 2.
Irrespective of which form the user submits and causes a post back, the view state for the page needs to
get transferred. To support this, each form on your page will have its own copy of view state. If the
associated view state is large, instead of having multiple forms on a page, have a single form and use
<apex:actionRegion> to submit portions of the form. This will ensure that only a single copy of the view
state is associated with that page. You can find additional details on component here.

// Using two forms

<apex:page controller="MyController">

<apex:form>

<apex:commandButton action="{!saveAccount}"

value="Update Account"/>

<!--Account attributes available for editing -->

</apex:form>
<apex:form>

<apex:commandButton action="{!saveContacts}"

value="Update Contacts"/>

<!--Contact attributes available for editing -->

</apex:form>

</apex:page>

This can be combined into a single form by leveraging the <apex:actionRegion> component.

// Combining into single form and leveraging <apex:actionRegion>

<apex:page controller="MyController">

<apex:form>

<apex:commandButton action="{!saveAccount}"

value="Update Account"/>

<!--Account attributes available for editing -->

<apex:actionRegion>

<apex:commandButton action="{!saveContacts}"

value="Update Contacts"/>

<!--Contact attributes available for editing -->

</apex:actionRegion>

</apex:form>

</apex:page>
Declare variable as transient: An instance variable declared as transient is not saved and is not
transmitted as part of the view state. If a certain field is needed only for the duration of the page
request and does not need to be part of the view state, declare it as transient.

<apex:page controller="ExampleController">

The Current Time is : {!currentDateTime} <br/>

<apex:form>

<apex:commandLink value="refresh"/>

</apex:form>

</apex:page>

public class ExampleController {

transient DateTime currentDateTime;

public String getCurrentDateTime() {

if (currentDateTime == null) currentDateTime = System.now();

return '' + currentDateTime;

Recreate state versus storing it in view state: View state should ideally contain only work in progress
data e.g. current object being edited, multi-page wizard data etc. If you can reconstruct the data during
postback, via a SOQL query or a web services call, do that instead of storing it in controller data
members.

Use custom objects or custom settings to store large quantities of read only data: Let us say that your
controller needs to call a web service and parse a large response object. Storing it in view state may
increase the page size. Marking it as transient would incur the cost of an additional web service call and
parsing it again. In such cases, you could store the parsed response in a custom object and just use the
stored record id to get to the parsed response. Custom settings provide another mechanism to cache
data needed by your controller. Accessing custom settings is faster than access to custom objects since
custom settings are part of your application's cache and does not require a database query to retrieve
the data.

Refine your SOQL to only retrieve the data needed by the page: Only retrieve (and store) the fields you
need and also filter the data to only retrieve data needed by the page.

Refactor your pages to make its view stateless: Instead of using apex:commandLink or
apex:commandButton components (which needs to be inside a apex:form component) to invoke an
action, use an apex:outputLink or other non action method instead and implement the action through
an apex:page action attribute - where it makes sense.

Consider doing your own state management in certain case: In certain cases you may want to bypass the
view state mechanism offered by Visualforce and do your own state management. In such cases, use a
HTML FORM instead of apex:form. This technique is useful for dealing with Visualforce pages that may
have to be served to mobile devices where the view state may be too large for the embedded browsers.

Summery:

Proper management of view state will really make the job of developer easier. One can control the view
state and optimize its size by paying attention to transient variables, the number of forms on a page,
using custom settings to store data and so on.