Make Page Events available to View Model

[carlo-tatoy]

Summary

Make page events like OnAppearing and other overridable events on page available to View Model. This will make the MVVM more powerful in accessing the View. The main purpose of view must be for design only, the other things like OnAppearing event must be available to handle on ViewModel since it might have some logical functions. It will make also the coding more cleaner i guess.

API Changes

I’m not the type of super coder so i don’t know what api must be modified regarding to my concern.

It might be something like this

public class ViewModel : PageName
{
  override OnAppearing()
  {
    //Do something
  }
}

Intended Use Case

It can be used on some function needs to be loaded on the moment that page appears.

Anyways, sorry for my bad interpretion. I just want to suggest something that might be useful for every coder like me.

Be safe always guys.

Thanks

[jsuarezruiz]

@carlo-tatoy Could you take a look to this other issue #120?
I think the idea is similar. Perhaps we could group and concentrate the feedback and ideas in one of them.

[carlo-tatoy]

@carlo-tatoy Could you take a look to this other issue #120?

I think the idea is similar. Perhaps we could group and concentrate the feedback and ideas in one of them.

Oh sorry, i probably missed out that. I just created this request for feature because i encoutered that.

[VladislavAntonyuk]

It will break separation of concerns. Now you can change UI while the view model remains the same. If you really need it, you should add method let’s name it InitializeVM in your ViewModel and call it from Code behind, when your event (OnAppearing) occurs

[carlo-tatoy]

It will break separation of concerns. Now you can change UI while the view model remains the same. If you really need it, you should add method let’s name it InitializeVM in your ViewModel and call it from Code behind, when your event (OnAppearing) occurs

This is what i am actually doing right now. I am just curious if it’s possible in someway. What i am doing right now is write some functions in my VM then call it to my codebehind.

[VladislavAntonyuk]

It will break separation of concerns. Now you can change UI while the view model remains the same. If you really need it, you should add method let’s name it InitializeVM in your ViewModel and call it from Code behind, when your event (OnAppearing) occurs

This is what i am actually doing right now. I am just curious if it’s possible in someway. What i am doing right now is write some functions in my VM then call it to my codebehind.

#120 (comment)

[dhindrik]

I am not sure I think this will be part of MAUI. You can use a third library for that. You can for do it with TInyMvvm right now, https://github.com/TinyStuff/TinyMvvm

The reason I think that is that people like to work with MVVM in very different ways and it hard to get all happy with adding features like that in "Maui.Core".

[PureWeen]

This is something I'm looking into with shell improvements

xamarin/Xamarin.Forms#5166

the plan with Shell is to introduce a bunch of interfaces that represent these events. I'm thinking of extending these interfaces so if they are applied to the BindableContext that they will fire there as well.

[carlo-tatoy]

I am not sure I think this will be part of MAUI. You can use a third library for that. You can for do it with TInyMvvm right now, https://github.com/TinyStuff/TinyMvvm

The reason I think that is that people like to work with MVVM in very different ways and it hard to get all happy with adding features like that in "Maui.Core".

Due to some requirements. Some people might need to do the same thing i said above and some people might dont like it because it will break some sense of MVVM.

[J-Swift]

I can see both sides on this. I agree it violates separation of concerns, but in practice you need to be lifecycle-aware when developing on the platforms that are being targeted. Handling lifecycles in user code becomes boilerplate (and buggy boilerplate a lot of times since I haven't found a solution that successfully unifies the platforms idea of 'lifecycle' yet). Moving this to the framework helps by

1. Reducing all that repetition of mapping events to 'init'/'pause' methods on the VMs
2. Reduces cognitive load on devs who all have to solve the same problem of unifying lifecycles over and over for every project