NEED FEEDBACK: Offline Application Block version2

Topics: CAB & Smart Client Software Factory
Aug 31, 2004 at 6:02 AM
originally posted by: SrinathVasireddy

We (patterns& practices group @ MS) are currently working on the planning process for Offline Application Block version 2. If you have played with this block...
- Please give us details on what was easy and What specific challenges did you face when using this block?
- Did you create any work-arounds to overcome limitations of the block?
- Did you build or see real world app built using this block? Can you share the design details of that app (if you have one?)
- When you programmed against the OAB API, what was easy, what would you like to change?
- Did you create any extensions for this block?
- Anything else would you like to share…I am open for suggestions.

Thanks for your time!

Provide feedback to this thread (preferable)
Feel free to email me directly srinathv AT microsoft DOT com
Sep 10, 2004 at 7:25 AM
originally posted by: JohnAskew

1) The Caching block's bug is a major problem. I don't trust it yet, so I only use the Queue.

2) I am having a REAL problem with the "SqlParameter already exists in another SqlParameterCollection" bug from the Data Access Block's SqlHelper(?).

So far, I can't deploy the current version.
Nov 1, 2004 at 4:12 PM
originally posted by: TomWhitnerFidelity

I hope that a subsequent version of this block will be based on and consistent with your group's Enterprise Library offering. One of the most important things the PAG team can do is unify its message.

- Tom
Feb 19, 2005 at 10:37 AM
originally posted by: DSTGroup

I just started using the application block, so if I'm mistaken what is available in the existing functionality, don’t be too harsh on me. :)

1. Transparent Synchronization: From reading this board there seems to be more than a few developers that want transparent synchronization. From this I mean that the block will refresh data periodically on it own, and notify the UI thread when it updated data is available.
2. Better documentation: I’ve also noticed that many developers found the existing documentation sketchy when it comes to actual implementation. You basically have to look at the QuickStarts to have any idea how to use the block. This isn’t to bad except when you consider that many developers like myself like/have to read when they are away their work computers. I think this may be reflected in the number of users posting here, which is much less than what should be expected for such an excellent block.
3. Incremental Updates: If there is a large amount of reference data, it would be better if only the changes could be fetched and merged with the existing reference data. This keeps network bandwidth to a minimum at the very least.
4. Errors from the connection not being available: This goes back to suggestion #1. If the service drops and an update is done through the onlineproxy before the ConnectionManager’s status has changed. An error will have to caught and handled. The correct procedure would be for the app block to check the connection immediately upon an error, and if offline, leave the message in the queue until the connection resumes or at least give the developer the option of leaving it in the queue. Why should the developer handle what is obvious?

Over all, I think the block will save me some work, but will take a lot of tweaking to get it to do what I want in my app due to the incremental updates issue. Keep up the good work, and I’m looking forward to V2.
Feb 19, 2005 at 10:45 AM
originally posted by: DSTGroup

Oh, I guess I should mention that I was able to get the block to complie on .NET 2.0. There were a couple (80) changes due to most of the v1.1 configuration stuff being obsoleted. Also there is some strange bug that MSBuild (i think, I was using VS 2005) doesn't like the ExceptionHandler.Interfaces project name. I changed the length of the project name, and it then built OK.