›

Connexion form: how to use MVVM correctly?

RobertLafriteRobertLafrite Member ✭
in Xamarin.Forms

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:

  • I have a "Views/" folder in which there is a Page that describes the connexion form (in XAML and C#)
  • I have a "Models/" folder in which I created a "User" class. This "User" class contains a "Login" property and a "Password" property. This class contains too an asynchronous method named "CheckConnexion()" that returns a value telling me if the connection is OK or if there is a login/password error. This method doesn't directly perform the connection verification itself, but she use a class inside the "Services/" folder
  • I have a "Services/" folder in which there is a class that contains methods to access to RPC

The connexion works... but I don't use any "ViewModel".

My questions:

  1. 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) ?

  2. 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.

Tagged:

Posts

  • AlessandroCaliaroAlessandroCaliaro ITMember ✭✭✭✭✭
    https://channel9.msdn.com/Shows/XamarinShow/Introduction-to-MVVM
  • igorkr_10igorkr_10 Member ✭✭

    You can see my post on another topic. There is an activityIndicator example but you can use it for your purposes

  • RobertLafriteRobertLafrite Member ✭

    @AlessandroCaliaro said:
    XXXXXXXXXX (I can not post links :) )

    Thank you. This video is perfect. Very interesting :)

  • ClintStLaurentClintStLaurent USUniversity ✭✭✭✭✭

    Another tutorial series that also covers some MVVM
    http://redpillxamarin.com/2018/03/12/2018-101-vs2017-new-solution/

  • rlaskerrlasker Member ✭✭
    edited September 2018

    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.

    <ContentPage 
    xmlns="http://xamarin.com/schemas/2014/forms"
    xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml"
    x:Class="Forms.Pages.HomePage"
    xmlns:views="clr-namespace:Forms.Views"
    BackgroundColor="Black"
    Icon="navIcon.png"
    Title="Home">
    <ContentPage.Content>
        <views:HomeView />
    </ContentPage.Content>
</ContentPage>
  • ClintStLaurentClintStLaurent USUniversity ✭✭✭✭✭

    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.

    SocialMediaFeature
CameraFeature
AuthenticationFeature
HomeFeature

    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.

  • rlaskerrlasker Member ✭✭

    @ClintStLaurent said:
    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.

    SocialMediaFeature
CameraFeature
AuthenticationFeature
HomeFeature

    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.

  • NMackayNMackay GBInsider, University mod

    xx> @ClintStLaurent said:

    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.

    SocialMediaFeature
CameraFeature
AuthenticationFeature
HomeFeature

    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.

    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.

  • ClintStLaurentClintStLaurent USUniversity ✭✭✭✭✭

    @NMackay said:
    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.

Sign In or Register to comment.