Hi,
I am studying Xamarin.Forms. I don't know very well MVVM and I have some question about it.
I want to create a connexion form (login/password) and to manage this connexion by sending connexion informations to a RPC, RPC that will report if the connexion is accepted (1) or refused (0). How to organize my Xamarin.Forms project to respect MVVM?
This is how I work now:
The connexion works... but I don't use any "ViewModel".
My questions:
I found it normal that this is the "User" class that owns the "CheckConnexion()" method. But should I move this method in a class of a "ViewModels/" folder (the class can be named "ConnexionViewModel" for example) ?
If yes, what property should I create in my "ConnexionViewModel" class? Nothing at all since I will simply use the "CheckConnexion()" method? Or simply a field (an "int") indicating if the connection worked without problems (1 for OK, 0 for not OK)?
Thank you in advance for your advice.
Posts
You can see my post on another topic. There is an activityIndicator example but you can use it for your purposes
Thank you. This video is perfect. Very interesting
Another tutorial series that also covers some MVVM
http://redpillxamarin.com/2018/03/12/2018-101-vs2017-new-solution/
Being new to Xamarin but very familiar with MVVM I was not very comfortable with the notion of mixing ContentPages and ContentViews in my "Views" folder. I ended up separating ContentPages out into a Pages folder and these pages were just dumb containers for their corresponding views. For instance I have a HomePage.xaml and the only thing that it does is pull in a HomeView.xaml from the Views folder.
Separating by type is common in school and other small projects. But for bigger projects I like to go by 'feature'. Seperating by type (ViewModel, Model, View) is kind of like filing on your PC as "Word Documents", "Excel Documents", "Text Files" etc. You file by purpose "December bills", "Kids Medical" and so on regardless of document type. I do the same thing in my solutions.
Having the Views, Controls and ViewModels that are specific to a feature in the same folder. Odds are you're going to work them all together anyway so why go around to 3-4 folders for all the related classes.
That's me. Not right-er or wrong-er than anyone else's system.
I flirted with this when trying to decide about my project structure but ultimately decided against this. I think this works very well for JS based applications where you don't get easy type navigation like you get in C# and Visual Studio. Otherwise I couldn't come up with a compelling reason that everything needed to be in feature folders. Maybe I'll change my mind when my project gets larger but you're right it's not a right wrong thing.
xx> @ClintStLaurent said:
Interesting,
That's when Prism becomes cool because you can modularise your app and just share common stuff cross modules.
The last app farmework I designed was three apps sharing multiple modules, nice way to reuse code but have a common code base.
We do the same thing by just putting the shared code in a nuget. All the apps use the same
SettingsModule
,LocalDBModule
,UploadLogsModule
and so on by just using the company nugets. Plus it forces people to use the shared features as written so they maintain compatibility with the server-side code. IE: Nobody makes tiny tweak thinking it won't hurt something else.