• After 15+ years, we've made a big change: Android Forums is now Early Bird Club. Learn more here.

Apps multitasking problems

L

lms5400

Newbie
seems like a number of my users experience crashes when resuming the back-grounded app. I'm not sure how to repeat the crash but it seems to be very much related to the state of the operating system.

What happens is that some of my arrays bound to static memory go null. But there is no possible way for that to occur in any state in my app. The only way it could occur if it it skipped my first activity (which initializes them) and they jump to a later activity.

When apps come back into the forground, could the OS clear out memory if it decides the app is no longer worthy of taking up resources and it gets paged out, then dump you to the last activity you left off on? In order words, could my global variables be destroyed or compromised and then my app tries to load the last activity the user left off on (not necessarily the first activity) therefore creating a state that is will crash my app?
 
upon further testing, i think its an issue with 2.2 only. I was able to get it to crash on resume in a 2.2 simulator (and on the phone) but no other supported versions or phones had issues that i know of.

Does 2.2 have issues?
 
If you are using deprecated methods, there is a possibility that one or more of the deprecated methods in use are no longer supported by the OS. This is the reason that a lot of apps required an update on release of 2.2.
 
I think this is androids doing. If the application is kept in the background for so long that the system needs its resources elsewhere, Android kills the process. And when user wants to use the application again, the application is given a new process, but the content in memory is lost.
I'm not sure about this, so don't shoot me if I'm wrong.
 
i'll look for deprecated functions, but shouldn't i get waring about that?

As far as android paging out my app.... if it decides it needs resources, it might put it to to the SD memory right? Then when i need it, it pages it back in, this is standard OS virtual memory management. If for some reason if it decides my app needs to be closed and never come back, why would it try to resume on the screen it last left off - should it not just start over? I'm totally confused. I'm pretty sure this is not an issues with my code (but i have been wrong many times about that point, lol). But i'm at least 100% sure static memory array objects are being null'ed for no reason on resume which is very disturbing.
 
lms5400 said:
seems like a number of my users experience crashes when resuming the back-grounded app. I'm not sure how to repeat the crash but it seems to be very much related to the state of the operating system.

What happens is that some of my arrays bound to static memory go null. But there is no possible way for that to occur in any state in my app. The only way it could occur if it it skipped my first activity (which initializes them) and they jump to a later activity.

When apps come back into the forground, could the OS clear out memory if it decides the app is no longer worthy of taking up resources and it gets paged out, then dump you to the last activity you left off on? In order words, could my global variables be destroyed or compromised and then my app tries to load the last activity the user left off on (not necessarily the first activity) therefore creating a state that is will crash my app?
Click to expand...

I know exactly what's going on. Your static variables ARE going null because the phone is killing your app's process while the user is in a different app. This happened to us a lot on the Android app that we created. Also, you'll never want to carry around static variables if you don't have to. With the way Android allows you to pass things around from and to activities with intents and such, there shouldn't be a need for statics.

In either case, to fix your problem, have your Activity override the onSavedInstanceState(Bundle) method. Use the passed in bundle to store all the data that you want to have retained in the case the Android OS kills your app.

If the OS does kill your app, the OS will restart the app in the same activity that it was previously at, and will actually AGAIN go through your onCreate(Bundle). Guess what this bundle is? It's the same bundle that you saved data into from onSavedInstanceState(Bundle). Use this bundle to replace the arrays that are going null and possibly any other fields that you might need.

As a note, the onSavedInstanceState(Bundle) method is called by the ActivityManager when your app goes into a state where it is killable. Refer to the Android Activity Lifecycle linked above to see when your app can be killed. The ActivityManager calls this as an effort to save the necessary data in the case it will kill your app.

Note: This happened to us also with crashing, and while it is unrelated to the problem at hand, may help someone. If you have to reinflate dynamically added layouts because of a crashed app, do so in the onPostCreate() method. If we did it in onCreate(Bundle), then for some reason (even though we had it inflating new versions of the layout every time), there seem to be an issue with references getting mixed up and changes to one would affect changes to all the layouts. *Just a side note :P*
 
Thank you, that was very helpful! I'll look into passing around variables. One of the issues I had with that last time i briefly looked into it was I thought for some reason only basic datatypes were allowed to be passed around with the bundle class such as integer, boolean, string, etc, and my custom objects were not?
 
In order for your custom objects to be passed around through intents and such, you class must implement the Parcelable interface. If you implement this, your class implements a WriteToParcel() method and a describeContents method. For describeContents, just have it return zero. For the WritetoParcel method, use the parcel parameter to store each of the fields in your object. pay attention to the order! if you lok at the java doc for Parcelable, it has a code example check out the Parcelable.CREATOR. copy it! Then change all the types on the Creator to your object. The two methods inside the creator, newArray(), which should just return your object returned as an array with the size parameter. The other, allows you to "unmarashall" the parcel to your object. Typically, I let my class have a constructor that takes aparcel. remember the order? Read the values from the parcel back in in the same.order it was written out.
 
You must log in or register to reply here.
Back
Top Bottom