Question

I have a Silverlight Windows Phone 7 app that pulls data from a public API. I find myself doing much of the same thing over and over again:

• In the UI, set a loading message or loading progress bar in place of where the content is
• Get the content, which may be already in memory, cached in isolated file storage, or require an HTTP request
• If the content can not be acquired (no network connection, etc), display an error message
• If the content is acquired, display it in the UI
• Keep the content in main memory for subsequent queries

The content that is displayed to the user can be taken directly from a data source, such as an ObservableCollection, or it may be a query on a data source.

I would like to factor out this repetitive process into a framework where ideally only the following needs to be specified:

• Where to display the content in the UI
• The UI elements to show while loading, on failure, and on success
• The URI of the HTTP request
• How to parse the HTTP response into the data structure that will kept in memory
• The location of the file in isolated storage, if it exists
• How to parse the file contents into the data structure that will be kept in memory

It may sound like a lot, but two strings, three FrameworkElements, and two methods is less than the overhead that I currently have.

Also, this needs to work for however the data is maintained in memory, and needs to work for direct collections and queries on those collections.

My questions are:

Has something like this already been implemented?

Are my thoughts about the topic above fundamentally wrong in some way?

Here is a design I’m thinking of:

There are two components, a View and a Model.

The View is given the FrameworkElements for loading, failure, and success. It is also given a reference to the corresponding Model. The View is a UserControl that is placed somewhere in the UI.

The Model a class that is given the URI for the data, a method of how to parse the data, and optionally a filename and how to parse the file. It is responsible for retrieving the data and notifying the View whenever the current status (loading/fail/success) changes. If the data downloaded from the network is different from the cache, the network data takes precedence. When the app closes or is tombstoned, the model writes the data to the cache.

How does that sound?

Answer 1

I took some time to have a good read of your requirements and noted some thoughts to offer as a sounding board.

Firstly, for repetetive tasks with common behaviour this is definitely the way to approach it. You are not alone in thinking about this problem.

People doing a bunch of this sort of thing may have created similar abstractions however, to my knowledge none have been publicly released.

How far you go with it may depend if you intend it to be just for your own use and for those with very similar requirements or whether you want to handle more general cases and make a product that is usable by a very wide audience.

I’m going to assume the former, but that does not preclude the possibility of releasing it as an open source project that can be developed further and/or forked.

By not trying to cater for all possibilities you can make certain assumptions about the nature of the using implementation and in particular UI design choices.

I think overall your thinking in the right direction. While reading some of your high level thoughts I considered some things could be simplified (a good thing) and at the same time delivering a compeling UI.

On your initial points.

• You could just assume a performance isindeterminate progressbar is being passed in.
• Do this if it’s important to you, but you could be buying yourself into some complexity here handling different caching requirements – variance in duration or dirty handling. Perhaps sufficient to lean on the platforms inbuilt caching of urls (which some people have found gets in their way).
• Handle network connectivity, yep this is repetitive and somewhat intricate. A perfect candidate for a general solution.
• Update UI… arguably better to just return data and defer decisions regarding presentation and format of data to your individual clients.
• Content in main memory – see above on caching.

On your potential inputs.

• Where to display content – see above re data and defer presentation choices to client.
• I would go with a UI element for the progress indicator, again a performant progress bar. Regarding communication of failure I would consider implementing this in a Completed event which you publish. Then through parameters you can communicate the result and defer handling to the client to place that result in some presentation control/log/whatever. This is consistent with patterns used by the .Net Framework.
• URI – yes, this gets passed in.
• How to parse – passing in a delegate to convert a stream or string into an object whose type can be decided by the client makes sense.
• Loc of cache – you could pass this if generalising this matters, or hardcode it’s path. It would be more useful to others if passed in (consider if you handle folders/creation).

On the implementation.

• You could go with a UserControl, if it works for you to be bound by that assumption. It would be more flexible though, and arguably equally simple/elegant, to push presentation back on the client for both the data display and status messages and control hide/display of the progress bar as passed in.
• Perhaps you would go so far as to assume the status messages would always be displayed in a textblock (if passed) and shift that housekeeping from each of your clients into your generic class.
• I suspect you will benefit from not coupling the data format and presentation still.
• Tombstone handling.. I would recommend some testing on the platforms in built caching of URLs here and see if you can identify whether it’s durations/dirty conditions work for your general cases.

Hopefully this gives you some things to think about and some reassurance you’re heading down the right path. There are many ways you could go about this. Which is the best path ultimately will be driven by your goals.