I have a Main Silverlight Project, in addition i Have a Silverlight Project for my Views and I have a Silverlight Class Library for my ViewModels.
When designing the view, I can see the ViewModel for the bindings.
In my Main Project in the App, the locator is pointing to my Class Library where the ViewModels are.
When I run my application, my ViewModel is not being instantiated.
What am I missing?
Related
I am looking for a solution/mvvm framework that supports nesting ViewModels and Views. What I mean is:
Each ViewModel derives from BaseViewModel
ViewModels have properties that are of type BaseViewModel which are sub-ViewModels (nested inside parent ViewModel)
Each ViewModel have corresponding View
Views have ContentControl (control that can display templated view) corresponding to sub-ViewModels of corresponding ViewModel
Now, when creating instance of ViewModel it is needed to pass appropriate instances of concrete sub-ViewModels. Views should be automatically resolved and nested (somehow) base on ViewModels structure.
I do not define somehow because there may be a lot of ways to do it.
I hope my idea is clear. This approach allows easy and dynamic creation of ViewModels and Views. Just create tree of ViewModels, for example in XML, and base on this create new functionality.
The questions are:
Is there any mvvm framework (mvvmcross, catel) supporting such approach for Xamarin.Forms?
How would you store tree of ViewModels - in XML, database tables, ...?
How would you create instances of ViewModels - deserialization, dependency injection, ...?
How to create Views and resolve (if framework does not support it)?
After some time I can share some experience about the questions I asked:
I do not know whether there is any mvvm framework supporting such approach. Probably Catel v5 is going to support this, but I did not checked this. I use custom solution.
In my solution I store ViewModels definitions in single database table in parent/child structure.
ViewModel instances are created by custom factories using definitions from database table.
Views are created using ValueConverters. It is possible, because each view has bindings created base on ViewModels structure.
Beside above answers I can suggest to use Prism. Although it has some disadvantages for me it is the best framework in such approach.
Yes! There's an MVVM Framework that fits exactly to what you are looking for and is created with Xamarin.Forms in mind:
FreshMvvM: https://github.com/rid00z/FreshMvvm
Quickstart Guide: http://www.michaelridland.com/xamarin/freshmvvm-quick-start-guide/
How does it compare to other options?
It's super light and super simple
It's specifically designed for Xamarin.Forms
Designed to be easy to learn and develop (great when you are not ready for RxUI)
Uses a Convention over Configuration
Features
PageModel to PageModel Navigation
Automatic wiring of BindingContext
Automatic wiring of Page events (eg. appearing)
Basic methods (with values) on PageModel (init, reverseinit)
Built in IOC Container
PageModel Constructor Injection
Basic methods available in Model, like Alert
Built in Navigation types for SimpleNavigation, Tabbed and MasterDetail
You can nest or derive ViewModels as much as you'd like (In our case we have a BaseViewModel). We have been using FreshMvvM for our startup and has been battle tested to work and fit to whatever we need.
Can someone explain What benefits an MVVM framework such as ReactiveUI or MVVM Light provides to Xamarin.Forms application? we can implement INotifyPropertyChanged in our viewmodels without using any of these frameworks.
Am I missing something?
I'm an author of a small MVVM framework for Xamarin.Forms (https://github.com/daniel-luberda/DLToolkit.PageFactory). I'll try to point some advantages of using it as some of features are common for other frameworks too:
Ready to use INotifyPropertyChanged implementation (just inherit from BaseViewModel or BaseModel)
ViewModel oriented Navigation (you can move your navigation logic to view models)
Built-in messaging to easily pass data/arguments between pages or view models
Page caching and reusing (better UI experience as views/pages are reused)
Every page has access to typed ViewModel instance which is automatically instantiated and wired to BindingContext
Those features vary between libraries. Some of more advanced MVVM frameworks offer you a possibility to move your entire project to a different platforms/sdks as they have multi platform support. It may be a nice deal for a larger projects.
Sample code to illustrate some features (the code is called from a ViewModel):
PageFactory.GetPageFromCache<SecondPageModel>()
.ResetPageModel()
.SendActionToPageModel((model) => { model.Message = "Hello World!"; })
.PushPage();
There is more to an MVVM Framework than just INotifyPropertyChanged. To give just a couple of examples there are:
RelayCommand - A class that can provides an implementation of the ICommand interface and allows you to bind a delegate to the view. Useful for buttons
EventToCommand - This allows you to bind an event to a command in your view model. Instead of having to use code behind for UIElement Events
These are just two classes that are provided by an MVVM Framework such as MVVMLight
By using MVVMLight it means that you do not have to implement INotifyPropertyChanged in every project you just make sure your ViewModel inherits from ViewModelBase and you also don't have to write your own implementation in every project for the two classes mentioned above.
The final thing to mention is that you can also install code snippets for MVVMLight. Meaning that writing code is EVEN faster!
For example if you would like a property that raises property changed as well just use the mvvmlight property snippet. And similarly if you would like a RelayCommand property you can just use the mvvmlight RelayCommand snippet
The Model-View-ViewModel (MVVM) architectural pattern was invented with XAML in mind. The pattern enforces a separation of the XAML user interface (the View) from the underlying data (the Model) through a class that serves as an intermediary between the View and the Model (the ViewModel). The View and the ViewModel are often connected through data bindings defined in the XAML file. The BindingContext for the View is usually an instance of the ViewModel. Please click here to see more details and sample code.
You don't need to use ReactiveUI or MVVM Light, you can just use INotifyPropertyChanged interface to notify clients that a property value has changed.Below, you can see my ViewModelBase class code, hope this helps you out;
public class ViewModelBase : INotifyPropertyChanged
{
#region INotifyPropertyChanged
public event PropertyChangedEventHandler PropertyChanged;
public void OnPropertyChanged([CallerMemberName] string propertyName = null)
{
if (PropertyChanged != null)
{
PropertyChanged(this, new PropertyChangedEventArgs(propertyName));
}
}
#endregion
}
In my ViewModel here is how I inherit from ViewModelBase and how I create my property;
public class ImageButtonViewModel : ViewModelBase
{
// ...
private string header;
public string Header
{
get
{
return header;
}
set
{
header = value;
OnPropertyChanged();
}
}
// ...
}
I have been using with great success with Askaiser.Mobile.Pillar, and I do not see anything wrong, I am still investigating, but this has become a great candidate for my projects.
Doc
I hope I have helped.
A greeting
The plain truth is that MVVM Frameworks (and their IOC Containers) are short-cuts to save you time. They come at an extraordinary expense:
They cause a simplistic alignment between views, view models and models. Only one can really belong to another. This is not "IOC" -- it's a hard-coded assignment based on a file naming convention such as this:
MainPage
MainViewModel
MainModel
In a real injection scenario, any number of models could serve any number of view models, provided they implement the proper interface. Also, any number of view models can serve any number of views as long as those view models support the views' interface(s).
MVVM Frameworks create classes through a reflection trick using a string prefix. In the example earlier, the string "Main" allows us to find the page, the view model and the model. But this is not view-model-to-view-model navigation. It is string to view model navigation.
The frameworks create classes using Activator.CreateInstance, which creates havoc on the compile-time linker.
The frameworks instantiate using hyper-simplistic constructor parameter logic. Modern programs use instantiation as a form of control. In these frameworks, there is no real control.
The complete code for these remarks is at https://github.com/marcusts/xamarin-forms-annoyances. See the solution called MvvmAntipattern.sln.
The GitHub site also provides links to a more detailed discussion on this topic.
Can somebody guide me what should be the design if I want to create a MVVM application in Prism(Silverlight) using MEF( I am not sure how to import or export ViewModel using MEF).
I saw few article which are binding ViewModel with View using DataContext(either in XAML or codebehind of View).
And I saw few guys who are having IView & IViewModel interface & both are having reference variable of each other.
And at some places the guidelines says ViewModel should never be referring to View.
It would be nice if somebody can provide me code snippet.
Have you read the Prism documentation? They have a section on Implementing the MVVM Pattern which discusses different techniques for wiring up the viewmodel and view.
You could also implement a composite application with an MVVM framework such as Caliburn.Micro which uses conventions for viewmodel/view binding.
I would bind the DataContext using setter injection in the code behind. Both the view and the view model are created by MEF.
[Import]
private MyViewModelClass ViewModel
{
get { return this.DataContext as MyViewModelClass; }
set { this.DataContext = value; }
}
I have a singleton Model and ViewModel objects and would like to programmatically create and attach WPF views to them, one at a time. Views can be created dynamically, say by selecting a menu item (somewhere). Newly created view would dispose of any old view looking at a ViewModel. Then it would make itself a current view of that ViewModel, displaying it in some WPF window serving as a container for view UserControl. I am using MEF for IoC. It is important that Model and ViewModel objects are created only once. What would be the way to accomplish this using MEF?
You might have a look at the ViewModel and Writer sample applications of the WPF Application Framework (WAF). They show how to switch a view using MVVM and MEF.
I use viewmodel first approach in my testapps. so i instantiate viewmodel via mef and then wpf + datatemplates do the rest. all i have to do is binding my actual viewmodel to the contentcontrol.content.
you say that its important that ViewModel objects just created once. you achieve this with mef and creationPolicy.Shared or Lazy<> import. with this in mind i think ViewModel-First is the way you should go. its straightforward and you need no extra locator or wathever :)
I'm working on a new WPF application and I'm trying to stay as close to the MVVM pattern as I can. My XAML files right now have no codebehinds, and all my interactivity is achieved using Josh Smith's RelayCommand class and commands in my ViewModel classes.
This worked great until I started working on the housekeeping tasks, such as an about box and a system preferences page. I want to have these as modal dialogs, but if I create a RelayCommand to open these pages, I'll be creating a dependency on the view within my view model.
This strikes me as against the grain of the MVVM pattern.
Is there an established method for creating new windows (modal and/or modeless) within the MVVM pattern without creating a dependency? It seems the only way I can keep the ViewModel clean is to create a Click event handler in the XAML codebehind file and create the new view within the old view.
Any recommendations?
One way to handle this is to implement a service that provides Views to ViewModels. Views register with the service and ViewModels can request dialogs from the service. This is an example of the Gang of Four mediator pattern.
Take a look at my Modal Dialogs solution for Silverlight 4:
Modal dialogs with MVVM and Silverlight 4
Please see my answer to this question about why the Window class itself is a ViewModel, so you can use it directly from your ViewModel without worries.
Laurent Bugnion has a weak-referenced mediator, in which he uses it to show dialog messages. Along with the message that is broadcast, a callback delegate is sent for the subscriber to execute. You could use the same concept to show an about dialog. Check out DialogMessage.cs from the source here.
We use Controller classes which are responsible for the UI Workflow. They create the modal windows and they mediate between various ViewModels.
How you can open a modal window with the View-Model-ViewModel (MVVM) pattern is shown in the ViewModel sample application here:
WPF Application Framework (WAF)
http://waf.codeplex.com