Building Microsoft ASP.NET Applications for Mobile Devices, Second Edition [Electronic resources] نسخه متنی

Programming and Configuration Techniques

You can optimize your application's throughput in a variety of ways. We'll now take a look at a number of different things you should consider; some or all of them will apply to your own mobile Web applications.

Turn Off Debug Support in Your Release Builds

The first technique for enhancing performance is to be sure to turn off debug support in your runtime builds. (It's easy to forget to disable this.) Remember that the runtime compiles each requested page using just-in-time compilers. If your application has debug support enabled, this can have a serious effect on response time. Here's how to ensure that debug support is disabled in the application's Web.config file:

<configuration>    
<system.web>
 
<compilation debug="false"/>
 
</system.web>
</configuration>

Disable ViewState If It's Not Required

ViewState enables the ASP.NET server controls to store all their property settings across HTTP requests. At the end of one request, the runtime stores the controls' property values in the ViewState. At the beginning of the next request, the runtime reinitializes the controls with values from the ViewState, thus restoring those controls to their state at the end of the previous HTTP request.

In many cases, this technique isn't necessary and wastes time. Consider a data bound List control. There's no point in this control saving its ViewState if the control is bound to its data source on every request. Saving the ViewState would just restore all the List control's properties from this state, only to have the runtime overwrite them again the next time the control is data bound.

To disable ViewState for a server control, set its EnableViewState property to false. Alternatively, you can disable ViewState for a whole page by setting the EnableViewState attribute of the @ Page directive to false:

<%@ Page EnableViewState="false" … %>

Disable Session State If It's Not Required

Your application can store data for a particular user and make it available throughout his or her session by using the Session object. If your application doesn't require this functionality, you should disable it completely. To disable session state for a whole page, set the EnableSessionState attribute of the @ Page directive to false:

<%@ Page EnableSessionState="false" %>

If a page requires access to variables stored in the Session object but doesn't create or modify them, set the value of the EnableSessionState attribute to ReadOnly. (We described the use of the Session object in Chapter 12.)

Cache Data in the Application Object

In many applications, you might have many Web clients running the same application, all accessing the same resources. An optimization technique that can yield real benefits is to open shared, read-only or infrequently modified resources in the Application_Start method in the Global.asax file and cache the data in the Application object. Each process servicing a client then accesses the data from there instead of retrieving it from the source again, which can benefit the performance of your application.

The following code in the Global.asax file uses the AuthsComponent data component that we developed in Chapter 11 to retrieve a DataSet object, which the code stores in the application state:

public void Application_Start()
{
// Create the data component. 
AuthorsDataComponent.AuthsComponent myDataComp = 
new AuthorsDataComponent.AuthsComponent();
// Use the data component to fetch a DataSet.
AuthorsDataComponent.AuthsDataSet ds = myDataComp.AllAuthors;
// Store the data source in the application state so that
// the data source is available to all clients.
Application["AuthsDataSet"] = ds;
}

Each request can then access the data source from the Application object in the Page_Load method, rather than fetch it from the database again:

void Page_Load(Object sender, EventArgs e) 
{
DataSet sourceDS = (DataSet)(Application["AuthsDataSet"]);
 
List1.DataSource = sourceDS;
List1.DataMember = "authors";
 
}

Use Custom Pagination with the List Controls

If you're loading large DataSet objects into the SelectList, List, and ObjectList controls, or the list contents require extensive computation time to build the row items, consider using custom pagination. (For a refresher on this technique, see Chapter 6.) The code supplies data to the control only when the control must be displayed, thus avoiding long delays during the initial load of a control.

Don't Perform Unnecessary Processing on Postback

Another optimization technique is to use the MobilePage.IsPostBack property to avoid unnecessary processing on a postback. You use the IsPostBack property to determine whether this is the first time the page is being displayed or whether it's loading as the result of a subsequent postback from the client. Often, the processing that the runtime must perform when the page first loads isn't required on subsequent loads. An example of this is binding a control to data.

Concatenate Strings Using System.Text.StringBuilder

You can also enhance your applications by concatenating string objects using System.Text.StringBuilder. If you use the addition operator (+) to concatenate string objects, the runtime must create a new String object to contain the result because strings are immutable. If your application performs a lot of string concatenation, it's much more efficient to use the StringBuilder object:

StringBuilder detailText = new StringBuilder();
detailText.Append("This block of text ");
detailText.Append("will be <b>displayed</b> in a ");
detailText.Append("TextView Control.");
TextView1.Text = detailText.ToString();

The performance benefits are particularly pronounced if you are concatenating large numbers of strings. In fact, in the example just shown, the performance advantage is negligible, but if your application needs to concatenate more than 9 or 10 different strings, the StringBuilder yields real performance benefits.

Optimize SQL Server Data Access

Using SQL-stored procedures for data access will help to optimize your mobile applications too. When you retrieve data from Microsoft SQL Server, it's much more efficient to compile stored procedures than ad hoc queries.

Using SqlDataReader or OleDBDataReader for data access can further optimize your applications. Use one of the DataReaders if you need just forward, read-only access to data retrieved from a database. Although using a DataReader provides better performance than using a DataSet, it doesn't support data updates.

Explicitly Declare Object Types in Visual Basic .NET

A final way you can help boost application performance is to explicitly declare data types when you're programming in Microsoft Visual Basic .NET. By default, ASP.NET doesn't enforce the explicit declaration of variable types. However, this flexibility has a performance cost. If possible, add the Option Explicit declaration at the head of your Visual Basic code-behind modules and other class modules. The Option Strict directive, which is even more stringent, permits you to set a variable to the value of a different type of variable only if there's no risk of truncation or loss of precision.

In your .aspx Web Forms page, you can enable Option Strict for any contained code by using the Strict attribute in the @ Page directive, as follows:

<%@ Page Language="VB" Strict="true" %>