User-initiated operations in Silverlight
- must be initiated by the user via an input device like keyboard, mouse or accessibility client...
- ...within Silverlight
- have an in-built timeout
- have atomicity of transaction
- cannot be marshalled across the specific Silverlight plugin's boundaries
#1 is obvious.
#2 isn't. Silverlight will not honor user-initiated operations that start from an HTML element, have a JavaScript handler which calls into a Silverlight scriptable API or other such endpoint.
#3, the in-built timeout in a user-initiated operation exists to eliminate long running, blocking, iterative, recursive tasks within one user-initiated method call. The timeout value is sort of a magic number, chosen to be small enough to no be a pain point for most developers and their scenarios, and large enough not to compromise on its goals.
#4 indicates that you cannot combine two operations in Silverlight which both require user initation into one transaction.
#5 means that the user-initiated "bit" doesn't traverse the Silverlight plugin boundaries, via IPC calls such as local messaging or even intra-process calls via DOM bridge or Scriptable object features.
These may look like quirks but are actually "features" that exist in Silverlight as secure defaults and to provide consistency of behavior across its supported browser and platform matrix. It is important for every Silverlight designer and developer to understand these nuances.
Labels: Silverlight
6 Comments:
Nice blog, Good Article
By
Life Style, at May 22, 2009 at 1:19 PM
Thanks for this article. A couple of questions:
If a user event calls another method, does the code in that second method count as 'user initiated'. I'm not sure I understand what you're using the "bit" for - is it to pass up the stack to indicate a user-initiated event?
Will the timeout magic number be big enough to call to the server and return to the client? (eg 500 milliseconds or larger) Or will it be so small that the code must perform the user-initiated action absolutely immediately? (eg 100ms or less)
By
Andrew, at June 7, 2009 at 8:39 PM
From experimenting, I see that in SL 3 beta the timeout magic number is one second.
I would argue that is far too short, and that a value of ten seconds would be more appropriate. Ten seconds is small enough to eliminate long-running or recursive code, but large enough to not cause anguish for developers.
A commercial application I am developing needs to do several round-trips to the server within the timeout, and is going to take more than one second.
By
Anonymous, at June 10, 2009 at 8:52 PM
I wouldn't call timing out an application in 20 minutes a feature. It's rather a limitation. You wouldn't want your Excel (for instance) to stop responding after 20, would you?
I say it's plain silly that these limitation should exist inside Silverlight.
Having said that...any way of working around this and making the aplication live?
By
Bigsby, at June 16, 2009 at 8:41 AM
The timeouts are enforced to protect the interest of the application consumer. We do not want apps to tie unrelated operations together under the umbrella of user initiation. The user must always be in control.
For clarity not all operations in Silverlight require user-initiation. That is restricted to a few which we consider privileged in a certain sense. E.g. going full screen, opening file dialogs, etc. The current discussion is centered around only these operations.
By
Ashish Shetty, at July 10, 2009 at 7:14 PM
This limitation prevents us from decoupling our UI buttons from our viewmodels, e.g. by using ICommand or PRISM DelegateCommand bindings.
Essentially you are requiring the buttons to have Click event handlers in the code behind.
Do you realise that this limitation is detrimental to a decoupled architecture and consequently testability?
Do you have any plans to resolve this in SL 5?
By
Simon, at September 29, 2010 at 5:06 PM
Post a Comment | Home | Inference: my personal blog