Best practice - C# Layout in code behind

ThreezoolThreezool USMember ✭✭
edited October 2016 in Xamarin.Forms

Hi every one!

I have a few questions how you guys implement C# Layouts in the code behind and what you think is the best practice here. At the moment i have a MVVM structure but what i get stuck at is how to handle the layout part. Should all of it be put in the code behind file or should i separate the layout generating code in to a separate layer that gets called by the code behind?

By separating it in to its own layer i get a better overview of the code but at the same time placing it in the code behind makes sense due to its connection to the page its representing.

So how do you guys do it and do you have any recommendations?

Thanks in advance! =)

Best Answer

Answers

  • ClintStLaurentClintStLaurent USUniversity ✭✭✭✭✭

    Ideally your layout is all XAML - nothing in code behind.
    Realistically on small things that are often reusable controls you'll see some code behind.
    But never should the actual view model know anything about the View.

    So... If you're making a small component of an image, button, label and background - lets say. Because you're going to use that 10 times over on a page. Your control might have a little code behind that know about the UI because all of its is about UI.

    The the page that uses those 10 copies of the control might bind to properties that were defined in that code behind - binding the control's properties to properties in the ViewModel the page is use.

  • ThreezoolThreezool USMember ✭✭

    @ClintStLaurent said:
    Ideally your layout is all XAML - nothing in code behind.
    Realistically on small things that are often reusable controls you'll see some code behind.
    But never should the actual view model know anything about the View.

    So... If you're making a small component of an image, button, label and background - lets say. Because you're going to use that 10 times over on a page. Your control might have a little code behind that know about the UI because all of its is about UI.

    The the page that uses those 10 copies of the control might bind to properties that were defined in that code behind - binding the control's properties to properties in the ViewModel the page is use.

    Thanks for the answer!

    Actually i don't really like XAML so I'm going for a code only approach to pages and views and by that only using the C# objects of the XAML elements. So that is why I'm a bit puzzled where to place the code.

    Code behind might have been the wrong term here since that is coupled to XAML views. I'm using pure C# classes as a page and fill it with the needed C# objects representing the different XAML elements. So code behind is actually the c# class page i use to generate a page in this case.

    Sorry for being a bit off in my explanation, were a late night. =)

  • ClintStLaurentClintStLaurent USUniversity ✭✭✭✭✭

    Actually i don't really like XAML so I'm going for a code only approach to pages and views
    I'm using pure C# classes as a page and fill it with the needed C# objects representing the different XAML elements.

    That's your call and its syntactically legitimate. But just to let you know, its not an approach that's going to be looked upon favorably by employers. If you're just dinking around at home for a hobby do whatever you like. If you're hoping to be employed doing this one day then the best (but blunt) advice would be "suck it up and get over it". XAML/C# has been around about a decade with WPF, Employers expect it done by the standards. Not to mention splitting UI to XAML and logic to C# is for a reason: They can hand off the XAML to the graphic artists while developers work on the C# AT THE SAME TIME.

  • FriedSlothFriedSloth DEMember ✭✭

    Ideally your layout is all XAML - nothing in code behind.

    Uh what?
    That depends on your style, if you like XAML or prefere to write your layout in c# code.

    I for example dont use XAML, i dont like Xamarin Xaml. You can just create a new c# class and let it derive from ContentPage or what ever. Set your ViewModel with BindingContext = viewModel like you do with a normal code behind.

  • ThreezoolThreezool USMember ✭✭

    @FriedSloth said:

    Ideally your layout is all XAML - nothing in code behind.

    Uh what?
    That depends on your style, if you like XAML or prefere to write your layout in c# code.

    I for example dont use XAML, i dont like Xamarin Xaml. You can just create a new c# class and let it derive from ContentPage or what ever. Set your ViewModel with BindingContext = viewModel like you do with a normal code behind.

    This is exactly my aproach to and the question is to use the class that derives from a page class in Xamarin and use it as "code behind" and seperate the UI elements in a seperate "UI generator class" or to keep that code in the page class.

    What is the best aproach for maintainability and structure.

  • ThreezoolThreezool USMember ✭✭

    @ThomasBurkhart said:
    Not really clear what you mean be "UI generator class". If you write a view in code then you have one class for each page that builds up the Page`s elements. What indeed makes sense is to put more complex elements into a seperate ContentenView derived class and use that in the Page classes.

    I'm thinking in line of placing the view elements in a seperate class and then just call that class from the page class. Then in the page class populate it with the data from the ViewModel. But that might also make it more complex and some times harder to seperate due to how some view elements are generated.

    That is why i thought if there is a "best practice" to handle this. =)

Sign In or Register to comment.