Sencha touch does an admirable job of displaying data in its list component. Performance can decrease however as the number of list items increases. You can work around this by using the 'infinite' and the 'useSimpleItems' configs. Both of these configs dramatically improve performance of lists with 100s of items. I needed something slightly different however. I needed to display a list of thousands of clients and have filtering so that the user wouldn't have to scroll through tons of rows to find what they wanted. I needed the ListPaging plugin.
The first thing I did was define a stored procedure to get my data a page at a time. The client table is pretty straight-forwardThe example above uses the row_number function to number each row. As long as the same filterstring is passed in and the underlying data doesn't change, it can be called repeatedly with the same results. If you call it successively, increasing the start parameter by the limit parameter, you get a page of data at a time.
Once I had the stored procedure in place, I created an Entity Model for it in Visual Studio, but to paraphrase Alton Brown, that's another post.
With the model in place, it was a simple enough task to stand up a service that would accept requests with a filterstring, start, and limit. Sencha also passes along a page number, but we don't really need that in our example.
Great, we have all of the plumbing we need to get the data so here's where Sencha comes in. First, define a model: Then a store that uses that model: There's a lot going on in this store, but let's show the list component and the controller before describing how things work.So our clientselection component is a container that wraps a search form field (this is just a search field wrapped with a form tag) and a list component. The config to note is where we require the ListPaging plugin and configure it for autoPaging with autoPaging: true. Using the autoPaging config allows the component to continually make load requests from the store when it hits the bottom of the list.
The store itself is configured with a beforeLoad listener that dynamically creates the proxy. This allows us to include extraParams based off of the search field. What we're doing is requesting the data from the server based off of the search field. The actionMethods, reader, and writer configs are required for the WCF service as its configured. actionMethods changes the default operation to a post instead of a GET. Although it's not strictly REST, I've had clients request this approach so their logs don't contain any identifiers. reader defines the way that the data is returned from the service. Because we used WebMessageBodyStyle.Wrapped in the service, it will have a GetClientsResult wrapper around the data. The writer will post the data as JSON instead of form encoded.
The controller listens to events on the searchformfield. In this case, the keyup and clearicontap events. Both of those handlers call the filterClients method with the filterString and the list object itself. I pass the list object because the this reference doesn't point to the controller any longer when you call the filterClients method. If the filterstring is empty, we clear the filter, and reload the store starting at page 1. Otherwise, we reload the store from the server starting at page one.
The image above shows the list rendered. I had to quickly snap it, because as soon as the Load More... text is displayed, a request goes out for the next page of data and it's appended to the list.
Labels: ListPaging, Mobile, Sencha Touch