Question

I’m far from new at threading and asynchronous operations, but SL seems more prone to asynchronous issues, particularly ordering of operations, than most frameworks. This is most apparent at startup when you need a few things done (e.g. identity, authorization, cache warming) before others (rendering a UI usable by your audience, presenting user-specific info, etc.).

What specific solution provides the best (or at least a good) strategy for dealing with ordering of operations at startup? To provide context, assume the UI isn’t truly usable until the user’s role has been determined, and assume several WCF calls need to be made before “general use”.

My solutions so far involve selective enablement of UI controls until “ready” but this feels forced and overly sensitive to “readiness” conditions. This also increases coupling, which I’m not fond of (who is?).

Answer 1

One useful aspect of Silverlight startup to remember is that the splash xaml will continue to be displayed until the Application.RootVisual is assigned. In some situations (for example where themes are externally downloaded) it can be better to leave the assignment of the RootVisual until other outstanding async tasks have completed.

Another useful control is the BusyIndicator in the Silverlight Toolkit. Perhaps when you are ready to display some UI but haven’t got data to populate the UI you assign the RootVisual using a page that has a BusyIndicator.