worry-free-mvvm-with-xamarin-forms

[pshomov]

testing a comments based on comments on github issues

[pshomov]

common guys, it is totally safe to comment, don't make me argue with myself ;)

[oscarcalvo]

Nice refactoring Petar.

At the end, What do you think about Prism and MvvmLight, Do you have any preferences and you think is a good approach to use a MVVM framework? Xamarin Foms is bindable so I am not sure if a framework over it pay off. Thanks

[pshomov]

Hello @oscarcalvo,

First of all, congrats on being the first reader to ever comment on my blog (for whatever it is worth)! Thank you for that.

I did find Prism and MvvmLight pretty close capability wise, but then again I am not sure I went very deep into both. My personal feeling was that there was very little to be benefited from these frameworks in Xamarin Forms. Having another abstraction on top of an abstraction such as Xamarin.Forms certainly did not help. Especially true for the area of navigation. All in all I found I can get to a pretty clean way of developing with plain Xamarin Forms and a few helpers here and there (+Fody.PropertyChanged of course). I am planning on writing about unit testing Xamarin Forms app which caused some friction but with a tiny bit of abstraction got pretty smooth I think. Stay tuned ;)

[oscarcalvo]

I totally agree.

Thanks Petar

[WarBorg]

Hello,

very nice blog post, I am also playing around with different MVVM frameworks and helpers like MVVMLight, MVVMCross, Reactive UI etc, but at one point I also wanted to do a completely "pure" Xamarin project without any MVVM framework on top, but I found it very hard, especially because of the navigation system, having to send the navigation class to the view model and then having the viewmodel know about the views so it could do proper navigation. Also I found that working with just the DependencyService has its limitations. So I was wondering what would be your approach to make an app that needs navigation, dependency injection, etc and be closest to a "pure" form, or using you words, NOT "having another abstraction on top of an abstraction" :)

thank you in advance

[blocksninja]

Thanks for this interesting post. I've used the FreshMVVM framework in one of my apps last week. I can say it's really nice. It's especially developed for Xamarin.Forms, so less overhead. It has a navigation service in the pagemodel and a tiny IoC container. I've been using it together with Fody.PropertyChanged and didn't know MVVMCommand before this blog post. So I'm definitely going to check that out right now.

[pshomov]

Hello @WarBorg,

I am planning to write another post about Xamarin Forms with a complete sample of a couple of forms and unit testing the app. It is #1 in the queue ;)

[pshomov]

Hello @timbrand,

I glossed over FreshMVVM since I already had it with MVVM frameworks but I am going to revisit it again, hope it is less of a framework and more like a library so one can pick and choose what she uses from it.

[brianlagunas]

I do have to say that the problem you are solving in this post has less to do with Prism and MVVMLight, than it does with INPC in general. I think the context in which you place using Fody to solve INPC may actually cause confusion on the benefits of what Prism and MVVMLight actually provide. Issues with INPC is not a scenario that either of these frameworks tries to solve, but rather provides a simple base class so you don't have to write the boiler plate code yourself. Fody, on the other hand, specifically addresses the issues caused by using INPC, so you are really comparing apples and oranges here, which may give a negative impression on MVVMLight and Prism in general.

I suggest taking a look at a simple walkthrough of Prism to get a better idea of where it would fit in, because you would actually use Fody and Prism together, since each solve a different problem.

http://brianlagunas.com/first-look-at-the-prism-for-xamarin-forms-preview/ http://brianlagunas.com/whats-new-in-prism-for-xamarin-forms-5-7-0-pre1-release/

[pshomov]

Hi @brianlagunas,

I agree that what I am demonstrating in this post is by no means a replacement for Prism or MVVMLight and I do not think I made such a claim. I was just trying to show how to fix one annoyance with MVVM where the solutions provided by Prism and MVVMLight were not as good (my opinion). I have read both posts on your blog as well as watched more or less the whole Pluralsight course on MVVMLight and I am aware there is more to Prism then BindableBase. However I experienced unnecessary friction while experimenting with both frameworks (I have to say more so with Prism simply because I spent much more time with it then MVVMLight) mainly when trying to do unit testing. That led me to write my own (very simple but completely adequate for my needs) helpers - for example View resolution from ViewModel, wrap built-in Xamarin.Forms services - navigation service which navigates based on view models, or use small libraries - simple DI containers. As someone who is not familiar, let alone experienced with Prism, I saw little value in it in the context of Xamarin.Forms. What I did like is some of ideas and patterns behind it and for that I am thankful to you and the Prism team as well Laurent Bugnion.

I hope you understand I do not mean to be mean, I respect and admire what you are doing for the community, these are simply my experience and opinion as they stand at the time of this writing ;)

[brianlagunas]

I would be interested to hear about the friction points you ran into, especially around unit testing, since this is one of the strongest benefits to using a framework like Prism (everything remains testable). Prism also allows you to navigate based on ViewModels, and it allows you to use any DI container you wish. It just happens to use Unity by default. I would really appreciate any specific feedback so that it can be addressed and improve in the framework. I am always looking for way to improve Prism.

[pshomov]

Hi @brianlagunas,

Here are the issues that I had with Prism for Xamarin.Forms preview 1:

• Bootstrapper rather hard to test

  Since the "noramal" way the Bootstrapper works is by invoking Run which takes an Application I found it difficult to test the CreateMainPage method. Had to simulate the boot process in a test subclass of the Bootstrapper

• INavigationService uses strings

  I read around why MVVM frameworks tend to use string as a parameter when navigating instead of View/Page or ViewModel and then pick up the counterpart based on a convention and I stumbled on this blog post. This makes no sense to me and I would much rather have navigate to view models then views let alone "experiences". This way we can skip the RegisterTypeForNavigation too, since I just have a marker interface for all view models

  Another thing with the Prism navigation service is it was suggesting one could cancel the navigation which I found hard to understand, seemed like you could not navigate in the first place. Navigation back for example on iOS can be triggered by gesture and cancelling that for example would be a rather weird behaviour for the user and tricky to implement.

• BindableBase and SetProperty are cool but Fody.PropertyChanged + MVVMCommand are better ;)
• Did not find much difference between DelegateCommand and plain Xamarin.Forms Command

Here is what I liked:

• IoC container - DI helps
• IEventAggregator - pub/sub is great

Hope this helps and keep up the good work ;)

[pshomov]

I am going on a vacation and have started work on a sample of how I would like my Xamarin.Forms app to be like. I will post a link here in the comments so those interested can see what I was trying to achieve as an end-result.

All the best guys and gals!

[brianlagunas]

Thanks for the great feedback. You are right, since the bootstrapper requires the Application, it makes it difficult to test. We felt it was better than having a custom PrismApplication base class that you have to derive from instead. We may revisit this to see exactly how we can improve this experience.

Prism does allow you to navigate to ViewModels. Check this post out: http://brianlagunas.com/whats-new-in-prism-for-xamarin-forms-5-7-0-pre1-release/

Yes, Fody is great for INPC. I use it too :0)

DelegateCommand has a number of features not available in the XF Command. We have concepts such as a command being active through the use of IActiveAware. We also have CompositeCommands (think SaveAll). DelegateCommand also allows the use of async delegates. The DelegateCommand also received a new feature where is can observe one or more properties so that the CanExecuteChanged is automatically raised based on INPC notifications. It is also more useful since it can be used in a non-Xamarin.Forms app.

I would be very interested in seeing your app. Prism for Xamarin.Forms is currently in preview, so the more improvements I can make before it's RTM, the better.

Enjoy your vacation.

[pshomov]

It has taken me a while but here is the first of a couple of posts about what I think will make MVVM apps better structured - http://pshomov.github.io/compartmentalizing-logic

[pshomov]

Hey guys, here is the end-game around my shenanigans around MVVM - http://pshomov.github.io/better-mvvm-with-xamarin-forms/ and here is the sample I keep talking about - https://github.com/pshomov/reducto.sample

Hope you like what you see ;)

[DevAjaySharma]

Hello, as you mentioned that Fody not invoke Propertychanged for Command, Similarly I also experienced that Fody also not invoked raise property change event on other kind of properties like Class, Observable collection, List etc. So, It means Fody work sonly String , bool and other basic data types ?

[pshomov]

Hey @DevAjaySharma,

Not sure about that, all their examples I have seen are about strings. I am not much in UI related development these days so I will not get a chance to look into this but if you find out, please share ;)