dotnet / maui

.NET MAUI is the .NET Multi-platform App UI, a framework for building native device applications spanning mobile, tablet, and desktop.
https://dot.net/maui
MIT License
22.21k stars 1.75k forks source link

[Spec] Cross-Platform LifeCycle #30

Closed jsuarezruiz closed 3 years ago

jsuarezruiz commented 4 years ago

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

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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?

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 commented 4 years ago

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

Animations?

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

PureWeen commented 4 years ago

We should also reconcile this spec with

https://github.com/xamarin/Xamarin.Forms/issues/2210 https://github.com/xamarin/Xamarin.Forms/issues/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 commented 4 years ago

What about Unloading for cleanup?

hartez commented 3 years ago

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 commented 3 years ago

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

hartez commented 3 years ago

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 commented 3 years ago

So it looks like we are missing a few things.

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 commented 2 years ago

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 commented 2 years ago

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