Dave Burke - Smart Client Disconnected Data Requirements

Smart Client Disconnected Data Requirements

There are many Powerpoint bullet lists providing the characteristics of Disconnected Data in a Smart Client Application, but when the rubber is on the pavement and you're building the app, there are real world issues that you have to deal with. Each app is different, but here's my list from laying the groundwork this past week using ADO.NET DataSets and the IssueVision model.

When the app loads, it has to be instant. A web service call cannot prevent the app from displaying instantly on the screen.
An initial data synchronization has to occur (post app startup) and while connected, ongoing synchronizations must take place on a set frequency: 30 seconds, 1 minute, 5 minutes, etc. This brings up a challenging issue: How do we synchronize the client data with the server data (has to be with some timestamping, right?) and how do we handle, say, a client machine time that is different from the server?
The Client App must be able to work disconnected. All data (sufficient to perform most operations) must reside on the client. The user must be able to update data while disconnected with a Send/Receive function. On Send/Receive AND in background synchronization process, all new and updated client data is synchronized with the server data and all data changes on the server are downloaded to the client.
If the user closes the app with changes pending, those changes must be preserved for synchronization when the app is next used and in a connected state or when the user clicks Send/Receive.
UI cues must be provided for all Send/Receive processes, to denote pending changes, and to display connected status. A Send/Receive button should be disabled when working online, for instance. Change pending icons should appear with any items not synchronized with the server, status bar text should accurately display the connected status of the application, etc.
How do we handle data conflicts?

Comments (5) | Post RSS RSS comment feed

Posted on 6/25/2005 1:21:00 PM by Dave Burke
Categories: .NET
Tags:

6/28/2005 10:43:47 PM Permalink

HI Dave,
You'll want to check out SQL Mobile.  This is the latest version of the SQL CE database engine.  In this release it now runs on Tablet PC as well as devices.  The main benefits are:
Runtime engine is < 1.4mb for everything, including both replication engines
Can be clickonce deployed without any admin rights
Includes an updateable resultset, SqlCeResultSet
Includes two forms of replication.  Remote Data Access (RDA) as well SQL Merge Replication
DataSets are an enticing easy entry point, but they're really not a data store.  You'll quickly hit the limitations of using DataSet for anything more then a small cache and a messaging mechanism to pass data between tiers.
I’ll be posting more info about SQL Mobile, as well as some of the new features we’ve added to SQL Express (previously MSDE)

Enjoy
Steve Lasker
Program Manager
Visual Studio – Smart Client Data
Blogs.msdn.com/SmartClientData

Steve Lasker |

6/29/2005 9:56:18 AM Permalink

Good to know. I've not considered SQL Mobile at all. I'll stay tuned to your feed for more. Thanks for your input!

daveburke |

6/29/2005 11:28:11 PM Permalink

With regard to SQL Mobile:

I can see how it would be a solution in some way. You don't have to cache large amounts of data in in-memory DataSets, instead storing them on non-volatile media.

However, the downside would be that the data-access logic (and server-side validation, if that's the way you're going) has to be tied up in the client application. In the project I'm working on, I was hoping to have data access limited to the server (web services) and have the client only know about ADO.NET DataSets. If we went with SQL Mobile, the client would need all the SQL logic as well.

What's the answer? Perhaps the data-access logic (converting SQL calls to DataSets and back again using SqlDataAdapters) could be moved into its own assembly, one that's shared by the web-services and the mobile client?

mabster |

7/11/2005 2:12:15 AM Permalink

Another question, Dave, and I hope you'll blog about this one.

How do you handle validation errors raised by the server? Say you have set RowError in the RowUpdating event of your DataAdapter.

My problem right now is this:

1. User adds a new row (pops up a dialog to enter the details of the new row)

2. User hits OK - some client-side validation occurs, and passes

3. Row is added to the local DataTable, and the DataSet's changes are passed to the server to be applied to the database

4. The server hits a problem in its validation in RowUpdating, and passes the dataset back to the client with RowError set

5. The user is notified of the error, and their dialog is not closed. They decide, though, not to worry about adding the row after all, and hit Cancel.

By the time they've hit cancel, I've already added the row to my client-side DataSet. I've tried calling RejectChanges with limited success - I still seem to have a 'phantom' row, validated only at the client-side, sitting in my table.

I realise that I could re-tool the UI so that the changes aren't applied when the user hits OK, and instead provide a "Save" button back in the parent window ... but I don't think my users will accept that.

How are you going about it? Enquiring minds etc etc

7/11/2005 7:41:46 AM Permalink

Mabsterama Dude,  You very expertly described an synchronization specification requirement.  This is a very lame response, considering how well you defined the situation, but conflicts are something I'm not worrying about until later in the cycle (2-3 months?) at which point I'll be a clientside synchronization machine and make a smarter decision about what to do.

It will be fun at that point to work through the details you describe, where at this point it is premature to attack those concerns.  IssueVision has a good example for handling conflicts if you want to take a look at that.

In my initial thinking, I know there are certain functions that must occur while online, or in real-time.  Say, if someone wants to add a certain type of data which would cause nasty potential conflicts and are in an offline state, they would receive a messagebox("You must be connected to do this, fool"), which would occur only rarely, since 90% of the time the app will be used in a connected state.  Those potential conflict actions will thus be handled in real-time via a webservice where the process of adding data will occur like any web app with minimal conflict.

Hope that helps.  I'll be blogging on how I handle it--when I handle it.

Regards!

Dave Burke : Freelance .NET Web Developer specializing in Online Communities

Smart Client Disconnected Data Requirements

Related posts

Comments (5) -