Yes, this can be used "directly" by toggling (via binding) the
IsWorking property. However, I'm looking into ways so that we can get
hold of the wait-indicator control as IIndicatorViewService from your
VM's View - this would allow you to use the indicator as
IIndicatorViewService rather than exposing an IsBusy property. I think
the token is a superior model, as it easily allows you to coordinate
one or more tasks. However, you have both the options, if you so
choose.
Lastly, the issue regarding TMI about the View is questionable, as
really the names (if used) are relegated to meta-data and your VM gets
to deal with a much more purposeful IIndicatorViewService interface.
Cheers,
Rishi
On Jan 11, 4:12 pm, Adrian Hara <
Adrian.H...@coresystems.ch> wrote:
> Looks cool, but I've one question about it. My use-case is that besides a "global" wait indicator I also need "local" indicators, for example a view could be made up of several containers each navigated to its own mini-view which loads and waits independently of the "big picture". So I guess for this case I would resolve a named indicator specific to that view, using the approach you proposed so far. While this works I don't like it a bit because the view-model would know a bit too much about the view, e.g. which named resource to get. My approach has been to just have a IsBusy property on the viewmodel and then have a waitindicator that toggles itself based on a binding to that property. Indeed for the global wait state I had a service that could be called, since the other approach doesn't work.
>
> So I guess the question is if this would be also the way to go with your proposed solution: for the global indicator use the behavior to register a service that can be called to trigger global waiting, while for local waiting just bind the IsWorking property and not use a service/behavior at all?
>
> Thanks!
>
> Freundliche Grüsse / Best regards
> Adrian Hara
> Cloud Developer
> LinkedIn<
http://www.linkedin.com/profile?viewProfile=&key=17921793&locale=en_U...>
> ________________________________
> coresystems ag
> Villa im Park | Dorfstrasse 69
> 5210 Windisch | Switzerland
>
> Phone
+41 56 500 22 22
> Fax
+41 56 444 20 50
> Infoline +41 848 088
088www.coresystems.ch<
http://www.coresystems.ch/>
www.coresuite.com<
http://www.coresuite.com/>
> follow us on twitter<
http://twitter.com/coresuite>
>
> SAP Gold Partner (SSP)
> Deutsche Telekom Audience Innovation Prize 2010
> Best of Swiss Silverlight 2010 Gold Winner
> Announced by Gartner as a Cool Vendor 2010<
http://www.gartner.com/technology/research/offer/cool-vendors.jsp>
> The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and / or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.
> From:
nro...@googlegroups.com [mailto:
nro...@googlegroups.com] On Behalf Of Rishi Oberoi
> Sent: Tuesday, January 11, 2011 1:44 PM
> To:
nro...@googlegroups.com
> Subject: [nRoute] NEW FEATURE: Wait Indicator Control
>
> One of the new controls I've added is the WaitIndicator Control - it's basically a control that can block the screen and shows a visual indicator to indicate it's working. Further, it supports two properties, one a bool IsWorking property and another a Title property to show a message. So it is nothing special, except it implements an IIndicatorViewService interface that looks like:
>
> public interface IIndicatorViewService
> {
> IDisposable RegisterIndicator();
>
> IDisposable RegisterIndicator(TimeSpan timeout);
> }
>
> What this interface allows us to do is to get a IDisposable token that would indicate that we are doing some work, and so the control would keep showing that it is working until we dispose the token. Not only that, but it also supports that multiple such tokens can be take-out at the same time, so imagine two (or more) ViewModels can take such tokens and until both of them dispose off the indicator would keep indicating it's working. And as you can see above, one of the options allows you to also specify a timeout - so in-case you don't dispose within the specified time, the control would automatically time it out for you if you specified a timeout.
>
> My idea with this control and supporting interface is to have one such control at the shell-level and so when-ever I'm doing some work I can block off the entire UI or part of UI input. And the tokens design would ensure that there is no contention between various consumers. Further, to ensure we don't start leaking memory, all issued tokens are weakly-referenced, this ensures the token subscribers don't inevitably outlive their lifetimes.
>
> Another idea with this is to ensure it is MVVM friendly, as so you really you can use it as so in your ViewModel:
>
> [ResolveConstructor]
>
> public TestViewModel(IIndicatorViewService indicatorViewService)
> {
> if (indicatorViewService == null) throw new ArgumentNullException("indicatorViewService");
>
> _indicatorViewService = indicatorViewService;
>
> _indicatorToken = _indicatorViewService.RegisterIndicator();
>
> }
> This should disconnect you from the View-specifics, and really you are just using it as any other ViewService (seehttp://
www.orktane.com/Blog/post/2009/10/23/Web-Xcel-Demo-View-Servic...). However, if you know ViewServices, it is a must that we should register it. And to enable registering a visual-tree/live instance I've create a specific behavior - it's use is something like:
>
> <nControls:WorkIndicator IsWorking="True">
>
> <i:Interaction.Behaviors>
>
> <nBehaviors:IndicatorViewServiceBehavior ViewServiceName="DefaultIndicator" IsDefault="True"/>
>
> </i:Interaction.Behaviors>
>
> </nControls:WorkIndicator>
>
> Now, you could get the instance either by a specific name or if like above it is registered as being the default instance you don't need to specify a name. Note, to get any name-specific resource in nRoute, use the ResolveResource attribute as such:
>
> [ResolveConstructor]
> public TestViewModel([ResolveResource("DefaultIndicator")]IIndicatorViewService indicatorViewService)
>
> {
> ...
> }
>
> Further, the control is fully re-templatable - so you can change its visuals entirely as you like. Though note for WP7, I've used the special dot like progress-bar like animation which has performance implications (seehttp://
www.codeproject.com/KB/showcase/WP7-Performance.aspx). Also, you could choose to implement the indicator totally differently, as you could provide your own implementation of IIndicatorService and register the same. Lastly, if you choose, you can make the waiting-indicator non-blocking by setting its background to be null and/or setting it as being not hit test visible.