[Spec] Cross-Platform LifeCycle

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

https://github.com/dotnet/maui/issues/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

[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.

[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.