2

Today I read about new plugin on net which Fody.PropertyChanged which is very simple and easy to use.

Currently I am using MVVMCross where we have to call RaisePropertyChange(()=>Property) again and again. Is it safe to use Fody.PropertyChanged with MVVMCross. Any One have experience of that I also watch this example of using MVVMCross and Foody.RaisePropertyChange

https://github.com/slodge/BindingTalk/blob/master/BindingTalk.Droid/ViewModels/FodySimpleViewModel.cs

Or Is there any solution in MVVMCross from which we get rid from using RaisPropertyChange() again and again

Thanks,

Best Regard

Waqas Idrees
  • 1,443
  • 2
  • 17
  • 36
  • - What you conclude with all answers, have you integrate Fody with MVVMCross ? If Yes share your experience. Fody works for all kind of properties or work only specific type of properties i.e. string only ? – Ajay Sharma Aug 29 '17 at 01:42
  • I used in one of my projects and its working good, recommended to all – Waqas Idrees Sep 18 '17 at 11:52
  • Fody works for all kind of properties or work only specific type of properties i.e. string only ? – Ajay Sharma Sep 18 '17 at 12:43

3 Answers3

5

Fody.PropertyChanged should not be any slower than manual calls to RaisePropertyChanged. What Fody.PropertyChanged effectively does is write that code for you at compile time.

So, you don't have to type all those messy RaisePropertyChanged calls, and you don't have to see them either, making your code much cleaner. But if you look at what gets compiled (using ILSpy or a similar program), you will see that they've all been automatically added for you. So, from a performance standpoint, there should be no difference, but it makes your code easier to write, easier to read, and easier to maintain.

I'm a huge fan of Fody.PropertyChanged. I've been using it for years now with MVVM Light (which I believe is similar MVVMCross), and I've never found it to be the cause of a slowdown. I definitely suggest you give it a try.

If you are using version control (which you should be), commit your project, install Fody.PropertyChanged, get rid of all those RaisePropertyChanged calls, and watch the magic happen. If you don't like it, you can always go back to your previous version.

devuxer
  • 41,681
  • 47
  • 180
  • 292
  • Thanks @devuxer. Let me check then I mark this as answer. I hope mvvmcross should not be disturbed by this. – Waqas Idrees Dec 04 '15 at 08:49
  • @devuxer : Can Fody works for all kind properties ? As I experienced it works for string properties, but when we take with ObservableCollection or MvxCommand as property , fody not calls RaisePropertyChance internally for this. We need to call it in our code manually. What you say about it ? Kindly correct me if I am wrong – Ajay Sharma Aug 29 '17 at 01:39
4

As @devuxer said, Fody.PropertyChanged won´t slow down performance. It won´t cause any more processing than the RaisePropertyChanged(() => ...) because that´s exactly what you get when compiling the app, nothing else. You can see exactly how it works in the readme file

I use Fody everywhere in my MvvmCross apps. Models, view models, etc

[ImplementPropertyChanged]
public class HomeViewModel : BaseViewModel
{
    // every property will notify changes
    public string Foo { get; set; }
}

[ImplementPropertyChanged]
public class ChatMessage
{
    public string Uid { get; set; }
    public DateTime? SentAt { get; set; }
    public string SenderConnectionId { get; set; }
    public string UserName { get; set; }
    public string Content { get; set; }
}

Note: If you add method binding to the mix, you will get rid of tons of boilerplate code. I don´t use a single Command in the whole app

xleon
  • 6,201
  • 3
  • 36
  • 52
1

You can use [DoNotNotify] attribute to exclude a property or type from having notification injected, or injects [DependsOnAttribute] property to be notified when a dependent property is set.

more info: https://github.com/Fody/PropertyChanged

Konrad Piękoś
  • 164
  • 1
  • 9