Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Enhancement] Add better life cycle events #2210

davidortinau opened this issue Mar 29, 2018 · 1 comment


4 participants
Copy link

commented Mar 29, 2018


Some lifecycle events are currently unavailable, and others are inconsistently supported across platforms Xamarin.Forms supported. To get to them today developers need to write custom page renderers in the platform projects and surface them in Xamarin.Forms. It's a pain, and we can do better!

Example or Ordering Issue

Currently, where MainPage is a TabbedPage you get this:


  1. MainPage.CurrentPageChanged event handled
  2. SchedulePage.OnDisappearing() called
  3. SettingsPage.OnAppearing() called


  1. SchedulePage.OnDisappearing() called
  2. SettingsPage.OnAppearing() called
  3. MainPage.CurrentPageChanged event handled


The comment here I think most closely indicates what we want

It's worth noting that in the iOS case I am actually suggesting that we do not use ViewWillDisappear here. I do not believe sticking to that particular callback on iOS lends any benefit but having it uniform and predictable as possible in this case is preferable.

I've defined these all on VisualElement as they will now just be symmetrical for View and Page

  • VisualElement.Appearing – The view is about to appear. This is a good time to set up update events, etc. Data updates should be enqueued here, but initial data should already be loaded.
  • VisualElement.Appeared – The view is visible on screeen, feel free to screenshot it. There is no guarantee that the view only just became visible, just that this happens after Appeared and before DIsappearing with a (strong) bias towards as close to Appearing as possible on the platform. These will most likely be tied to platform events. Just make sure to validate that once the event has fired the VisualElement has indeed appeared
  • VisualElement.Disappearing – The view has been removed from the Xamarin.Forms logical hierarchy, either by direct or indirect action by the user. The view MAY still be be visible on screen.
  • VisualElement.Disappeared – The view is no longer visible on screen.

Things to consider

  • Right now there exists a lot of code that propagates lifecycle events through pages and manually calls appearing/disappearing which is currently causing duplicated propagation c0c0077#diff-dd108d9d76d564cac973db4899b5d797R359
  • Modal and Tabs: With modal and tabs there's more of a logical concept for disappearing/disappeared because the pages aren't detached from the visual tree they just get "hidden" by the incoming view
  • The most important thing to keep in mind with these events is that they fire consistently. I would play down the importance of having these specifically tied to a platform concept. The importance of the events is to establish the current state and the intent of the state. For example if Appearing fires on android before "attach window" that's fine, Appearing is purely to indicate the intent to appear but it hasn't yet. Appeared will most likely be tied to native but there are some scenarios like dismissing a modal or switching tabs (make sure to test having more than 3 tabs) where it'll be more of a logical thing
  • Shell Parts
  • ListView and CollectionView

Expected Result

User can subscribe to additional Page and View life cycle events.

Events are consistently fired across all platforms.

Developer rejoicing is heard in the streets. 😃 🎉

Backward Compatibility


@pauldipietro pauldipietro added this to New in Triage Mar 29, 2018

@davidortinau davidortinau changed the title [Enhancement] Add better lifecycle events [Enhancement] Add better life cycle events Mar 29, 2018

@PureWeen PureWeen removed this from New in Triage Mar 29, 2018

@samhouts samhouts added this to Backlog in Enhancements Apr 13, 2018

@PureWeen PureWeen assigned PureWeen and unassigned PureWeen May 21, 2018

@samhouts samhouts added this to In Progress in vCurrent (3.6.0) Jul 5, 2018

@samhouts samhouts removed this from Backlog in Enhancements Jul 5, 2018

@samhouts samhouts added this to the 3.4.0 milestone Oct 19, 2018

@samhouts samhouts added this to In progress in Sprint 143 Oct 22, 2018

@samhouts samhouts added this to To do in Sprint 144 Oct 31, 2018

@rmarinho rmarinho moved this from To do to Blocked in Sprint 144 Nov 14, 2018

@samhouts samhouts removed this from the 3.4.0 milestone Nov 20, 2018

@samhouts samhouts added this to In Progress in vNext (4.0.0) Feb 2, 2019

@samhouts samhouts removed this from In Progress in vCurrent (3.6.0) Feb 2, 2019

@samhouts samhouts added this to In Progress in vNext+1 (master) Mar 2, 2019

@samhouts samhouts removed this from In Progress in vNext (4.0.0) Mar 2, 2019


This comment has been minimized.

Copy link

commented Mar 28, 2019

Does this also cover life cycle events for ContentView? or should I create a new Issue?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.