Namespaces

Variants
Actions

Please note that as of October 24, 2014, the Nokia Developer Wiki will no longer be accepting user contributions, including new entries, edits and comments, as we begin transitioning to our new home, in the Windows Phone Development Wiki. We plan to move over the majority of the existing entries. Thanks for all your past and future contributions.

Talk:How to use MVVM Light Toolkit for Windows Phone

From Wiki
Jump to: navigation, search

Contents

Saramgsilva - Response

I added some references, and i read the article, that looks confuse

I didn´t understood want you mean with

[--hamishwillee : I'm up to here. Trying to explain how the bits all fit together starting from what gets installed to your project. It actually might be easier to start with a diagram that shows the Locator as part of the MVVM. ANyway, still working on this.]

ViewModelLocator is a static class that helps to connect ViewModel to the View and it don´t belongs to MVVM pattern.


How to use MVVM Lght is simple,

  • Create ViewModelLocator with viewModels and register each dependecy
  • Add ViewModelLocator to App.xaml
  • Create the View Model (MainViewModel - that uses RelayCommands,ObservableObject, ViewModelBase, ...)
  • Create the View (MainPage - and connect with ViewModel)

    saramgsilva (talk) 17:38, 12 November 2013 (EET)

Saramgsilva - Response

I don´t agree with MVVM Light Overview

only agree if it contains

  • A ViewModelBase class to be used as the base class for ViewModels.
  • A Messenger class (and diverse message types) to be used to communicate within the application. Recipients only receive the message types that they register for. Additionally, a target type can be specified, in which case the message will only be transmitted if the recipient's type matches the target parameter. Messages can be anything from simple values to complex objects. You can also use specialized message types, or create your own types deriving from them.
  • RelayCommand command classes to simplify passing commands from View to ViewModel.

The GalaSoft.MvvmLight.Extras library with optional classes:

  • EventToCommand behavior, allowing you to bind any event of any UI element to an ICommand, for example on the ViewModel, directly in XAML. This makes using Commands much easier, without writing code behind. With the newest version, you can even get the EventArgs of the fired event directly in the ViewModel to handle it.
  • DispatcherHelper class, a lightweight class helping you to create multithreaded applications.

    saramgsilva (talk) 17:43, 12 November 2013 (EET)

Hamishwillee - Still "under construction"

Hi Sara

I completely agree the section was confusing because it wasn't finished (the article is in Draft category).

I have now finished the #MVVM Light Overview section and I think it provides a fairly good overview of what MVVM light offers from Nuget installation and what you need to do to create the app. Note that it doesn't refer to "Add ViewModelLocator to App.xaml" as that was done for me by Nuget, and they don't need to know at this point. It also does mention ViewModelLocator - it is not part of the MVVM pattern, but it is important part of the toolkit.

Is this introduction clear/useful/can it be improved? I haven't actually tested that the Intellisense code snippets are delivered by Nuget. Do you know if they are?

My next step is to go through the rest of the article. I think some bits can probably be improved with a few links to related articles.

Regards Hamish

hamishwillee (talk) 04:57, 13 November 2013 (EET)

Hamishwillee - Some stuff for discussion

Hi Sara

OK, so I've taken this further now so you can see where I'm heading. This has all be done in one commit, so we can revert it if you think it is terrible.

So the way this has changed is that now that it is focussed on "what you do" - ie "Creating and binding to ViewModels (ViewModelLocator)" rather than classes. This allows us to have "Creating extra views" even though the example doesn't cover that. We can also talk about sending RelayMessages if we want. In addition, it now has scope to provide a little more background on the flow of operations, and more clearly identify what is part of the skeletons and what you have to do yourself.

It is not complete yet. If you hate it, then we can talk about other ways of making addressing the problem.

I have some questions that came up. For the locator skeleton the factory function for the main model is

public MainViewModel Main

And it is "Main" you declare in your XAML. My confusion is that if you're declaring Main in your XAML it looks like it will be calling the factory function all the time, and I thought that it would be getting the existing instance of MainViewModel if the viewmodel is already created. Is there some magic here?

Secondly, I haven't talked about the cleanup code. I think this needs its own section - explaining how you cleanup the views and how you clean up the Messenger. Can you write that or explain it. Ideally this should also cover your options for creating/cleanup - ie sometimes you might want to clean up early, how can you do that etc.

Thoughts on how it is evolving?

Regards

H

hamishwillee (talk) 09:03, 13 November 2013 (EET)

Saramgsilva - Response

  1. MVVM Light Overview section is now more clear, i liked.

I rarelly use code snippets from MVVM Light, but can be usefull, good idea to talk about it.

About cleanup code, i talked with Pedro, and in Windows Phone clean up don´t make sense.

The article is better now.

saramgsilva (talk) 11:52, 13 November 2013 (EET)

Hamishwillee - Great. I'm still playing with it.

Hi Sara

thanks

Can you ask Pedro "why" cleanup isn't needed? I know that people will want to know why doing cleanup doesn't make sense on WP and it does elsewhere. If you are too busy let me know and I'll send him the questions. I can also see that you're cleaning up - removing the PropertyChanged notification and resetting the messenger.

I can see the Person class is an Observable object, but what isn't clear is if this is somethign that is true of all model classes, or just this one. Also if this is the only way to create the model. Can you explain this generically, rather than just in terms of Person.

Similarly, I see that in the ViewModel you've registered the viewmodel: PropertyChanged += MainViewModel_PropertyChanged; can you explain what the "generic rules" are here - ie that the ViewModel must implement MainViewModel_PropertyChanged, how the changes in the model propagate? Again, I'm trying to find out what needs to be done "in every view model" and then relate it to what you have done here.

Does that make sense?

Regards

H

hamishwillee (talk) 13:11, 13 November 2013 (EET)

Hamishwillee - New section for you to check

HI Sara

Added #How_to_use_services. OK?

Cheers

H

hamishwillee (talk) 07:16, 14 November 2013 (EET)

Hamishwillee - OK, so what needs to be done to "really" complete this.

So in essence, to complete this we need to clarify the difference between "what you did", and what anyone implementing an MVVM Light Toolkit app would have to do - ie what is just because you chose to implement it this way, what the framework does, and what the choices are.

So

  1. We should add three more sections, with snippets and explanations
    • Commands - how they work
    • Messages - how to use them
    • Cleanup - cleaning up view, view models. When this has to be done. When not.
  2. Possibly also dynamically creating/removing views/viewmodels - can you do this, and does it make sense.

More generally, based on what we have now

  1. The ViewModelLocator provides a property that uses the service locator to return an instance of the ViewModel (either create it or return an existing one). Your prototype is "public MainViewModel MainViewModel". IS THIS normal. The default is "public MainViewModel Main" which I think is more readable. Any particular reason to name the type of the property the same as the instance?
  1. Why isn't cleanup as s important on the phone as on Windows. that doesn't make intuitive sense and needs an explanation.
  2. I’m finding it hard to understand the implementation of the MainViewModel – ie what is accidental and what is needed in any app.
    • Firstly, why is the property the same name as its type "public Person Person". That makes it confusing to read.
      private Person _person;
      and a property
      public Person Person
      {
      get
      {
      return _person;
      }
      set
      {
      Set("Person", ref _person, value);
      }
      }
      So what I think is happening is the property Person allows you to get and set the internal value of the private Person object (I find this very confusing since the property name is the same as its type!) The value of the private member is set in the constructor based on runtime/design time check.
      Is this a normal way to link to the model? Why not define an interface to the model in the ViewModelLocator as a service as is done in the template? Are there benefits of doing it this way?
    • We derive from ViewModelBase, which I believe derives from INotifyPropertyChanged. I THINK we do this so that we can get property changed events from the UI. Here we get them and do nothing. Do we do nothing here because the Person property itself is public and will get updates through the setter/getter – in other words we don’t explicitly need to set the properties? So we are only do this as an example?
              private void MainViewModel_PropertyChanged(object sender, System.ComponentModel.PropertyChangedEventArgs e)
      {
      if (e.PropertyName == "Person")
      {
      //Do something if necessary
      }
      }
    • Is there anything else that needs to be said about the viewmodel?
  1. The Model inherits from ObservableObject. Can you confirm that this is done so that properties of the object (Name, Age) can be bound in XAML. Is this a requirement of all models or just the way you have chosen to make it visible – rather than providing some sort of link in MainViewModel_PropertyChangedl? Are there any other (recommended) ways to define the model to achieve the same purpose?

    hamishwillee (talk) 06:41, 26 November 2013 (EET)

BuildNokia - Great article

Hi Sara,

This is a useful article. I agree with Hamish that it would be *more* useful if you were to address his comments, but nonetheless it's useful as-is. Is it okay if we remove Draft mode so that others can start using it and benefit from it?

Jen

BuildNokia (talk) 02:26, 13 June 2014 (EEST)

 
×