Closed jsuarezruiz closed 3 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
.
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.
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?
ViewWillAppear
etc.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.
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?
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?
What about Unloading
for cleanup?
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.
It would be nice to have events of when the navigation is completely finished, do I understand what NavigatedTo is?
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.
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.
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.
@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.
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)
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
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
View/VisualElement
Handler Life Cycle
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