Activity doesn't fully display, then app crashes when resumes after a long period

AndyFlisherAndyFlisher GBBeta, University ✭✭✭

Odd one this and looking for pointers, app using the app compatible library's, tabs and fragments all works fine, activity loads the tabs, fragments etc. when app resumes from background again all fine. However, if you try to resume after a few hours you will get the activity title bar, and then a white screen below (no tab bar, no fragments ) and then the app crashes. I'm using Bugsense, but it's not catching the app.

Obviously Having to wait 3 hours to recreate is a pain, not caught it on a device whilst debugging, so not many clues. I'm guessing it's due to the activity lifecycle and android is closing things down, but would expect the app to open as new if been force closed, or am I wrong? I'm logging events to file to try and catch but any other pointers to try would help

Tia

Answers

  • CheesebaronCheesebaron DKInsider, University mod

    You should be able to reproduce that by going to "Developer options" on your device and in the bottom tick "Don't keep activities". This will trigger that behavior when returning to the app.

    Mind you there is a difference in using the back button to exit the app and pressing home!

  • AndyFlisherAndyFlisher GBBeta, University ✭✭✭

    Didn't know that one, cheers, will,try in the morning, will save me a few hours if nothing else!

  • CheesebaronCheesebaron DKInsider, University mod

    About my last sentence:

    Mind you there is a difference in using the back button to exit the app and pressing home!

    Hitting back until the app closes will kill the app entirely when having that option set, so when returning to the app it will restart from scratch. Using home however, will background it and save the bundle. When coming back it will hand you that bundle so you can re-hydrate your app.

  • AndyFlisherAndyFlisher GBBeta, University ✭✭✭

    Thanks for the tips @Cheesebaron‌ didn't help me catch this one though, even when closing the activities explicitly the app resumes / restarts perfectly (there's very little in terms of application 'state' as such to remember, the Activities, well fragments redraw based on DB content or are static in the main).

    I also checked the debug logs I'd but in (basically logging each and every application lifecycle state it hits to give me a clue) and there was nothing logged at the point it crashed - any ideas where / what else I can use to catch the crash?

    TIA

  • AndyFlisherAndyFlisher GBBeta, University ✭✭✭

    Still looking for help on this one, going to disable some network background libs in case that, but query ref Activities.

    Basically my app has a LoadingActivity (the launcher activity) that does some stuff, sets the scene, then calls the next Activity (MainActivity - which has NoHistory set to false so you can't go back to LoadingActivity), does this by;

    Intent intent= new Intent(this.ApplicationContext, typeof(MainActivity));
                    intent.SetFlags(ActivityFlags.NewTask);
                    StartActivity(intent);
    

    MainActivity is the one that is briefly displayed when the App resumes 4 hours or so later and then crashes (I can tell by the title on screen). Is there something wrong in how I've implemented this process that I should look at, or could it be the SupportActionBar at issue (that would be the next thing to be rendered on screen).

    Appreciate any pointers as have no clues at all at the moment :-(

  • CheesebaronCheesebaron DKInsider, University mod

    If you are using Fragments anyways, why not just swap the Fragment when you are ready to display the app stuff instead of starting a new Activity?

  • AndyFlisherAndyFlisher GBBeta, University ✭✭✭

    It's slightly more complex than I described, the Loading Activity will have a registration / login form with a different visual layout to the main app so easier to user a different Activity with a different theme than use Fragments.

    As it stands, I think it's either the Bugsense of Flurry (probably Bugsense since the crash is not being caught!) binding too blame, or at least it's taking an age to repeat the bug

  • AndyFlisherAndyFlisher GBBeta, University ✭✭✭

    So, it turns out that the crash is the ServiceContainer class throwing a cannot resolve service, except that the class in question had been registered and resolved umpteen times, but something in the time gap seems to cause it to deregister or forget that it had an instance.

    Actually it looks very similar to this issue here - http://stackoverflow.com/questions/19223974/using-tinyioc-in-xamarin-android

    So identify the cause, no idea on the resolution though. Same class and structure is working a treat on iOS

  • AndyFlisherAndyFlisher GBBeta, University ✭✭✭

    Bit early to tell, but looks like the issue was I was registering the services in the first Activity class, and the application lifecycle was in essence killing them off, so they didn't exist.

    I've subclassed the Application class now, and moved all my startup service registration to that, and just resolving the services from the container in Activities. My understanding, and by killing the process to test, is that if the OS does kill it off they'll be re-registered when the Application fires up, and thus problem solved.

    Odd that I've never hit this before, but guess been lucky, or at least other apps have been simpler - thanks for the pointers though

Sign In or Register to comment.