Forum Xamarin.Forms

Propagate Page LifeCycle Events to containing controls

ThomasBurkhartThomasBurkhart DEMember ✭✭✭✭
edited March 2017 in Xamarin.Forms

When composing a page from multiple self contained Views it's always a problem how to propagate OnAppearing / OnDisAppearing events to them.
So it would be great if Controls could have a propagatePageEvents property to select if a controls want's to get informed about this events so that it can update itself.

This would be extremely helpful for users of RxUI as then all controls could support the WhenActivated pattern

Tagged:

Open · Last Updated

Posts

  • DavidDancyDavidDancy AUMember ✭✭✭✭

    An interesting idea! There are a couple of things I'm concerned about that would need to be solved before I'd be happy to see it in Forms, but otherwise I like it.

    1. There are potentially lots of child Views of a Page that might all want to receive the various lifecycle events. I think this might have a negative impact on performance - but it would require careful testing to find out. I agree that it's a better idea to have child Views register to receive these events rather than just hooking up all children regardless. We might easily have a Page with hundreds (or more) of child Views and sending events to all of them (with most being ignored) would be wasteful.
    2. How do we sort out the timing (i.e. the sequence) of the various events being sent to the registered views? In what order are they called? Is the call sequential or asynchronous? Do we give the child Views the option to register for sequential or asynchronous calls? These aspects could be quite important if there are animations to run or other updates that depend on network resources etc.

    I'm also fairly sure that this could be achieved with current Forms by means of Behaviors. So this feature would be a shortcut that would save on having to create lots of Behaviors and attach them to controls that want lifecycle events. Or have I missed something?

  • ThomasBurkhartThomasBurkhart DEMember ✭✭✭✭

    Not sure if we can do that with behaviors. Also I would prefer to have it a property of the view.
    I agree this events should not bubble through the Hierarchie. Instead views that have set that responsible property to true would register with the page.
    Honestly I have not idea concerning the timing so far this wasn't a real issue for me. Perhaps others have a good idea.

  • VelocityVelocity NZMember ✭✭✭

    What about using Reactive extensions and Observable.FromEvent to create an observable for the necessary page events and feed to your views via dependency injection into your view models?

  • ThomasBurkhartThomasBurkhart DEMember ✭✭✭✭
    edited March 2017

    Then the Page and eventually ParentViewModels need to know about their children which makes reuse in other Projects more difficult.
    I would like to have the possibility to have completely self contained views

  • VelocityVelocity NZMember ✭✭✭

    @ThomasBurkhart said:
    Then the Page and eventually ParentViewModels need to know about their children which makes reuse in other Projects more difficult.
    I would like to have the possibility to have completely self contained views.

    That is a good point, however the solution I was proposing is the other way around. The page and parent view models do not need to know about their children, the children just have the option of subscribing to an IObservable from the page/parent VM. This makes it possible to keep the views self-contained and not referencing the page. Parent view model is then passed down the chain via DI into the child view models. Child VMs have the option to subscribe or not depending on their requirements.

    Another option would possibly be to use Messaging. Extend ContentPage etc and publish a messaging event which your child views can optionally listen to. Prism's event aggregator could work nicely for this.

  • KentBoogaartKentBoogaart AUMember ✭✭

    @Velocity your suggestions would work, but they're not framework-friendly. See my (accepted) proposal here: https://forums.xamarin.com/discussion/84510/improved-life-cycle-support. The second point discusses this very issue of not being able to tell if or when a view is on-screen or not.

    I completely agree that performance is a concern. My hope was that by subscribing to e.g. View.Appearing, this sets up a subscription to Page.Appearing behind the scenes. That way, it Just Works how you'd expect (including timing, in my opinion) and you don't pay the cost of bubbling events - only registered views incur a cost.

  • VelocityVelocity NZMember ✭✭✭

    @KentBoogaart said:
    @Velocity your suggestions would work, but they're not framework-friendly. See my (accepted) proposal here: https://forums.xamarin.com/discussion/84510/improved-life-cycle-support. The second point discusses this very issue of not being able to tell if or when a view is on-screen or not.

    I completely agree that performance is a concern. My hope was that by subscribing to e.g. View.Appearing, this sets up a subscription to Page.Appearing behind the scenes. That way, it Just Works how you'd expect (including timing, in my opinion) and you don't pay the cost of bubbling events - only registered views incur a cost.

    @KentBoogart That certainly sounds reasonable. If the page events can be propagated to the views without incurring a performance penalty, that would be ideal.

Sign In or Register to comment.