Improved life cycle support

KentBoogaart · December 2016

Summary

As one of the authors of ReactiveUI, I have found that Xamarin.Forms does not provide the requisite view life cycle hooks to enable the framework to manage the activation and deactivation of resources in response to the comings and goings of views.

Specifically, I have found these problems:

Page.Appearing actually fires in response to ViewDidAppear on iOS. One of ReactiveUI's benefits is its code-based, type-safe binding infrastructure. Appearing is the only hook we can use to get stuff on the screen, but it fires too late on iOS, so there is a brief period where the screen is not populated with data. I have already attempted to start a discussion here, but it seemed to stagnate.
Given a View, there is no way to tell when that View appears and disappears from the screen. There is no View.Appearing or View.Disappearing events as there is for Page. It might seem appropriate to therefore search up the visual tree for the Page and hook into that. However, this is inefficient (but perhaps that's inevitable) and there is no means of knowing when the Page itself changes. There is no PageChanged event, and PropertyChanged does not fire in response to the Page changing.

API Changes

Page.Appearing should fire in response to ViewWillAppear on iOS. Moreover, there should be Page.Appeared and Page.Disappeared counterparts. Yes, this is potentially breaking to people who are hooked into Appearing and rely on it firing in response to ViewDidAppear on iOS. However, that behavior has always been incorrect and the fix for these people is literally to change Appearing to Appeared (or hold off on the XF upgrade).
Ideally, add Appearing, Appeared, Disappearing, Disappeared to View and have them Just Work. Failing that, ensure there is a hook by which framework authors can know the hosting Page for a View has changed. Perhaps a specific PageChanged event, or just ensuring PropertyChanged works as expected in this scenario.

Intended Use Case

The use case here is to give framework authors what they need to facilitate the creation of self-sufficient, standalone, encapsulated components by framework consumers. I specifically work on ReactiveUI, but other framework authors will/have run into the same issues.

ModEdit - Spec incoming ASAP

TheRealJasonSmith · December 2016

I like this. Would you be willing to create a table like so:

	Appearing	Appeared	Disappearing	Disappeared
iOS	ViewWillAppear	ViewDidAppear	ViewWillDisappear	ViewDidDisappear
Android	...	...	...	...
UWP	...	...	...	...

TheRealJasonSmith · December 2016

Also on further thought I think we would probably need to have a "Compatibility" mode for anyone updating and not wanting to port to the new behavior.

AdamP · December 2016

A default compatibility mode will be essential. I have never come across any app that doesn't depend on OnAppearing at some point. While it might not cause any issues, it has the potential to cause havoc on existing apps.

TheRealJasonSmith · December 2016

Yup, mandatory. Should probably look something like

Xamarin.Forms.Page.UseLegacyLifecycleEvents = true;

Old apps can just put that in their App.cs to restore the legacy behavior.

AdrianKnight · December 2016

Hope you make this a priority because I need to start a new app and I want to do Xamarin.Forms.Page.UseLegacyLifecycleEvents = false;

Having said that, I'm not sure if Android or UWP event cycles are 100% translatable to iOS. Not sure what kind of issues this could create for people.

TheRealJasonSmith · December 2016

We really need to make sure we have a good idea of what all the old/new events should be. I think we wrote a spec on this like a year ago but I am afraid we lost the data in the migration to microsoft services...

AdamP · December 2016

This is the best I have. Not everything is 100% translatable. Will require tapping into events on other objects to probably detect an about to disappear. From the Android documentation, OnDetachedToWindow states it no longer has a surface to draw on at the point of OnDetachedToWindow, hence I assume its already gone at this point. The OnGlobalLayout is apparently the only point at which we can detect if Android has finished doing its layout, as you could tap into OnDraw but it can be recursive, so you would never know when it finished.

|           | Appearing             | Appeared       | Disappearing         | Disappeared | 
| iOS       | ViewWillAppear        | ViewDidAppear  | ViewWillDisappear    | ViewDidDisappear | 
| Android   | OnAttachedToWindow    | OnGlobalLayout | ??                   | OnDetachedToWindow | 
| UWP       | Loading               | OnLoaded       | ??                   | OnUnloaded |

TheRealJasonSmith · December 2016

Disappearing is easy enough to emulate on platforms that need it. Basically emit when its removed from the logical hierarchy.

KentBoogaart · December 2016

@AdamP my thinking was that if the platform doesn't have a more specific hook, then the same hook resolves to both events. For example, on Android OnAttachedToWindow would fire Appearing and then Appeared immediately after. From the viewpoint of the consumer, I don't think it matters. As long as both events are raised in the right order and they correlate to the best possible hook in the underlying platform.

I know for a fact that setting up data in Appearing on Android (i.e. in response to OnAttachedToWindow) does not present the same problem as on iOS (data appearing too late).

AdamP · December 2016

@KentBoogaart - if a platform doesn't have a specific hook, I would go down the path of emulating it.

The problem is if you don't have all platforms behaving exactly same in this scenario it can lead to discrepancies in a XF app, that will be nothing but an absolute pain to then rectify from the app developers view e.g. me Say data loading too early, or too late, causing a not so smooth UI experience, or something like that.

TheRealJasonSmith · December 2016

Appeared could be handled by a variety of hooks. Draw is a bad one since overriding draw has performance implications, but the layout hook might work. We could even go as stupid as a timer if we want to be as loose as saying "Appeared will happen some time shortly after the object is on screen but not always immediately so"

KentBoogaart · December 2016

@AdamP As someone who also develops apps for a day job, I'm struggling to understand why emulation would lead to fewer headaches for me as an app developer. I don't think it's realistic to have exact same behavior across all platforms, but if we were trying to get as close to that as possible then we could just change iOS to use ViewWillAppear instead of ViewDidAppear.

That said, if a dependable emulation can be found I'm all for it. What worries me is trying to get too clever and creating more problems than we started with. I can imagine the underlying platform evolving and breaking the emulation, perhaps with no recourse. If we're only using life cycle hooks that are officially supported by the platform, that feels a lot safer to me.

TheRealJasonSmith · December 2016

I think we just need to be consistent in how we define what these events are.

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.

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.

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.

Disappeared: The view is no longer visible on screen.

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.

huangjinshe · December 2016

Too complex for leave 4 events. I think currently 2 events good enough already. could we let things more simple and easy for now?(for UWP especially)

JeremyKolb · December 2016

@huangjinshe We definitely need more than two events. I think @TheRealJasonSmith summed up the scenarios pretty well.

ModEdit - In the future please attempt to provide more than just a contrary/supportive opinion to help keep the conversation on track and productive Your rational as to why we need more than two would be a great addition to this post. If you simply agree with a previous post push the "Like" button. I am going to leave the comment in place so others may learn.

rmarinho · December 2016

I agree with the events, one of the thing to take notice is the hierarchy the events fire, so if i m child of a NavPage, nav page should fire first, then the child page. This is more complex that it seems in order to be consistent between platforms.

FredyWenger · December 2016

@huangjinshe
You can use the events, but you don't have to use it.
For me, this is a real problem and a good proposal (that should be accepted)

ModEdit - Removed strong formatting.

TheRealJasonSmith · December 2016

First, I want to post a reminder that "+1" style comments are not allowed. There is a like button if you agree with something.

Second, I want to say as a team we think this is a great proposal. It's something we have actually wanted for a while. I think this proposal still needs to work out the following things:

Ordering of event firing when taking a hierarchical view. Should child pages fire first or second? Does that matter at all? Should we guarantee an order or just say "hey this works a bit different per platform?"
A proper spec for this feature needs to be produced. To make sure we produce some nice examples I will make this spec once the above question is answered.

My personal opinion here is we probably shouldn't attempt to guarantee ordering in a hierarchical sense. It's quite likely we will end up having to fight the underlying platforms quite strongly. The only thing we should consider doing is making sure that its consistent that pages ALWAYS get these events, even if, for example, their parent is what is actually removed and the underlying toolkit doesn't end up triggering the events because of that.

Once we have a spec I will put a link to it (as a gist) in the OP.

ChaseFlorell · January 2017

Continuing on the lifecycle conversation. I think there's a strong need for one (possibly two) more beyond what's already accepted.

I'd like to propose at minimum OnRemoved and possibly OnRemoving (but maybe not necessary). The reason for this is for cleanup when a Page is being removed from the navigation hierarchy.

I've created a separate proposal, but it really does belong here.
https://forums.xamarin.com/discussion/85745/add-onpopped-method-to-page

Intended Use Case

The biggest reason for this is to solve the issue whereby we need to clear Behaviors from a VisualElement, especially when those behaviors are added via xaml. If we tap into the existing methods (even the ones proposed above), we would be cleaning up our page when a new page is pushed over top and not limited to when the page is popped.

Example:

[XamlCompilation(XamlCompilationOptions.Compile)]
public partial class MyFunPage
{
    public MyFunPage()
    {
        InitializeComponent();
    }

    protected override void OnRemoved()
    {
        // clean up behaviors once the view is definitely gone.
        MyVisualElement.Behaviors.Clear();
        OtherVisualElement.Behaviors.Clear();
    }

    // note: a destructor/finalizer doesn't solve this because it doesn't get called the way one would hope
}

DanielL · January 2017

Is it possible to also unify NavigationStack behaviour while making this change?

Last time I checked (some time ago), the behaviour on Android was:

Push a page to NavigationStack, then Pop it. Result: it isn't in NavigationStack anymore
Push a page to NavigationStack, then Tap navigation back button. Result: it's still in NavigationStack, until another page is pushed.

ToniPetrina · January 2017

That makes sense because one might go forward in time when going back. Like browsers do today.
However, when you pop a view, it is closed forever - just like a modal dialog.

MichaelRumpler · January 2017

@TheRealJasonSmith said:
First, I want to post a reminder that "+1" style comments are not allowed. There is a like button if you agree with something.

Please bring back that Like button! It's gone in the Evolution forum.
(now I have a Like button on my own post, but not on others')

I agree with @ChaseFlorell that we need to distinguish between when a page was popped or another has been pushed over it. In the former case you need to clean up, in the latter not.

I also opened a bug a few years back that Appearing/Disappearing were raised in a different order on iOS and Android when you pushed/popped a page. IMHO it is very important that the order is consistent over platforms. Unfortunately the bug got closed (not fixed) and I can't search for closed bugs on bugzilla.

Joshua.R.Russo · January 2017

@MichaelRumpler said:

@TheRealJasonSmith said:
First, I want to post a reminder that "+1" style comments are not allowed. There is a like button if you agree with something.

Please bring back that Like button! It's gone in the Evolution forum.
(now I have a Like button on my own post, but not on others')

I agree with @ChaseFlorell that we need to distinguish between when a page was popped or another has been pushed over it. In the former case you need to clean up, in the latter not.

I also opened a bug a few years back that Appearing/Disappearing were raised in a different order on iOS and Android when you pushed/popped a page. IMHO it is very important that the order is consistent over platforms. Unfortunately the bug got closed (not fixed) and I can't search for closed bugs on bugzilla.

+1

In all seriousness, in case it's not this way for others, the only place I do see the like button is on my own posts

PierceBoggan · January 2017

@Joshua.R.Russo said:

@MichaelRumpler said:

@TheRealJasonSmith said:
First, I want to post a reminder that "+1" style comments are not allowed. There is a like button if you agree with something.

Please bring back that Like button! It's gone in the Evolution forum.
(now I have a Like button on my own post, but not on others')

I agree with @ChaseFlorell that we need to distinguish between when a page was popped or another has been pushed over it. In the former case you need to clean up, in the latter not.

I also opened a bug a few years back that Appearing/Disappearing were raised in a different order on iOS and Android when you pushed/popped a page. IMHO it is very important that the order is consistent over platforms. Unfortunately the bug got closed (not fixed) and I can't search for closed bugs on bugzilla.

+1

In all seriousness, in case it's not this way for others, the only place I do see the like button is on my own posts

We're working on fixing it. It's a Vanilla Forums issue.

/backontopic

rmarinho · January 2017

@DanielL i think it depends where we check, the NavigationStack can be update after the animation finished vs being updated before, but yes we can fix that i just also found this issue while working on MacOS branch.

DanielL · January 2017

@rmarinho Fixing that bug would be very useful for me, eg. I could implement navigation back event.

i think it depends where we check, the NavigationStack can be update after the animation finished vs being updated before

On Android when navigation is used (back icon), it isn't removed from navigation stack at all. It's removed only if another page is pushed.

MelbourneDeveloper · February 2017

Please fix this.

KentBoogaart · March 2017

Note that I've posted an interim, hacky workaround for the iOS ViewDidAppear problem here: http://kent-boogaart.com/blog/hacking-xamarin.forms-page.appearing-for-ios

trung.dinh · March 2017

that's awesome! @KentBoogaart

BoguslawBlonski · March 2017

How's the progress ?
Just for info please note that people are coming to xamarin from other technologies WPF, WinForms, WebForms, Js ... Web , it would be nice to have same names, page loaded loaded ..

Sabdullah · June 2017

We really need a few other hooks, Create, Created, Destroyed, Destroying.

This may look like the Android Activity lifecycle.

Or the Android Fragment lifecycle:

And the Disappearing or Destroyed (or Destroying) hook should also allow the app to save the view's state (preferably a page's state) in a dictionary like object (Android's bundle concept) and that same object should be given back to the view's resurrected object if the app is being restarted.

But for all of this to work, Forms needs to take control of the app's lifecycle and retain and restore Page / View states and navigation stacks upon application restarts. Unless this is implemented, almost none of the lifecycle hooks give us much advantage...

ChrisBoyd · June 2017

I feel like it might be important to note that Google has looked into issues with lifecycle management on Android and came up with this for their new Architecture components.

They even provide new ways to track the lifecycle state and, thus, allow you to determine whether or not a specific function should run at this time.

e.g.:

    public void enable() {
        enabled = true;
        if (lifecycle.getState().isAtLeast(STARTED)) {
            // connect if not connected
        }
    }

WilliamJockusch · September 2017

I think the most important thing is to have every lifecycle event from every platform fire some callback in the page. I think it's fine if, as a consequence, there are some Page callbacks events that never fire on some platforms. It would be important to document that, obviously, maybe with a table of what platform event corresponds to which Page event.

DavidBerroa · December 2017

@WilliamJockusch said:
I think the most important thing is to have every lifecycle event from every platform fire some callback in the page. I think it's fine if, as a consequence, there are some Page callbacks events that never fire on some platforms. It would be important to document that, obviously, maybe with a table of what platform event corresponds to which Page event.

I like this idea.

I just ran into an issue where the lateness of iOS was a problem. I had to the customer renderer hack Kent wrote up to get it working with viewillappear.

Do we know if this will ever change?

TomSoderling · December 2017

I'd say yes.
See David Ortinau's response down at the bottom of this Bugzilla issue I filed related to this: https://bugzilla.xamarin.com/show_bug.cgi?id=60739

DavidBerroa · December 2017

@TomSoderling said:
I'd say yes.
See David Ortinau's response down at the bottom of this Bugzilla issue I filed related to this:

Glad to see it is an item on their list. I'm a little concerned about this part though:

"That proposal has been in spirit accepted, but needs a spec and someone to take on the work and generate a pull request."

What if no one takes on the work?

SteveShaw.5557 · June 2018

@ChaseFlorell re

If we tap into the existing methods (even the ones proposed above), we would be cleaning up our page when a new page is pushed over top and not limited to when the page is popped.

Perhaps it is more robust to ensure that all important view state is reflected in bound properties, so that it is easy to restore page to desired state in OnAppearing? IIRC, in native programming, it can happen that user has left your app, the OS has suspended it, and then returned to your app, re-creating all the views/fragments on the native nav stack. Is the Xamarin Nav stack susceptible to this? It might be a fragile illusion to rely on preservation of all details of a view on nav stack.

SteveShaw.5557 · June 2018

Re knowing when view has appeared on Android.

@AdamP - OnAttachedToWindow - this is a feature of Android NativeActivity which is a special activity convenient when using NDK to write in C/C++. Can this be adapted for use with Xamarin.Forms.Platform.Android.FormsAppCompatActivity, which is what I see as base of main activity on Android?

So far, I haven't found any solution other than overriding a View's OnDraw (as you mentioned), with a bool to only do the action once. Or perhaps instead put code in override of Draw. For completeness, here is how I see it:

Details:

    bool _appearing = false;

    // Following AdamP's suggestion to use this as "Before Appearing" method.
    protected override void OnAttachedToWindow()
    {
        _appearing = true;

        // Code here definitely happens before Draw, and doesn't require testing a flag.
        // However, it might happen EARLIER than is desired.
        // Android doc says "may be called any time before the first onDraw -- including before or after View.OnMeasure".
    }

    public override void Draw( global::Android.Graphics.Canvas canvas )
    {
        // This is the last possible moment before drawing.
        // Conceivably some quick "before appearing" work could be done here, "if (_appearing)".
        // In an extreme case, last-minute changes might make it worth suppressing the following base.Draw,
        // to quickly get back to measure/layout of changes.

        base.Draw( canvas );

        // Here, we know SOMETHING has been drawn.
        // Useful if you want to be sure user is seeing SOME version of your view,
        // before triggering an update that might be slow.
        // Ex: Asynchronously adding to a long scrolling ListView's ObservableCollection from web data -
        // if done while it is in middle of layout? measure? before first drawing, it apparently triggers re-layout,
        // so first drawing is delayed. Delayed repeatedly if you keep adding items. Instead here is first time to queue a task to do that.
        //if (_appearing) OncePerAppearance();
    }

    // TBD: Is this called at START or END of base.Draw?
    //   (If at End, then is equivalent to call above.)
    protected override void OnDraw( global::Android.Graphics.Canvas canvas )
    {
        //if (_appearing) OncePerAppearance();
    }

    // Uncomment ONE of the calls to this.
    void OncePerAppearance()
    {
        _appearing = false;

        // ... One time code per appearance.
    }

SteveShaw.5557 · October 2018

Kent Boogart's hack for iOS, to do an action before page appears:

https://kent-boogaart.com/blog/hacking-xamarin.forms-page.appearing-for-ios

My updated code for Android, to do an action after page is drawn the first time:

https://stackoverflow.com/a/52748913/199364

Combining these two hacks, with the existing behavior (which is "after appearing" on iOS, "before appearing" on Android), yields both before and after for the two platforms.

It should be fairly easy to incorporate both techniques into an implementation with "WillAppear" and "DidAppear".
So this hackery isn't needed by app programmers.

I'm not familiar with UWP.

AngeloLazzari · October 2018

@SteveShaw.5557 said:
Kent Boogart's hack for iOS, to do an action before page appears:

https://kent-boogaart.com/blog/hacking-xamarin.forms-page.appearing-for-ios

My updated code for Android, to do an action after page is drawn the first time:

https://stackoverflow.com/a/52748913/199364

Combining these two hacks, with the existing behavior (which is "after appearing" on iOS, "before appearing" on Android), yields both before and after for the two platforms.

It should be fairly easy to incorporate both techniques into an implementation with "WillAppear" and "DidAppear".
So this hackery isn't needed by app programmers.

I'm not familiar with UWP.

@SteveShaw.5557 thank you for your answer .... can you please explain where we have to put that hacks? thank you very much!

Xamarin

Improved life cycle support

Summary

API Changes

Intended Use Case

Accepted · Last Updated February 2017

Posts

Intended Use Case

Xamarin

Quick Links

Improved life cycle support

Summary

API Changes

Intended Use Case

Accepted · Last Updated February 2017

Posts

Intended Use Case