I'm using Prism to handle view navigation.
I want a view to respond to it being removed from a region myRegion.Remove(view).
What is the correct way to handle this (in the view)?
Using the Unloaded event doesn't work and neither does OnNavigatedFrom.
One way you can do this is by publishing and subscribing to a CompositePresentationEvent using the EventAggregator. Alternatively, and maybe better, is to implement IActiveAware on your views (it's part of the RegionManager I believe).
Related
In a WPF application that uses Prism, I have a shell in which there is a docking manager control.
Now I have to listen to an event coming from that docking manager, specifically, when one of its children docking state has changed.
To me, this event should be handled in code-behind as letting the view model do some work against that framework-specific visual control is worse than doing it code-behind.
Question:
Is this the right approach or am I missing something?
As long as the code is only related for the presentation then it is no problem to have it in "code-behind".
The main problem with "code-behind" is having the presentation logic split in two different locations XAML and "code-behind". There are several ways to avoid that using MarkupExtension, DependencyProperty, ValueConverter or custom (derived) controls.
I have a Command (in my viewModel) and a Clicked event (in my code behind) attached to the same view in my XAML, and I am noticing some weird results. I am doing this because I would like a view to receive focus right after the code for the command in executed:
Do the Command and the Clicked event execute synchronously or asynchronously?
Are there any adverse effects to using this approach.
Is there a better way I could handle this?
Yes, the Click events are executed asynchronously. However, I believe the commands are not. They are executed right after the associated action being performed.
My suggestion would be not to use these both together for what you are looking for. Because events will be handled whenever the thread and processor is free. So you cannot rely on it for your requirement as it depends on some other action.
You might achieve what you want by using the Behaviors in Xamarin forms. Refer below links for more details.
https://learn.microsoft.com/en-us/xamarin/xamarin-forms/app-fundamentals/behaviors/creating
A Xamarin view is a partial class - Separated by View and Code behind
View(use XAML to create front end)
Code Behind (write logic)
you can easily write an entire app using View and code behind but it's not practical in the long run.
If you want to use MVVM or MVC you will need to use Binding (separate logic from view )
to answer your question :
Commands - best when using MVVM or MVC
Click Events - Best for code-behind logic e.g. click a button
More information about MVVM design patterns
I am building an app using UWP and I have MainPage.cs which contains a Frame control where I load different child pages. I would like to pass a listener to the child page to notify my parent page about event that happen in the child. On android I would pass a callback listener which I will have to trigger in the sub-pages so I can get notified in parentl The issue here is that pages are started Frame.Navigate(typeOf(LoginPage)) for which I cannot set a callback since login page is not a referece/object but a type class.
Any help would be greatly appreciated.
It seems like the MainPage is a singleton instance. In such case you could just expose this instance by creating a static MainPage Instance property in MainPage and set it in its constructor. Then you could access MainPage directly from any other page.
The proper solution however would be to use a MVVM framework and instead of communicating between the views directly put the communication within the view models. In MVVM you usually have a sort of navigation service which allows passing parameters/return values and also you can have a event aggregator to raise messages to which other components can subscribe. Good examples of MVVM frameworks are MvvmCross, MvvmLight and Prism. It is definitely worth learning to use and integrate them early on, because it will make your life significantly easier in terms of code maintenance in the long run.
I want to create a composite wpf application with ribbon control using Prism,
and I have some thoughts about commanding:
The ribbon tab is in different view, so i guess it will have specific view model. but the command should be in another view model, because when I click on button in the ribbon, I want to do some action in the view below, so how can I bind it? should I use Event Aggregator to communicate between the view models? maybe Composite command? any other approch?
Thanks.
Because it's a different Views/ViewsModels - EventAggregator is a way to go. You use command on a View with ribbon that executes Method on RibbonViewModel which will Publish that event. Other views subscribe to that event.
If you use Ribbon as a menu - then maybe you should use PRISM's Navigation to open other views (in different region)
This is the typical scenario for composite commands
I'm using AvalonDock in a WPF application, and need to persist the layout of the AvalonDock the user has setup (moving, docking, detaching of the panels).
The function to do that are on the control itself (SaveLayout, RestoreLayout).
What is the correct way to do that ?
Right now I have a command at the mainWindowViewModel that gets created by the application when creating the instance of the window view and the viewmodel. It basically makes the relay command call an anonymous method that calls the needed function on the view control. This works since the application creates the window and the viewmodel for it.
But how would i approach this if some lower level view and viewmodel had to do this? If using this method I'd have to still create the Command at application level and sending it through the viewModels down to where it is needed to be bound to? Inside it I'd have to search the usercontrol that is a view then the avalonDock control inside it and use that at application level, which is bug prone. Somehow it seems dirty...
Thanks!
You might introduce an interface IView so that the ViewModel can call a method on the View. This way the ViewModel doesn’t need to know about the concrete View class and can still be unit tested.
How this can be accomplished is shown by the sample applications of the WPF Application Framework (WAF).
You can use decoupled messaging to communicate between view models
http://www.bradcunningham.net/2009/11/decoupled-viewmodel-messaging-part-1.html