Understanding Paging In ASP.NET 1.x Mobile Applications

You can also enable pagination at the control level by setting the Form.ControlToPaginate property to "true", which is good for the TextView control, which holds large amounts of content (Note:. If ControlToPaginate is set to "true" and the Form control in which it sits is set to "false", pagination will still occur.) Working with the OnPaginate Event One of the events raised when your mobile page reloads due to automatic pagination is the OnPaginate event. You can handle custom logic within this event Handler; I Typically Toggle The Visibility of A "[Home]" Link Returning to a Splash Page, Like SO:

// Handle The Paginated Event

Protected Void DisplayPagenumber (Object Sender, Eventargs E)

{

LINKGOHOME.Visible = True;

}

Output Caching Paginated Content in Mobile Web FormsAny savvy ASP.NET developer knows the importance of caching and how to manage / manipulate it for optimal performance, in particular applying output caching to individual pages, which ensures frequently-accessed content loads quickly without repetitive server roundtrips to a data store. Output caching caches the entire markup of the requested resource, and can be configured to store separate cache instances for different parameter values. Specifically, the @OutputCache directive's VaryByParam allows for the page developer to specify a semi-colon delimited list Of parameters by which to vary the cache. (for more information on output caching, be sad).)

There's one caveat to be aware of when using output caching with a paginated mobile form:. Because a mobile form may be paged many times over, output caching will cause the page to display the first virtual page of cached data repeatedly This is because each time the request comes into the Web server for the next page of data, the Web server returns cached content, which contains the data from the first page. to solve this problem, you need to vary the cache by the requested page number, which is stored in the __EVENTARGUMENT HTTP POST header. Specifically, you must include __EVENTARGUMENT within the VaryByParam property to properly page through data while caching previously-viewed pages. It's a strange condition if you're used to wired output caching, but does work beautifully, as in the following code, which caches the paged contents of a news article within a mobile form for 10 minutes: <% @ OutputCache Duration = "600" Location = "ServerAndClient" VaryByParam = "__ eVENTARGUMENT; OtherParame TERS "%>

Handling Errors Due to Expired View StateAnother concern with pagination in mobile-based Web applications is expired view state, which will inevitably be a concern, and make for a nasty error when it does. With ASP.NET mobile Web forms, all data is persisted on a per-user session basis, with the hidden variable __VIEWSTATE containing only a reference to the user's specific session identifier (hence the importance of enabling session state in mobile pages, and hence the reason why view state can "expire"). By having the hidden __VIEWSTATE form field merely contain a reference to a session instance, a much smaller amount of data is passed down from the server to the client, and back again on postback.Several things could happen that might lead to a mobile web form's view state expiring. A cellular phone's battery could die while in the middle of a browsing session, or a smartphone's owner could go outside for a smoke break and simply leave the device alone for a long period of time. Thes E and MANY Other Situations Will inevitably come into play, and any of the hould force That User's session state to expire eventually.

Because a reference to the session state is held within the mobile web form's ViewState object, if the user clicked on a link within a paginated mobile page pointing to the next or previous page in the series, or tried reloading the current page with expired session state The Server Would Be Trying to Recall Non-Existent Data. In this case, the Mobile Page Framework Would INVOKE The ONVIEWSTATEEXPIRE METHOD, THROWING AN Exception of Type System.exception.

OnViewStateExpire can be overridden to allow for a more graceful departure from having the user be greeted by the .NET-generated error message. I typically redirect the user to a static splash page not dependent on persistent state data. This forces the user to reselect the link, but effectively reassigns the user with a new session. Your first thought as a wired Web developer might be to use the Response.Redirect () method to send the user to the static mobile page, but that method does not necessarily behave as expected with mobile-based applications. Instead, call Form.RedirectToMobilePage (url), passing in as an argument a string value pointing to a "safe" uRL. From there the user can navigate through the pages, working under a newly-assigned session . // Override The Default IMPLEMENTATION for Expired ViewState

Protected Override Void OnViewStateExpire (Eventargs E)

{

// do not use the base class importation, as doing so

// throws an error of type "system.exception"

// this.Response.Redirect ("http://wireless.kuam.com");

this.RedirectTomobilePage ("http://wireless.kuam.com");

}

Not your Father's Web.config File ... When creating a mobile-based Web application, I have found using the following Web.config file a good template to start with to maximize the performance of the application. I've found the sessionStateHistorySize attribute . of the mobileControls node within to be sort of misleading You may encounter errors due to expired view state (see above), which throws an exception that implies that increasing the sessionStateHistorySize will fix This is not completely true. - you'll need to tweak this value with the value you set for the timeout attribute in the sessionState node to get it work the way you want. Typically, I decrease the timeout attribute slightly while increasing the sessionStateHistorySize a bit.Also, the useFullyQualifiedRedirectUrl is Key. if you're Using Munged Urls (in which the session.Session) You'll Want To Set UsefullyqualifiedRedirecturn To "True" to Allow for Proper Redirects WITHOUT WRECKING YOTION DATA.

The following is the Web.config Template I Use in My Mobile-Based Application's:

< httpRuntime useFullyQualifiedRedirectUrl = "true" /> ConclusionIn this article I briefly touched on some of the major considerations you'll need to mull over when creating mobile Web applications that use pagination to improve the cost of Sending Large Amounts of Data To The Client. Such Sources of Large Data Can Be Long Lists, Large Amounts of Text, Or Othe .

If you're working on an ASP.NET mobile web application for the first time, all your knowledge from your experience in doing wired applications is definitely going to help, but just be aware of the differences in importance in view state, session state and output caching. Properly managing these considerations in the wireless arena will create applications that blaze, without user discomfort due to some of the hardships wireless clients have to deal with.For more information on this topic, check out the MMIT QuickStarts Tutorials and read Andy Wigley's & Peter Roxburgh's Seminal Book Building Microsoft ASP.NET Applications for Mobile Devices, SECOND Edition.