I want to know what the advantage are using the relay command to call functions that refresh the screen. In my application I have the following relay command setup.
private RelayCommand _refreshSitesCommand;
public RelayCommand RefreshSitesCommand
{
get { return _refreshSitesCommand ?? (_refreshSitesCommand = new RelayCommand(RefreshSites)); }
}
private RelayCommand _refreshProvidersCommand;
public RelayCommand RefreshProvidersCommand
{
get { return _refreshProvidersCommand ?? (_refreshProvidersCommand = new RelayCommand(RefreshProviders)); }
}
private async void RefreshSites()
{
var sitesStats = await _dataService.GetSiteStats();
if (sitesStats != null)
{
SiteStats.Clear();
foreach (var site in sitesStats)
{
SiteStats.Add(new SiteStatsViewModel(site));
}
SelectedSite = SiteStats[0];
}
}
private async void RefreshProviders()
{
var providers = await _dataService.GetProviders();
if (providers != null)
{
Providers.Clear();
foreach (var provider in providers)
{
Providers.Add(new ProviderViewModel(provider));
}
SelectedProvider = Providers[0];
}
}
Then in my code I have the following calls to execute it.
RefreshProvidersCommand.Execute(null);
RefreshSitesCommand.Execute(null);
So why is that better than just calling the RefreshSites and RefreshProviders functions. Then I would not need the code for the RelayCommand objects. Other than exposing the functionality of the 2 private functions, what benefit does using the RelayCommand object have over just making the functions public and calling them.
MVVM is in part about avoiding code-behind in the View class.
If, for example, you want an action to be taken in response to a button click, then you can either assign a Click event handler or assign the Command property to command methods. (Commands have certain advantages over Click event handlers, but that was not the question.)
There is no other good option for handling the Click event other than defining a method in the View class. You cannot directly assign the Click event to a handler method in a different class than the View and you can bind only to properties, not methods.
However, you can assign the Command property to a binding to an object that implements the ICommand interface, e.g. a RelayCommand, and that binding can be to a property of your ViewModel object. This avoids having to define Click event handlers in the view's code behind file and at the same time gives your ViewModel the ability to easily enable/disable commands without needing to know anything about the View's specific implementation.
One can argue about the merits of religiously avoiding code-behind, but that was not the question asked.
Because you can bind to a Command in your view. You can't bind to methods in your views (well you can but binding to Commands is much cleaner)
RelayCommand also implements a CanExecute method which, when binding your RelayCommand to a button, is used to automatically toggle the button's IsEnabled property based on the action you specified for the CanExecute method.
Related
How can I dispose and re-instantiate a singleton with Prism/DryIoC in Xamarin Forms?
I'm working with Azure Mobile Apps for offline data. Occasionally, I need to delete the local sqlite database and re-initialize it. Unfortunately the MobileServiceClient occasionally holds the db connection open and there's no method exposed to close it. The suggested solution (https://github.com/Azure/azure-mobile-apps-net-client/issues/379) is to dispose of MobileServiceClient. Only problem is that is registered with DryIoC as a singleton.
I'm not overly familiar with DryIoC, or Prism and Forms for that matter... But for the life of me, I can't see a way to do this.
I did cook up a pretty elaborate scheme that almost worked.
In my ViewModel method, when I needed the db freed up, I fired off an event -
_eventAggregator.GetEvent<RegisterDatabaseEvent>().Publish(false);
Then in App.xaml.cs, I wired up a listener and a handler like so -
_eventAggregator.GetEvent<RegisterDatabaseEvent>().Subscribe(OnRegisterDatabaseEventPublished);
private void OnRegisterDatabaseEventPublished()
{
Container.GetContainer().Unregister<IAppMobileClient>();
Container.GetContainer().Unregister<IMobileServiceClient>();
Container.GetContainer().Register<IMobileServiceClient, AppMobileClient>(new SingletonReuse());
Container.GetContainer().Register<IAppMobileClient, AppMobileClient>(new SingletonReuse());
_eventAggregator.GetEvent<RegisterDatabaseCompletedEvent>().Publish(register);
}
Lastly, back in the ViewModel constructor, I had a final listener that handled the event coming back from App.xaml and finished processing.
_eventAggregator.GetEvent<RegisterDatabaseCompletedEvent>().Subscribe(OnRegisterDatabaseCompletedEventPublished);
So the amazing thing is that this worked. The database was able to be deleted and all was good. But then I navigated to a different page and BOOM. DryIoC said it couldn't wire up the ViewModel for that page. I assume the unregister/register jacked up DryIoC for all injection... So how can I accomplish what needs to be done?
FINAL SOLUTION
Thanks so much to dadhi for taking the time to help. You are certainly a class act and I'm now considering using DryIoC elsewhere.
For anyone who stumbles on this, I'm posting the final solution below. I'll be as verbose as I can to avoid any confusion.
First, in my App.xaml.cs, I added a method for registering my database.
public void RegisterDatabase(IContainer container)
{
container.RegisterMany<AppMobileClient>(Reuse.Singleton,
setup: Setup.With(asResolutionCall: true),
ifAlreadyRegistered: IfAlreadyRegistered.Replace,
serviceTypeCondition: type =>
type == typeof(IMobileServiceClient) || type == typeof(IAppMobileClient));
}
I simply add a call to that method in RegisterTypes in place of registering the types in there directly.
protected override void RegisterTypes(IContainerRegistry containerRegistry)
{
containerRegistry.GetContainer().Rules.WithoutEagerCachingSingletonForFasterAccess();
...
RegisterDatabase(containerRegistry.GetContainer());
...
}
Note also the added rule for eager caching, per dadhi.
Later on when I need to release the database in the ViewModel... I kick things off by resetting my local db variable and sending an event to App.xaml.cs
_client = null;
_eventAggregator.GetEvent<RegisterDatabaseEvent>().Publish(true);
In App.xaml.cs, I have subscribed to that event and tied it to the following method.
private void OnRegisterDatabaseEventPublished()
{
RegisterDatabase(Container.GetContainer());
_eventAggregator.GetEvent<RegisterDatabaseCompletedEvent>().Publish(register);
}
Here I just call RegisterMany again, exactly the same as I do when the app starts up. No need to unregister anything. With the setup and ifAlreadyRegistered arguments (thanks, dadhi!), DryIoC allows the object to be replaced. Then I raise an event back to the VM letting it know the database has been released.
Finally, back in the ViewModel, I'm listening for the completed event. The handler for that event updates the local copy of the object like so.
_client = ((PrismApplication)App.Current).Container.Resolve<IAppMobileClient>();
And then I can work with the new object, as needed. This is key. Without setting _client to null above and resolving it again here, I actually ended up with 2 copies of the object and calls to methods were being hit 2x.
Hope that helps someone else looking to release their Azure Mobile Apps database!
I am not sure how exactly XF handles these things.
But in DryIoc in order for service to be fully deleted or replaced it need to be registered with setup: Setup.With(asResolutionCall: true). Read here for more details: https://bitbucket.org/dadhi/dryioc/wiki/UnregisterAndResolutionCache#markdown-header-unregister-and-resolution-cache
Update
Here are two options and considerations that work in pure DryIoc and may not work XF. But it probably may help with solution.
public class Foo
{
public IBar Bar { get; private set; }
public Foo(IBar bar) { Bar = bar; }
}
public interface IBar {}
public class Bar : IBar {}
public class Bar2 : IBar { }
[Test]
public void Replace_singleton_dependency_with_asResolutionCall()
{
var c = new Container(rules => rules.WithoutEagerCachingSingletonForFasterAccess());
c.Register<Foo>();
//c.Register<Foo>(Reuse.Singleton); // !!! If the consumer of replaced dependency is singleton, it won't work
// cause the consumer singleton should be replaced too
c.Register<IBar, Bar>(Reuse.Singleton,
setup: Setup.With(asResolutionCall: true)); // required
var foo = c.Resolve<Foo>();
Assert.IsInstanceOf<Bar>(foo.Bar);
c.Register<IBar, Bar2>(Reuse.Singleton,
setup: Setup.With(asResolutionCall: true), // required
ifAlreadyRegistered: IfAlreadyRegistered.Replace); // required
var foo2 = c.Resolve<Foo>();
Assert.IsInstanceOf<Bar2>(foo2.Bar);
}
[Test]
public void Replace_singleton_dependency_with_UseInstance()
{
var c = new Container();
c.Register<Foo>();
//c.Register<Foo>(Reuse.Singleton); // !!! If the consumer of replaced dependency is singleton, it won't work
// cause the consumer singleton should be replaced too
c.UseInstance<IBar>(new Bar());
var foo = c.Resolve<Foo>();
Assert.IsInstanceOf<Bar>(foo.Bar);
c.UseInstance<IBar>(new Bar2());
var foo2 = c.Resolve<Foo>();
Assert.IsInstanceOf<Bar2>(foo2.Bar);
}
I've looked at 'Messenger and references' discussion, but I'm writing a new topic, because my issue is not technical, and I don't want to offtop there.
I've encountered a doubt - Have I to code cleanup()/RequestCleanup() method implementation to unregister previously registered Messenger in my viewmodel class? I'm afraid of memory leaks in the future.
I think I've found the documentation not to be enough bright for me.
Description of Messenger.Register is: '... Registering a recipient does not create a hard reference to it, so if this recipient is deleted, no memory leak is caused.'
1) Is this mean that I don't have to take care of it and implement-develop following solutions?
On the other hand, we can find in the code of GalaSoft.MvvmLight.ViewModelBase abstract class the short info about the Cleanup() method:
//
// Summary:
// Unregisters this instance from the Messenger class.
// To cleanup additional resources, override this method, clean up and then
// call base.Cleanup().
public virtual void Cleanup();
so 2) Is only invoking a Cleanup enough to unregister class-instance out of the Messenger?
3) Or maybe I have to invoke Messenger.Default.Unregister(this); in the body of a Cleanup method?
4) In the Unregister(Object) doc we read 'Unregisters a messager recipient completely' - what does the 'completely' mean?
I'm very sorry if my post seems to have out of the context quotes, I wanted to point out what I'm more interested in.
EDIT 1:
Hello Joel, thanks for reply. I've got several questions:
1) I have used your code. There's defined override void Cleanup() in CustomerMasterViewModel. Where to call it? Should I declare destructor in this case or maybe the ViewModelBase has an automatic mechanism for invoking the Cleanup()?
2) I have in my project another base class from a different toolkit, so my VMs cannot derive from both at the same time. How to organise your code to get the same effect by implementing only ICleanup interface?
public class CustomerMasterViewModel : SomeBaseClass, ICleanup
{
public CustomerMasterViewModel()
{
Messenger.Default.Register<Message>(this, this.MessageReceived);
}
#region messages
private void MessageReceived(Message obj)
{
//do something
}
#endregion
#region helper methods
public override void Cleanup()
{
//base.Cleanup();//there's no implementaction in an interface
ViewModelLocator.Cleanup();
}
#endregion
}
You have to invoke the Cleanup() method in GalaSoft.MvvmLight.ViewModelBase on each of you view models you wan't to dispose don't need any longer.
Example:
Let say your application has a tab control with different tabs. Each of your tabs displays a UserControl which has a dedicated ViewModel. The user has the ability to close a tabs which causes the underlining ViewModel to become obsolete.
Want you want to do now is to clean up the ViewModel calling the Cleanup() method in GalaSoft.MvvmLight.ViewModelBase. This will unregister ALL registered messages. The GarbageCollector will take care of you viewmodel if there are no other references.
Assuming you use the ViewModelLocator which also comes with the MVVM Light Framework you're not done yet because at least the ViewModelLocator itself has a reference to your viewmodel! Therefore the Garbage Collector can't finalize your viewmodel.
But it also has another side effect. When the user reopens the tab (Lets say the user is able to do so) the UserControl is loaded again and the ViewModelLocator will give you the same ViewModel instance. The only difference is that there are not registered messages because you cleaned them by calling the CleanUp() method.
What you need is a new instance of your ViewModel. To achieve this you have to clean up your ViewModelLocator as well!
You have to unregister them (Unregister<CustomerMasterViewModel>()) one by one or simply call Reset() which will unregister all viewmodels.
Then there should be no other reference to you viewmodel and the GarbageCollector can finally take care about it.
Here is an example to do so:
ViewModelLocator:
public class ViewModelLocator
{
public ViewModelLocator()
{
ServiceLocator.SetLocatorProvider(() => SimpleIoc.Default);
SimpleIoc.Default.Register<CustomerMasterViewModel>();
}
public CustomerMasterViewModel CustomerMasterViewModel
{
get
{
return ServiceLocator.Current.GetInstance<CustomerMasterViewModel>();
}
}
public static void Cleanup()
{
SimpleIoc.Default.Reset();
//Don't forget to register them if the user attempts to open the new.
//The viewmodel initialization is lazy by default so this comes at no costs.
SimpleIoc.Default.Register<CustomerMasterViewModel>();
}
}
ViewModel
public class CustomerMasterViewModel : ViewModelBase
{
public CustomerMasterViewModel()
{
Messenger.Default.Register<Message>(this, this.MessageReceived);
}
#region messages
private void MessageReceived(Message obj)
{
//do something
}
#endregion
#region helper methods
public override void Cleanup()
{
base.Cleanup();
ViewModelLocator.Cleanup();
}
#endregion
}
In Short:
1) As far as i understood clean up is necessary after you're done.
2) Yes, calling the Cleanup() method in GalaSoft.MvvmLight.ViewModelBase will unregister all messages for this viewmodel.
3) No, see above.
4) Completely means it will unregister ALL registered messages.
I have a button on my AppBar to "Sync All". This call a webservice for each provider and updates their data that is has been cached. Once updated I need to update the selected providers data on the screen, so how do I do this with mvvm-light.
1) When I try to access the data in the click even of the button I am not sure how to access the currently loaded view models so I can refresh the data behind them. Is there a way to access the view model from a click event and refresh the underlying data.
2) I am wondering that is what the messenger class is used for and if so are there any good examples I can look at to use this feature in when the user clicks the "Sync All" Button.
3) If the messenger class is not the way to do this and there is no way to access the current view-model, what other options do I have.
Any help will be appreciated.
You've got two ways of doing this:
Using messenger
Using standard events
Option 1 works pretty much regardless of your design and goes something like this:
User clicks your AppBar button, which calls a command
The command calls a service that, internally calls your webservice (the nice way) or the command just calls your webservice (the not so nice way). I'm expecting this method to be an async method.
Once you've got your new data you call Messenger.Default.Send() to broadcast to all listening viewmodels that they should refresh their data.
Code:
ViewModel:
public class ViewModel
{
public ViewModel()
{
Messenger.Default.Register<DataRefreshEvent>(this,ReceiveDataRefreshEvent);
}
private void ReceiveDataRefreshEvent(DataRefreshEvent obj)
{
//do what you need to do
}
}
Service:
public class Service
{
public async void RefreshData()
{
await _webService.RefreshDataAsync();
Messenger.Default.Send(new ReceiveDataRefreshEvent());
}
}
Option 2 works like option 1 except it expects you to have a central data service wrapping your webservice. This service would be injected into all of your viewmodels.
User clicks your AppBar button, which calls a command
The command calls a service that, internally calls your webservice (the nice way) or the command just calls your webservice (the not so nice way). I'm expecting this method to be an async method.
The service raises a standard event to let the subscribed viewmodels know that they need to refresh their data. So basically same as option 1 except that each viewmodel is actives subscribing to an event on the service rather than a Messaging event.
Code:
ViewModel:
public class ViewModel
{
public ViewModel(IService service)
{
service.DataChanged+=ReceiveDataRefreshedEvent;
}
private void ReceiveDataRefreshEvent(sender obj,EventArgs args)
{
//do what you need to do
}
}
Service:
public class Service:IService
{
public event EventHandler ReceiveDataRefreshedEvent;
public async void RefreshData()
{
await _webService.RefreshDataAsync();
if(ReceiveDataRefreshedEvent!=null)
ReceiveDataRefreshedEvent(this,EventArgs.Empty);
}
}
Option 1 is nice because you don't have to hand over a reference to the service to the ViewModel. It's nicely de-coupled.
If you are unsure about messaging use option 2.
I have created a TcmExtension named WorkflowEventSystem that has an event handler subscribed to the FinishProcess event. The purpose of this event is to schedule for publish all dependencies (i.e. pages) of the associated workflow subject.
The problem I am having is that even though the event triggers at the right time (a workflow process is completed), and all the items that are supposed to be scheduled for publish are, the PublishScheduler object created by the event never seems to go out of scope, and as such the WorkflowEventSystem object does not either.
Is there something I am missing about how the Event System works that would cause these objects to live on forever? I've included what I consider the relevant code below (some parts summarized). Thanks for any help.
Here's most of the actual TcmExtension:
public class WorkflowEventSystem : TcmExtension
{
public WorkflowEventSystem()
{
this.Subscribe();
}
public void Subscribe()
{
EventSystem.Subscribe<ProcessInstance, FinishProcessEventArgs>(ScheduleForPublish, EventPhases.All);
}
}
ScheduleForPublish creates a PublishScheduler object (class I created):
private void ScheduleForPublish(ProcessInstance process, FinishProcessEventArgs e, EventPhases phase)
{
if(phase == EventPhases.TransactionCommitted)
{
PublishScheduler publishScheduler = new PublishScheduler(process);
publishScheduler.ScheduleForPublish(process);
publishScheduler = null; // worth a try
}
}
The ScheduleForPublish method looks similar to this:
public void ScheduleForPublish(ProcessInstance process)
{
using(Session session = new Session("ImpersonationUser"))
{
var publishInstruction = new PublishInstruction(session);
// Set up some publish Instructions
var publicationTargets = new List<PublicationTarget>();
// Add a PublicationTarget here by tcm id
IList<VersionedItem> itemsToPublish = new List<VersionedItem>();
// Add the items we want to publish by calling GetUsingItems(filter)
// on the workflow process' subject
//Publish the items
PublishEngine.Publish(itemsToPublish.Cast<IdentifiableObject>(), publishInstruction, publishTargets);
}
}
Life-cycle management for TcmExtension classes is quite simple:
when you call Subscribe the TcmExtension object you specify is added to an internal list of subscriptions
when you later call Unsubscribe the same TcmExtension object is removed from the list of subscriptions
Since you never call Unsubscribe your WorkflowEventSystem is never removed and thus will never be garbage collected by .NET. And since your WorkflowEventSystem holds a reference to the PublishScheduler instance it created, that one will thus also never be cleaned up.
The proper boilerplate for a custom TcmExtension is:
public class WorkflowEventSystem : TcmExtension, IDisposable
{
EventSubscription _subscription;
public WorkflowEventSystem()
{
this.Subscribe();
}
public void Subscribe()
{
_subscription = EventSystem.Subscribe<ProcessInstance,
FinishProcessEventArgs>(ScheduleForPublish, EventPhases.All);
}
public void Dispose()
{
_subscription.Unsubscribe();
}
}
Nuno also gave a longer example (handling multiple subscribers) in this article:
http://nunolinhares.blogspot.nl/2012/07/validating-content-on-save-part-1-of.html
In an AIR application, I have a private variable and a setter:
private var _saveResult
public function set saveResult( result:String ):void
{
_saveResult = result;
dispatchEvent( new resultUpdatedEvent( _saveResult ));
}
The first time that I set "saveResult" the event fires. But it will never fire again unless I restart the application.
If I change the setter to:
public function set saveResult( result:String ):void
{
_saveResult = result;
if ( result != null)
{
dispatchEvent( new resultUpdatedEvent( _saveResult ));
}
}
The problem goes away, I can set the variable many times and the event fires every time.
My question:
Am I doing something wrong here? If not, can anyone explain to me whats happening? If so, what SHOULD I be doing?
Thanks!
It looks like you're constructing your event incorrectly. The first parameter of an Event object should always be a string. So in this case you'd want to always use the same string so you could listen for the event. What does your resultUpdatedEvent class look like? You'll want it to look something like this:
package myEvents
{
import flash.events.Event;
public class PropertyChangeEvent extends Event
{
public static const PROPERTY_CHANGE:String = "propertyChange";
public var result:String = "";
// Public constructor.
public function PropertyChangeEvent (type:String,
result:String="") {
// Call the constructor of the superclass.
super(type);
// Set the new property.
this.result= result;
}
// Override the inherited clone() method.
override public function clone():Event {
return new PropertyChangeEvent(type, result);
}
}
}
That way, when you go to dispatch your event, you can construct the event as follows:
new PropertyChangeEvent(PropertyChangeEvent.PROPERTY_CHANGE, result);
That way, you're listening for the event "PropertyChangeEvent.PROPERTY_CHANGE", which never changes. The problem is now your event listener is probably listening for an event represented by the string saved in result, and obviously, this changes after the first time it's set, so there's no way to assign a listener to it.
For more information about how events work in AS3: http://livedocs.adobe.com/flex/3/html/help.html?content=events_02.html
Per the comments...
There was no event dispatcher problem.
I misdiagnosed the problem, the REAL problem was that if you have a [Bindable] property and you use a setter, and you set it for the current value, flex will ignore it. SO, you have several choices:
1) give the getter and setter different names. Seems like a "bad idea" but it does fix the problem.
2) remove [Bindable] from either the class (my problem) or the property. If the class does not implement IEventDispatcher, you will need to do so. You can simply "extends Sprite" to see it work, but that seems like a "bad idea" as a solution, so I implemented IEventDispatcher per the example at the end of this page: http://livedocs.adobe.com/flash/9.0/ActionScriptLangRefV3/flash/events/IEventDispatcher.html
3) I am sure that there is a way to get around this bug, but I don't actually NEED the class to be [Bindable] so I did not find a work around.