XF Lifecycle not hitting OnResume at Launch

ClintStLaurentClintStLaurent USUniversity ✭✭✭✭✭
edited October 2017 in Xamarin.Forms

https://developer.xamarin.com/guides/android/application_fundamentals/activity_lifecycle/

Maybe I'm just nuts but I swear this has changed at some point recently.
The startup lifecycel as documented is:
1. Launch
2. OnStart
3. OnResume
Meaning OnResume still hits once after your app has started.

But... Now I'm watching and breakpointing my app and seeing that OnStart hits at launch but OnResume does not... Until I actually background it and then resume it. Then the Application class hits OnResume before MainActivity.OnResume; which seems backwards.

Am I just loosing it? Am I wrong to expect OnResume to hit at launch?

Best Answers

  • ClintStLaurentClintStLaurent US ✭✭✭✭✭
    Accepted Answer

    I think I have it clear... And a clear picture of where my thinking broke down...

    ANDROID MainActivity - Will call OnStart and then OnResume. But the PCL does not get that same behavior. PCL Application only gets OnStart

    My confusion has come in with confusion Android Activity Lifecycle with Xamarin Application Lifecycle... especially when the generic template puts handlers for the those lifecycle events in from the start. I just assumed that if the Activity got an event then it was passed up. Therefore if the Activity was getting OnStart and then OnResume the Application would hear them both as well. The idea that Xamarin would filter that out so the Application behaved differently just never occurred to me.

    Thanks for helping to set me straight @NMackay @JohnHardman @ClayZuvich

Answers

  • NMackayNMackay GBInsider, University mod
    edited October 2017

    @ClintStLaurent

    These app methods have been notoriously unreliable but testing on hardware right now it seems fine :)

    OnResume is not supposed to hit on Launch.....but it used to in my experience. I had to check the IoC to see if a service had been intialised in the past.

    Tested it just now on my own S5, the life cycle events debug correctly...in VS2015 SP3 anyway. It seems reliable now.

  • ClayZuvichClayZuvich USMember ✭✭✭
    edited October 2017

    Despite what the google docs say, my experience has been that the OnResume isn't always called on launch for Droid. I've had consistent success using OnWindowFocusChanged. You're not crazy... Android is just a pain in the rear.

    https://developer.android.com/reference/android/app/Activity.html#onWindowFocusChanged(boolean)

  • JohnHardmanJohnHardman GBUniversity mod
    edited October 2017

    @ClintStLaurent @NMackay - I've just run a quick test on a physical Samsung-J500FN running Android 6.0.1.

    With a splash screen activity that starts the main activity, this is the startup sequence that I am seeing:

    SplashActivity.OnCreate
    SplashActivity.OnStart
    SplashActivity.OnResume
    MainActivity.OnCreate
    MainActivity.OnStart
    MainActivity.OnResume
    SplashActivity.OnStop
    SplashActivity.OnDestroy

    At first I wasn't seeing OnCreate for the SplashActivity, but then noticed that there are two OnCreate signatures. I added the second one, and that was hit. The one that isn't being called is Android.App.Activity.OnCreate, which is marked with metadata saying ApiSince = 21. The one that is called is Xamarin.Forms.Platform.Android.FormsAppCompatActivity.OnCreate

    If you are seeing a different sequence, I wonder if it's o/s version dependent?

    I've had essential code in the OnResume override for both the splash screen activity and main activity since I started working with XF. My code is dependent on it being called, so I can be pretty certain that it has always been called on my various test devices (I think they range from Android 4.4 to 6.0.1 currently).

  • ClintStLaurentClintStLaurent USUniversity ✭✭✭✭✭

    Scenario...
    No SplashActivity. Just MainActivity with a splash screen designated in the theme, and Intent listening for the connect/disconnect of a USB scanner.
    Testing against Samsung TabE 8" tablet running Android 6.01 {Verizon}

        #region MainActivity (Class : FormsAppCompatActivity)
    
        [Activity(ConfigurationChanges = ConfigChanges.ScreenSize | ConfigChanges.Orientation,
                  Icon = "@drawable/icon",
                  Label = "xxxxxxApp",
                  LaunchMode = LaunchMode.SingleInstance,
                  MainLauncher = true,
                  Theme = "@style/Theme.Splash",
                  WindowSoftInputMode = SoftInput.AdjustPan,
                  ScreenOrientation = ScreenOrientation.Landscape)]
        [IntentFilter(new[] { UsbManager.ActionUsbDeviceAttached, UsbManager.ActionUsbDeviceDetached })]
        [IntentFilter(new[] { Intent.ActionMain,
                              UsbManager.ActionUsbDeviceAttached,
                              UsbManager.ActionUsbDeviceDetached },
                              Categories = new[] { Intent.CategoryHome, Intent.CategoryDefault })]
        [MetaData(UsbManager.ActionUsbDeviceAttached, Resource = "@xml/device_filter")]
        public class MainActivity : FormsAppCompatActivity
    
      <style name="Theme.Splash" parent="MainTheme.Base">
        <item name="android:windowBackground">@drawable/splash</item>
    

    Too many cooks in the kitchen. So many team members all wanting their VM to be launching 'right away' at app launch. Most are not Xamarin trained and thinking that just spinning up a new thread is the answer. (Why listen to the only Xamarin certified guy in the office, right?)
    At boot I sometimes see the Android device saying

    But the app does continue to boot up- It just has a massive amount of crap its doing at launch.
    And this seems to be a pretty good indicator that the Application class is not going to be notified of OnResume.
    So I'm starting to think there is a threading condition taking place and the events are getting lost before reaching the PCL Application class.

    @JohnHardman You listed all the MainActivity events hitting. What about your PCL Application class that is supposed to hit those same handlers? The App.xaml.cs class if we're talking about a default "Welcome to Xamarin" solution. This is where I am especially noticing the OnResume() not being hit. {Maybe "Not being hit consistently" is going to prove more accurate)

        public partial class App : Application
        {
            public App()
            {
                InitializeComponent();
                MainPage = new NavigationPage(new HomePage());
            }
    
            #region Application lifecycle state changes 
            protected override void OnStart()
            {
                // Handle when your app starts
            }
    
            protected override void OnSleep()
            {
                // Handle when your app sleeps
            }
    
            protected override void OnResume()
            {
                // Handle when your app resumes
            }
            #endregion Application lifecycle state changes
    

    @NMackay

    OnResume is not supposed to hit on Launch.....but it used to in my experience.

    You say its not supposed to hit on Launch... but that chart in the Xamarin documentation looks to me to say otherwise. And John is saying it does hit in his testing; at least in the Android MainActivity - which is what a couple of the Android specific coder here seem to feel/recall/beleive. Is there some documentation someplace that says specific whether it should or should not?

    Tested it just now on my own S5, the life cycle events debug correctly...in VS2015 SP3 anyway. It seems reliable now.

    Just to be clear... What is 'correctly' in your terms? Does, or does not, hit OnResume as part of the launch sequence?

    @NMackay

    These app methods have been notoriously unreliable but testing on hardware right now it seems fine

    I think the emphasis is on "right now"... at the moment... today at xx:xx O'Clock. Yes?

    @ClayZuvich said:
    Despite what the google docs say, my experience has been that the OnResume isn't always called on launch for Droid.
    You're not crazy... Android is just a pain in the rear.

    I'm starting to lean this direction specifically with the "always" part. It would explain some of the reports from our own team members that say:

    Sometimes it just doesn't seem to boot right.

    And I'm beginning to think that "sometimes" the OnResume doesn't trigger and so many of the VM's don't get that first wake up call to do their job.

  • JohnHardmanJohnHardman GBUniversity mod
    edited October 2017

    @ClintStLaurent - Using XF 2.3.4.270, I can confirm that the PCL's OnResume is not called on first launch, testing on the same setup as before.

    However, it is not expected to be called in that scenario.
    The documentation at https://developer.xamarin.com/guides/xamarin-forms/application-fundamentals/app-lifecycle/
    says "OnResume - Called when the application is resumed, after being sent to the background."

  • ClintStLaurentClintStLaurent USUniversity ✭✭✭✭✭
    Accepted Answer

    I think I have it clear... And a clear picture of where my thinking broke down...

    ANDROID MainActivity - Will call OnStart and then OnResume. But the PCL does not get that same behavior. PCL Application only gets OnStart

    My confusion has come in with confusion Android Activity Lifecycle with Xamarin Application Lifecycle... especially when the generic template puts handlers for the those lifecycle events in from the start. I just assumed that if the Activity got an event then it was passed up. Therefore if the Activity was getting OnStart and then OnResume the Application would hear them both as well. The idea that Xamarin would filter that out so the Application behaved differently just never occurred to me.

    Thanks for helping to set me straight @NMackay @JohnHardman @ClayZuvich

  • JohnHardmanJohnHardman GBUniversity mod
    edited October 2017

    Just hit another one where await becomes a problem - on UWP, with a bottom toolbar, don't await anything before the toolbar items are added. In that scenario, when await results in control returning to the caller (XF), XF seems to calculate the size of the viewable page content. When the await completes, the toolbar items are added, the toolbar appears, but the viewable page size is not re-calculated (in XF 2.3.4.270). As a result, the toolbar obscures part of the page content. I've raised a bug.

    Perhaps it's time for me to finish my own toolbar implementation, which I started ages ago but haven't finished yet...

Sign In or Register to comment.