Need Maui UI assistance/suggestions

[ejritter]

Hey all. I am new to app development and I am looking for user feedback and suggestions on my UI for the app I'm working on:
https://github.com/ejritter/WeightAndSee

Let me know what your recommendations are for backgrounds, making certain sections stand out, or certain bits of info that need to stand out for the user.

[JaimeBernar]

Hi @ejritter I have a couple suggestions to you:

1. The Models do too much, they have the info about the Weights etc, then perform some calculations and even create some Views. That is for sure too much for a class. That don't follow Single Responsibility Principle. What I would do here is, place the logic for the calculations in a real Service, Manage the creation of a View in any other possible way (Use a component with a ViewModel, a service to build the views, whatever but having that logic there).

2. Create a class with constants where you can reuse the factor between Kg and Pounds.

3. I like to have one extension class per type but this is just preference. But what you could in your Extensions class do is create a Dictionary<KiloPlates, Func> or make the switch a little bit smaller as most of the Kiloplates return Silver color.

4. The IWeightConversionService is implemented by the models? Quite weird, this is exactly where you need to do you calculations as explained in point 1.

5. Think about the registration of the ViewModels, you are registering them as Singleton, no idea if that's what you need, but some point to be careful.

Overall looks good man, the only thing that I would say is keep in mind the separation of concerns of the distint parts of the app. If you app grows it will be much easier to maintain, even if it doesn't I always find helpfull to develop my smallest projects following the cleanest pattern.

[ejritter]

Thank you so much for taking the time to review and provide feedback.
For 2.) can you clarify on how you mean reuse the factor?

For 3.) Is my Extensions.cs in the appropriate location? Would that be a "service"?

For 4.) I wasn't sure... I thought I should make a WeightConversionService class, but I thought MVVM pattern had a rule of having the Models control how they appear? (I am still new to this pattern). In doing this and moving the logic out of the models, this should resolve your point in 1.)?

For 5.) I am registering as Singleton as I understand it, it's for the lifetime of the application. Considering I am not navigating anywhere, should they not be Singleton?

[JaimeBernar]

Sure np,

For 2.) can you clarify on how you mean reuse the factor?

What I tend to do in these cases is create a class called constants with all the constants that I'll need for the app. I think I've spotted the same conversion factor twice in your code. Kg -> Lb conversion has a factor that it's constant so that class would be the best place to put it. Just to organize my code I usually put that class inside a folder called "Helpers"

For 3.) Is my Extensions.cs in the appropriate location? Would that be a "service"?

It's not a service per se, so again what I usually do is create a folder called "Extensions" in there I split the extensions classes by type. So in that folder I could have something like StringExtensions, EnumerableExtensions, EnumExtensions... and so on.

For 4.) I wasn't sure... I thought I should make a WeightConversionService class, but I thought MVVM pattern had a rule of having the Models control how they appear? (I am still new to this pattern). In doing this and moving the logic out of the models, this should resolve your point in 1.)?

ViewModels are the glue between your models and your View, but they can use things (and they should) to decouple things a little. So for example your ViewModels can use the WeightConversionService which you injected via the constructor for example (use an interface, it's easier to mock in your tests). If you want to create your View in C# I would also create a specialized service for that case, something like ViewCreatorService? There is a ton on documentation of what to do in a ViewModel and what not to do... But honestly in some cases you cannot follow 100% pure MVVM pattern as it will make your life miserable. You will get the feeling of what belongs to a ViewModel and what not when you have a little bit more experience with the pattern, don't worry. Lastly, yes, that will resolve point 1. Decouple things to make your code more testable, reusable and in the end much easier to understand which in my opinion is the most important part.

For 5.) I am registering as Singleton as I understand it, it's for the lifetime of the application. Considering I am not navigating anywhere, should they not be Singleton?

Yeah. I mean that depends on your use case, but from what you are saying sounds reasonable. I see that you have a popup, not sure if yet working, that might be the place to register the corresponding ViewModel as a Transient as you probably want a "fresh" ViewModel each time you open the popup.

Hope that helps! Do not hesitate to ping me back if you have any other doubts.

[ejritter]

okay! Thanks so much for your input.
I will put together a work plan later and attempt to refactor.

Yeah. I mean that depends on your use case, but from what you are saying sounds reasonable. I see that you have a popup, not sure if yet working, that might be the place to register the corresponding ViewModel as a Transient as you probably want a "fresh" ViewModel each time you open the popup.

Yes the popup is working. if you missed it in MauiProgram.cs I am registering my popup as a TransientPopup since that is being navigated to. I agree for the other viewmodels, I don't plan on growing this app into more than this. So I think singleton will be the way to go for the MainViewModel.