-
Notifications
You must be signed in to change notification settings - Fork 1.9k
[iOS] Call page appearing when restoring app from background #11172
Conversation
I typically use this logic to not have appearing/disappearing events on pause/resume in Android:
Is there an option to opt out of this on iOS too? |
What is the use of these events as there's no action points on a per page level when the app is suspended and resumed? It just takes a lot of work to get rid of these unnecessary calls. OnAppearing and OnDisappearing are the closest thing to lifecycle events and I can't see them being used for anything else than as a pseudo constructor and destructor. The app being suspended and resumed has no bearing on individual pages, and for generic sleep/resume code there's Application.OnSleep and Application.OnResume anyway. To make matters worse, in order to opt out of these it's not enough to listen to OnSleep/OnResume and skip the next appearing/disappearing call, as OnSleep and OnResume are called AFTER OnAppearing/OnDisappearing -- so when one of these fire you are absolutely blind as to why. I had to build an entire system just to get the calls in an order where they are useful for anything, https://github.com/Tommigun1980/Xamarin.Forms.ExtendedLifecycleContentPage, and now even more calls are going to be made that need to be filtered out. So tldr: In what scenario is it useful to get OnAppearing/OnDisappearing calls on a per-page level when the application sleeps and resumes; ie exactly what problem does the change solve? (I you want to play around with these, please change the order of OnAppearing/OnDisappearing and OnSleep/OnResume instead. Calling OnAppearing before OnResume, and vice versa, means you can't run any code in OnAppearing and OnDisappearing as you can't know for sure whether the page really appeared or if the app just suspended/resumed. These events are so badly designed that they are bordering on useless, and any change like this means one has to rebuild their event system.) |
Also, isn't this a breaking change as it completely changes the event system (and for the worse imho)? I get the feel this change was made to conform to incorrect documentation, instead of serving a real purpose. |
Well put. This will break a lot of apps, especially since it's not marked as a breaking change in the release notes. |
Edit: I now see that this was done in order to make iOS work the same way as Android, which is of course a good thing. May I suggest that instead of enabling this behavior on iOS you’d remove it from Android? By doing so both platforms would work the same way, and because OnAppearing/OnDisappearing being called on sleep/resume are highly problematic, that’d solve an issue instead of creating one. There really is nothing you can do in them when the app sleeps/resumes other than try to filter them out. Thanks. |
I have updated to 4.8 version and it is causing an issue due to this fix-4986, I have reverted to 4.7 for now. Can we expect something in the future releases which includes something similar to Android where we can turn that off? |
…11172) fixes #4986 (#12263) * Revert "[iOS] Call page appearing when restoring app from background (#11172) fixes #4986" This reverts commit 77e79f7. # Conflicts: # Xamarin.Forms.Platform.iOS/PageLifecycleManager.cs # Xamarin.Forms.Platform.iOS/Renderers/PageRenderer.cs # Xamarin.Forms.Platform.iOS/Xamarin.Forms.Platform.iOS.csproj * - fix rollback
Has this issue been resolved as yet? |
Updated to 4.8.0.1687, still didn't hit the break point in OnAppearing(). I click the home button on IOS simulator and then return to the app after a while. Is it coming in the next release? |
Description of Change
Handle calling appearing and disappearing of pages when the Application is going to background and restored.
Issues Resolved
API Changes
Platforms Affected
Behavioral/Visual Changes
When the app is restored the current page should have the Appearing event being called, like on Android.
Before/After Screenshots
Not applicable
Testing Procedure
use
new NavigationPage(new ContentPage52318())
in the MainPagePR Checklist