Bridging the Data Divide–An Introduction to Cocoon Data Lists

When I first introduced the Cocoon framework one of the targets was to improve the ease at which data retrieval APIs (primarily web APIs) could be integrated into modern desktop applications. In this post I will introduce two concepts, the “data list” and the “data list source”, that are used in the Cocoon framework to simplify this process when writing Windows 8 Metro-style applications, in particular those implementing the MVVM design pattern.

The Data Divide

Let us first consider a typical web API that will return a list of information in response to a web request from a desktop application. In many cases there may be a large number of items in the list, so the API will split the results into several “pages”. For example, the hypothetical web call,

public Task<PersonResult> GetEmployeesAsync(int pageNumber) {...}

Might return the resulting data for pageNumber=1,

<PersonResult TotalCount="450" Page="1" PageSize="50">

    <Person Name="Bob"/>

    <Person Name="Dave"/>

    <Person Name="Amy"/>

    ...

</PersonResult>

Here, whilst there are a total of 450 items in the data set, only the first 50 are returned. If you then require any further items then additional calls must be made for the second, third, etc. pages as required.

In contrast let us consider a modern Windows 8 Metro-style UI. Here the user generally expects to see a single list of all items that can be scrolled through as desired. For performance reasons this list should take advantage of data virtualisation to retrieve data on demand, filling in the UI smoothly as the results are retrieved (see my last post on VirtualizingVector for more information).

It is this “data divide” between the state-less paged result sets of web APIs and the fluid continuous lists of desktop applications that often require much code to implement correctly. This is the problem that “data lists” and “data list sources” in the Cocoon framework are desired to solve.

“Data Lists” and “Data List Sources”

The approach taken by the Cocoon framework is to separate the two concerns of the web API calls (or any other data access call) and the resulting lists to display in the UI into separate components. These can then be developed separately using their own conventions, with the Cocoon framework bridging the divide.

In this model a web API call (or calls) that return information on a list of information is represented as part of a “data list source”. This understands how to query the source API to retrieve the list of data as required. In addition it is your application’s own representation of what it knows about the list of data – the length of the data set, and any items that have already been downloaded. This can be reused amongst different parts of your application and in some ways acts as a local cache of the data. Multiple data list sources will be available, for simple cases where all data is returned at once and for data that is returned by pages, as well as the option for custom implementations.

At the other end of the chain is the “data list”. This is the IList<T> implementation that is bound to the UI, either via the code behind or through a view model. Multiple data lists can be attached to the same data list source so that the application’s view of the data is consistent. Different data list implementations can determine how the data is retrieved for display; for example,

• StaticDataList – This will retrieve all the information before display to the user
• VirtualizingDataList – This will use data virtualization to only retrieve the data items that are currently visible to the user
• IncrementalLoadingDataList – This will initially show a fixed number of items, but allow the user to expand the list if they wish to see more items
• DynamicDataList – This will start with an empty list, with items being added as they are retrieved from the data list source

Between the data list and the data list source are a number of optional processing steps. For example these could constrain the list to only the first 50 items for preview, they could filter the items based on a search term, or could group the items to display as part of a grouped grid view.

The IDataListSource Interface

All of the above is orchestrated by the Cocoon.Data.IDataListSource<T> interface.

public interface IDataListSource<T>

{

    Task<int> GetCountAsync();

    Task<T> GetItemAsync(int index);

}

You can think of this as an asynchronous version of IList<T>, albeit a minimal version. There are two methods:

• GetCountAsync() – Returns a task that results in the number of items in the list.


• GetItemAsync(int index) – Returns a task that results in the item at the specified index.

Note that the GetItemAsync(…) method should throw an exception if ‘index’ is less than zero, however if ‘index’ is greater than the last item it should return default(T) (for reference types this will be null).

Summary

To summarize, the Cocoon framework supplies an infrastructure designed to bridge the gap between state-less web APIs and modern fluid Windows 8 Metro style applications. Over the next few blog posts (and associated code drops) I will provide a number of generic implementations of data lists and data list sources to make consuming lists of data from the web quick and easy.