Understanding Pagination in ASP.NET 1.x Mobile Applications

原创 2004年09月29日 12:38:00

Even for experienced ASP.NET developers, authoring mobile Web applications can be tricky. Many of the facilities and features that make ASP.NET 1.x such a great platform on which to develop great apps are available in the mobile venue through the Microsoft Mobile Internet Toolkit (MMIT). The MMIT includes built-in features for preserving data through view state and session state, caching, and centralized configuration. However, the means by which the MMIT accomplishes these ends is not always as you might expect. The challenges presented by the MMIT are due to the very important differences between desktop Web and mobile Web platforms. It's essential for astute ASP.NET programmers to be aware of these differences and how they can affect the behavior of their applications.

One such major difference is that in a desktop-based Web browser, the end user can view all of the Web page's data at once. For mobile devices, however, there is often limited screen real estate. Cell phones, for example, might only allow a dozen lines of text to be viewed at a time. In order to send the appropriate amount of data to a mobile browser, the MMIT uses a technique known as pagination, which breaks up the returned content into correctly-sized chunks. In this article we'll examine MMIT's pagination features and how they affect mobile application development.

Paging in Mobile Web Applications
Paging in mobile Web applications is largely variable and dependent upon the individual device and the server settings of a service provider. As an example of the former, one of my site's 15,000-character news articles may either be read entirely on a single scrollable WAP page on a smartphone, but may be paged seven times on a smaller-resolution cellular phone that can only handle 35 lines of data per screen. As an example of service provider limitations, a local cellular service provider constrains the size of content that can be sent down to the client to about 1,300 characters per virtual page.

The Importance of ViewState in Mobile Web Applications - Turn it On!
In non-mobile development, we as ASP.NET programmers are taught to disable the Page-level view state and session state by setting the EnableViewState and EnableSessionState properties to false when not explicitly necessary. By turning off view state (when not needed), we can greatly reduce the total amount of overhead and content downloaded by a client. You can also disable session state and/or view state in the Web.config file, if you know that your entire application will not need session state or view state information.

In the mobile world, view state and session state are invaluable tools a developer needs to display content. For example, view state and session state work in tandem to provide the important pagination features. That is, in developing desktop-based Web applications, view state and session state are available for providing extra functionality outside the scope of displaying information. View state is useful for remembering state changes across postbacks; session state is one way to share user-specific data across the Web application. For mobile-based applications, session state and view state play a more important role, as they are commonly used in the actual display of data.

Paginating "Large" Amounts of Data
To enable pagination for large amounts of data, you'll need to enable pagination in your mobile application. To accomplish this, set the Boolean Paginate property of the server-side <form> tag to "true". This tells the mobile page framework to determine, on its own, the best manner in which to fragment your content across post backs. When paginating content, a mobile form will display as much content as possible within a single form, and then automatically include navigation links at the bottom of the page, allowing a user to move back or forward within the form's content. The default text for said navigation links is "Next" and "Previous", but it may be modified at design-time by altering the values of the Form.PagerStyle.NextPageText and Form.PagerStyle.PreviousPageText properties.

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 Forms
Any 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 sure to read: Caching with ASP.NET.)

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;OtherParameters" %>

Handling Errors Due to Expired View State
Another 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. These and many other situations will inevitably come into play, and any of them would 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 doesn't 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 implementation, as doing so 
    // throws an error of type "System.Exception"
    // this.Response.Redirect("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 <system.web> 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 isn't 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.SessionID variable is included within the URL of the page being browsed, by setting the cookieLess attribute of the sessionState node to "true"), you'll want to set useFullyQualifiedRedirectUrl to "true" to allow for proper redirects without wrecking your session data.

The following is the Web.config template I use in my mobile-based application's:

        <sessionState mode="InProc" cookieless="true" timeout="20"/>
        <mobileControls sessionStateHistorySize="45"/>
        <customErrors mode="Off"/>
        <compilation defaultLanguage="C#" debug="false"/>
        <trace enabled="false"/>
        <globalization culture="en-US" uiCulture="en-US" responseEncoding="utf-8" requestEncoding="utf-8" fileEncoding="utf-8"/>
        <pages enableSessionState="true" enableViewState="true" autoEventWireup="true"/>
        <httpRuntime useFullyQualifiedRedirectUrl="true"/>


In 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 other scenarios where you find yourself sending massive amounts of markup to the mobile client.

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.

分享15款为jQuery Mobile定制的插件

jQuery Mobile 1.0 已经发布了, 做为jQuery的移动设备类库, 并且依靠着jQuery这个及其受欢迎的类库,必将带给大家不一样的使用体验,基于jQuery Mobile的插件开发必...
  • u013981738
  • u013981738
  • 2015年02月05日 11:51
  • 174


插件信息 官网:http://blog.ajaxmasters.com/jquery-pagination-plugin/ Demo:http://tutorials.ajaxmasters.co...
  • chinet_bridge
  • chinet_bridge
  • 2013年10月20日 09:15
  • 3108

使用 jQuery Mobile 及 ASP.NET 开发跨行动装置网站 (Mobile Web)

转:http://msdn.microsoft.com/zh-tw/hh875190.aspx 在行動式裝置普及化的現在,要開發一個能夠跨行動式裝置的原生應用程式 (Native A...
  • xd43100678
  • xd43100678
  • 2014年01月21日 09:58
  • 5601

ASP.NET MVC 4 Mobile 介绍

 这篇文章我们将介绍 ASP.NET MVC 的移动特性。 你需要先 安装 ASP.NET MVC 4 现在开始。 Step 1: 创建 ASP.NET MVC 4 Web 应用项目...
  • Andrewniu
  • Andrewniu
  • 2016年12月27日 10:21
  • 695

HTML5, jQuery Mobile 和 ASP.NET MVC 4——在模型和控制器之间使用ViewModel

在企业应用开发场景,我们也许需要聚集一些模型/数据来源并将其呈现为一个整体控制器。简单起见,我们拿个需要输入新学生姓名、年级、州(如图一)的例子来说。 年级为A、B和C,但如果我们能够让这些年级显示...
  • bighead1026
  • bighead1026
  • 2013年11月14日 09:24
  • 3176

论文记录_MobileNets Efficient Convolutional Neural Networks for Mobile Vision Application

本文个人博客地址:点击查看 Tensorflow 中的实现:点击查看 Caffe 中的实现:点击查看 1、概述 Google在2017年提出的适用于手机端的神经网络模型 主要使用了深度可分离卷积Dep...
  • u013082989
  • u013082989
  • 2017年09月13日 19:49
  • 345

论文阅读-《BlitzNet: A Real-Time Deep Network for Scene Understanding》

ICCV 20171.Motivation:为了做到实时的目标检测和语义分割 2.Framework 采用的是Resnet50+SSD, ssd这种one-stage的检测器天生适合和分割一块做。...
  • yaoqi_isee
  • yaoqi_isee
  • 2017年08月15日 15:52
  • 1456

ASP.NET MVC4桌面与移动视图(MVC4显示模式)

I. MVC4显示模式简介 MVC 4引进了显示模式功能,这个功能可以简单的为不同设备显示不同的视图。 换名话说,假设我们网页的内容是为桌面版的浏览器设计的,但是在移动浏览器或其它设备浏览器中没有...
  • dc8899
  • dc8899
  • 2014年03月01日 23:51
  • 2000

ASP.NET MVC 4 移动特性

此教程将讨论ASP.NET MVC 4 Web应用程序里的移动特性。对于此教程,可以使用 Visual Studio Express 2012 或者 Visual Web Developer 20...
  • ojlovecd
  • ojlovecd
  • 2012年11月08日 22:23
  • 13362

Mobile Commerce Applications

版权声明:原创作品,允许转载,转载时请务必以超链接形式标明文章原始出版、作者信息和本声明。否则将追究法律责任。http://blog.csdn.net/topmvp - topmvpMobile Co...
  • topmvp
  • topmvp
  • 2008年08月24日 18:11
  • 222
您举报文章: Understanding Pagination in ASP.NET 1.x Mobile Applications