Asynchronous User Interfaces

I have been thinking about this topic over the last few days. How should you build concurrency into user interface processes. In this context concurrency is used entirely to ensure responsiveness, not due to any form of concurrent nature of the application. In other words how can we gain the required responsiveness without introducing the issues related to concurrency.

As some of the previous blogs entries on this have discussed, concurrency is difficulty, with shared data being the cause of the issues. Within the user interface only limited sharing of data between threads is only required. We need to communication progress, and completion (with success or failure etc).

While I have been thinking about this in the back of my mind, I have also been reviewing some of the material I use to teach enterprise development with .NET. In particular, User Interface Process Components, see http://msdn.microsoft.com/library/en-us/dnbda/html/AppArchCh2.asp?frame=true. I think the concept of User Interface Process Components is great. The application block, http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag/html/uipab.asp, is ok but IMO lacks some basic functionality. Mainly I would liked to have see the ability to link actions to user interface events, rather than just transitions. Transitions can then become actions, multiple actions can be performed by composition. Having this reduces the functionality of the user interface components to notifying the user interface process of certain events + managing the view. The "What happens" part of the application is controlled by the user interface process.

Given this, it would be nice to have asynchronous support built into this. Given tasks (or parts of tasks) could then be marked as asynchronous. Running these tasks is then coordinated by the UIP framework. Asynchronous tasks could be given the ability to indicate progress. The coordination of data required to do this would also be managed by the framework. Basically, by using this developers will be able to gain responsiveness, without (as many) concerns for concurrency.

I haven't spent anywhere need long enough thinking about this but I am interested in any comments you have.

---

Issues I can think of off the top of my head:

1: Interaction with the UI. If a task is asynchronous the developer must not interact with GUI elements. Doing so is asking for disaster...
2: Web application. I think this will be ok but there are some tricks that need to be done to get this to work ok.

---

Just some random thoughts on this (so I don't forget):

UIC --> UIP (User interface components are dependent on User Interface Processes)

Each UIC would have a specific functionality, for example collecting data from the user and storing it in the UIP. Therefore UIP is not dependent on UIC.

UIP needs to move to new views. UIP --> UIC... UIP <--> UIC. However page transitions are already implemented in the application block. This interdependence is already present within the block.

Moving actions into UIP ensures that it is encoded here and not in the UIC.

Do you really want one UIP for web and windows? Does the extra complexity outweigh the benefits?

---

Any thoughts on this are very welcome.