Client Side App Data Caching

Moved from RemoteGuiProtocols

On the rare occasion I've been allowed to replace a web app with a rich client app, I still keep (most of) the data manipulation on the server, generally using SOAP/Web services. The user-facing application is still a regular binary with a regular interface and thus has all of the control that I need to provide the user with the features that they want. I don't pull the GUI definition from the server (although I guess I could, at least up to a point... hmmm...), and I absolutely don't pull application logic from there, but all data is sourced from and acted upon there. On the other hand, stuff like re-sorting a listbox doesn't take a round-trip and I do that totally on the client. A particular benefit of using a rich client is that it becomes reasonable to store much larger data sets in your client - don't try working with 5000 element lists in JavaScript. Just parsing the JS to build the list in the first place takes a noticable amount of time. -- ChrisMellon?

Sounds like a typical mid 90s client/server app. Not that old==bad. But a 5000-element display list perhaps may need a revisit. Nobody is going to read 5000 elements. Thus, perhaps some kind of QueryByExample should be explored. However, I agree that some customers just like giant lists from spreadsheet habits or whatever.

It's exactly like a client/server app, since that's what it is. The "modern" way of sticking everything on the web sucks, because the web wasn't designed for that sort of interactivity and it really contrains what is practical to do. Note that I didn't say a 5000 element *display* list, I said a 5000 element list. In the specific case, it was a find-as-you-type list of product codes. Round-trip query per keystroke is too slow to be practical. Loading entire dataset in JavaScript is impractical. Caching dataset in a compiled client application was very practical. -- ChrisMellon?

In that case, I think I would opt for a pop-up window to help find the item using something more sophisticated than a single giant list. For example, alphabetic buttons that narrow down the choices to a given letter in the alphabet and/or QueryByExample. If it is used often, then perhaps you are right that it should be cached client-side somehow instead of loaded per lookup. Still, a singular list is often problematic beyond about 300 items from a user interface standpoint in my experience regardless of where it is stored. -- top

Subsequent arguments and misunderstanding removed for sake of clarity. Important outcomes follow:

Of course:


In the end:

Heated argument and insults deleted; feel free to restore via history, but they were mostly content-free. -- JoeOsborn

Factors in data caching include:


View edit of October 20, 2008 or FindPage with title or text search