[Spec] Cross-Platform LifeCycle

[jsuarezruiz]

LifeCycle

This spec currently illustrates the types of events we are looking to surface with .NET MAUI

The platform level tie ins are purposefully left blank so that we can define purpose and use cases without getting stuck inside platform paradigms. By design .NET MAUI will allow users to hook into native life cycle events without the complexities of wiring up a renderer so if users require finer platform level hooks they can break out of the xplat APIs easily and use Mapper/Handler structures to hook in.

Application (Work in Progress)

Event	Description	Use Cases
Creating	Before the native concept of the Application is created (Not sure if this is possible?).	Not sure?
Created	After the native concept of an Application is created and before any windows have been created	Register Windows or other services that are needed before a window comes into existence
Resuming	Application is Starting up or resuming from the background. This fires after created and it will also fire after coming back from the background	Wire Up services or update your application based on it coming into existence
Resumed	Currently Active window has finished activating and application is ready for interacting
Pausing	App is going into the Background
Paused	App has gone into the Background (Is this possible on all platforms?)
Stopping	App is Closing (Is this possible on non desktop platforms?)
Stopped	All Windows have been closed and everything is cleaned up (Is this Possible?)

Window

#1720

Page

• This API doesn't have Appearing/Appeared currently because those APIs are currently very inconsistent and overloaded. Appearing/Appeared will most likely be a combination of the events provided here in order to limit breaking.

• Currently these events will fire for the following scenarios

  • Tabbed Navigation
  • Push/pop Navigation

• These events will not fire during app resume/backgrounding

• Page will inherit from View so all of the events that are on View will also be part of Page

Event	Description	Use Cases
NavigatingTo	Page is going to be navigated to and fires after NavigatingFrom.
NavigatedTo	Page has been navigated to via what we currently call "NavigationPage".
NavigatingFrom	Fires before the NavigatingTo fires on the destination page.
NavigatedFrom	Fires after the NavigatedTo fires on the destination page.

View/VisualElement

Handler Life Cycle

Event	Description	Use Cases
ParentChanging	parent is about to be set on this view	This tells you that the view is about to get connected to an xplat visual tree
ParentChanged	parent has changed on this view

Parent Changing/Changed

Native helpers (WiP)

Can we create native mappers that tie into all native life cycle events? How can we provide a mapper for UIView.LayoutSubViews for example

[velocitysystems]

This is an incredibly important, albeit simple requirements for Maui to be considered a leap-ahead from Xamarin.Forms.

For example, it is difficult to use ReactiveUI's concept of view activiation/deactivation with Xamarin.Forms since the view lifecycle implementation is inconsistent. This is documented here. Also, it will be especially important for these lifecycle events to fire for child views in a collection i.e. Appearing/Disappearing fired when item scrolled in and out of view in a CollectionView.

[RLittlesII]

It is worth pointing out that this isn't specific to ReactiveUI. There was something identified, on the Xamarin Forums which links to a dead user voice.

There was a workaround identified and blogged about Xamarin Forms Page Appearing

It's been discussed on Xamarin Forums

I know that Android does not conform to Apple standards. The granularity that UIViewController provides would be ideal in terms of LifeCycle events that developers can respond to.

[velocitysystems]

I know that Android does not conform to Apple standards. The granularity that UIViewController provides would be ideal in terms of LifeCycle events that developers can respond to.

I think this is a critical requirement for Maui. While it is great to have some vanilla OnAppearing/OnDisappearing events, being able to dig down deep and latch into the native lifecycle events on each platform is essential too.

This is just off the top of my head, but could it be possible to have a native event mapper?

• Maui provides several default implementations i.e. OnAppearing maps to ViewWillAppear etc.
• Maui provides the ability to specify a custom event mapping i.e.
  MyLifecycleEvent --> iOS --> ViewDidAppear
  MyLifecycleEvent --> UWP --> Loaded

Then once you have set up the native mappings, you could simply listen to the custom lifecycle event on the IView and handle it according to your requirements. I think one of the biggest limitations of XF is being locked into a proprietary set of events, which do not necessary match the native implementation on the platforms and/or your app requirements.

[PureWeen]

The Slim Renderers will help a lot with being able to latch onto native events.

The important thing is to articulate what stages of a Maui view are useful to xplat developers based on what they want to accomplish.

Loading is important because this is the last moment you have to affect the xplat model before it's realized natively.

Events like Appeared => visible on the screen are semi useful and kind of expensive to attach to every view. iOS has nice hooks for this but on android you have to attach a GlobalLayoutListener and UWP you have to wire into the layout system. Connecting that much stuff is expensive. I'd argue that very few people actually need a literal Appeared event.

as @RLittlesII points out

The granularity that UIViewController provides would be ideal in terms of LifeCycle events that developers can respond to.

Appearing is easy because it's just the intent for a view to a appear at which point users can update whatever they want to on a view. Unloaded is useful because you know it's detached from the visual hierarchy here.

I don't think Disappearing/Disappeared quite make sense to fire based on the visual tree. For example when I push a page what events should the current page fire?

So what are the scenarios here?

MVVM frameworks care about

• setting up a view (Correct implementations of Loading/Appearing)
• knowing when a view is no longer visible (Disappearing)
• when a view is removed from the xplat visual tree and all the events should be unwired (Deleted/Removed/Destroyed?)

Animations?

• just fire your animation in appearing and we'll make sure it plays once the view is part of the native tree

What about the current life cycles are the most annoying? Is it mainly that they aren't consistent?

[PureWeen]

We should also reconcile this spec with

xamarin/Xamarin.Forms#2210
xamarin/Xamarin.Forms#8596

Also I don't think this is a .NET MAUI specific thing

We can start pulling these things like Loaded/unloaded into Forms

I think the more interesting part of this for .NET MAUI is how this all looks with slim renderers and single project.

What more can we now do with life cycles and slim renderers?

[dersia]

What about Unloading for cleanup?

[hartez]

It might be worth noting that all of these will be exposed as events and as overridable virtual methods (OnCreated, OnPaused, OnAttaching, etc.).

@PureWeen correct me if I'm wrong about this.

[angelru]

It would be nice to have events of when the navigation is completely finished, do I understand what NavigatedTo is?

[hartez]

It would be nice to have events of when the navigation is completely finished, do I understand what NavigatedTo is?

I believe that's the idea, yes.

[Clancey]

So it looks like we are missing a few things.

• Application
  • Open From URL
• Pages
  • On Appearing
  • On Disappearing

Open from URL
This is used by Auth Scenarios, or deep linking.

I see Resuming/Pausing is similar to Appearing/Disappearing but that is tied to the window state.
Navigating looks like it could be used as well, but also doesn't match the exact use-case/need for OnAppearing/Disappearing

For example. I have an app with Tabs. And one tab has a timer that runs updating the UI while it's visible. There is no way for me to toggle the update timer when the page is not in focus.

[IndexOutOfLimit]

Why NavigationPage events like PopRequested, PopToRootRequested, PushRequested, RemovePageRequested made private whereas it was public earlier and we are not able to customize page navigation now.

[PureWeen]

@IndexOutOfLimit can you create a new issue indicating how you were using those to customize? Those events were hidden behind [EditorBrowsable(EditorBrowsableState.Never)] https://github.com/xamarin/Xamarin.Forms/blob/5.0.0/Xamarin.Forms.Core/NavigationPage.cs#L372

And were only there to facilitate communication between the Renderer and the NavigationPage

The newer Navigation Handlers don't make use of any of these events.