I am creating an android application. It holds a downloading process from server. It's running fine until the application runs and maintains the data without any crashes, but now I am stuck up with the problem as described below
When the application minimizes by pressing home button and after a long time, when I open the application all the data in the application are deleted. It gives me a "Null Pointer Exception"; even the ArrayList value are deleted and it gives a 0 sized arraylist.
I am opening the application after maximizing from the home screen through OnResume only, but it didn't call itself.
I don't know why this problem occurs. Can anyone please suggest me a solution and point me what am I doing wrong?
Yes, it's true - as #paradx said - that the Garbage Collector throws away the data while the app is in background. Finally I found a solution based on #paradx suggestion, as data are stored in SQLite or savedInstanceState
Just pass some of static values through the
intent.putExtra("static key","static value");
Then static hashmap are written in a file and retrieved for later use. Now the application does not crash for this problem.
I have posted this solution so that someone might use it.
My guess is, that the garbage collector throws away your data while your app is in the background. try saving your data either to the built in SQLite database, or to the savedInstanceState bundle in the onSaveInstanceState() lifecycle method and load it back in the onRestoreInstanceState() method.
Did u use the apache HTTP client or the UrlConnection?
See Apache http client or URLConnection
Maybe the wrong use could lead to such an NPE.
Could you also please post your logCat output?
Related
Have an application that generates an arrayList of data collected from a rest call. The arrayList is used in an adapter supporting a listView. Had a case where the arrayList reach a size of 999 entries.
The application passes the arrayList via a putExtra on an Intent. The arrayList is used to populate a listView. When startActivity is called, the application crashes without generating a stack trace recorded in stacktrace.
Is there a limit to the size an arrayList can be? Have set a debug break point in the activity started and the crash is occurring right after calling the super onCreate method.
Ideas on how to debug this? Have been able to pass a 390 entry arrayList without crashing.
AS #CommonsWare said, there's a limit of < 1MB but in real practice is way less than that, as soon as you need to pass more data than a couple hundred KBs you need to use other procedures to pass the data around.
The most common one would be to save it into a Local database or other type of storage and then on the other activity query for the data (on the intent you only pass the data needed to query for the list later on) and instead of loading all of them at once, you use a CursorLoader so that you only load the data as you need.
Other quick and dirty way is by adding an static field to pass the data to the other activity and then on load read the value and remove it, the problem that you will face is that this is not Thread-safe nor it will solve the issue of what to do with the data on the other activity when onSavedInstanceState gets exectued, because you are going to run into the same 1MB issue. [WARNING: This is the worst solution you could think of, so, please try anything else before you try this one, that's why i gave you first a very good approach and leaved this one at the end]
[UPDATE:]
BTW the first approach is how we fixed this problem on the Microsoft Band app, because we had so much data coming as part of a very long run (GPS points, and other tracked data). Just make sure that the data is not big enough that you will generate a bottleneck somewhere else, we used to only cache it in memory and never send it to disk to avoid the serialization process or the time it took to save and retrieve from storage.
Now I'm facing some problem in Android when memory is low or the application is killed by system.
Scenario 1:
I set some static members in a class, I found in some situation , it will be deleted by system when the application is still running.
My problem to this is : when does this kind of GC run?
Scenario 2:
If I switch to another large application and then switch back to my application ( named App_A). App_A sometimes will be recycled by system and restart the last activity when it be switched back.
But there are some application-wide data (like login info) I saved in a singleton.
My problem to this is : Dose the application-wide data saved in singleton will be deleted?
If so, is there a appropriate way to restore the data?
My effort is:
To Scenario 1, I will avoid to use static member directly.
To Scenario 2, I will save those data into file , after it be deleted, I pass Context to each public function to let each of them have the ability to restore the data. But I think it will be unfriendly when the function is used in some situation which need run quickly.
I can only answer about Scenario 2.
Android will try to keep recently used apps in memory, but if the user switches to another app and memory starts running low, the OS has the option to kill the recently used app to make more memory available to running applications.
I had the same problem, where I had some user-context data like username in a static singleton. This data would disappear when returning to the app after using a number of other apps.
The way I solved this problem was to use the activity's intent. Since the user data was retrieved at the beginning of the app, I would simply pass this data to subsequent activities in their intents. Because the OS stores the intent and uses it to recreate an activity not in memory, my data was no longer vulnerable to being garbage-collected.
Also consider other means of persisting data: Shared Preferences, file system, SQLite database. But never count on static data from previous execution being available at the start of an activity.
It is generally bad idea to use singleton to save some data.
Best practice is using any persistent storage - SQLite, Realm,JSON, or any file.
Easiest way is saving your login data for ex. in JSON - then in Application class parse it in onCreate method into POJO - then you can get it from any place of your app. And store to file when app is closing or on any change.
Anyway I suggest you to read Android guides about persistence, memory management and performance tips.
I´ve an Android Application that holds some static objects on an class that extends Application class, using the same approach as exemplified here.
The objects that is hold by this class is shared and manipulated between all activities on my app.
Everything works well, but, some time ago, I noticed that when the application runs on backgroud for some time, when it´s restored, the data that was stored on the extended class has gone, and the app starts to throws a lot of NullReference exceptions.
I think that this happens because of the application was being temporary destroyed by the OS, to be recreated when we need to use it again.
So, how could I handle this scenario? Is there any way to discover that the application is being temporary destroyed, without subscribing to the onDestroy event of an Activity? On a test that I did, the onDestroy event was not called when I asked the background process of my app to being stopped.
Thanks a lot!
There is no way to determine when the proccess will be killed, so you always should store important data somewhere(sd-card for example) and restore it in onCreate() method of your App class.
Also take a look at onLowMemory() and onTrimMemory(), release all unnecesary data in memory to help the OS prevent destroying your app, cause one of the reason to determinate your app is a lack of memory.
No, there's no way to tell when you need to persist data that you store in static variables like that. There's no callback that the systems notifies you about this, at least to my knowledge.
So you should only use static variables to store temporary data, or cache data accessed from peristent sources. I've faced this problem in many of my projects, and I always ended up using intents / shared prefs / sqlite / etc. to reliable store data across Activities.
I have a multi-Threaded android application. One of the things my application does is saves various data to a database on a server via webservices. I was trying to figure out why things were not saving to the server correctly, and saw in one of my log files, that the application objects onCreate() method and constructor were called in the middle of one of the requests going up to the server. These request are in the background and are sent via an intentservice.
I have my application set to catch unhandled exceptions and log them, and I did not see anthing in there. The application onCreate() and constructor was called, the application was kicked back to the main/first screen, the user then had to re-login, and it seems that the database was wiped(which is something else I am wondering about).
So, my main questions are: Why did the application object onCreate() and Constructor get called(why did the application get killed), why did the database get wiped when the above happened because if I do a force stop from inside of settings, applications, it never kills my db.
two words: low memory
I have the same problem. No solution for now. Try to take advantage of the onLowMemory() method, maybe the OS will spare your app.
My application object gets restarted randomly (not any time) when I am coming back from an external application (ex. camera or gallery) for onActivityResult().
Hope that helps someone.
If the application is not a service, but a 'normal' application that calles your intentservice, it is subject to the normal application lifecycle: this means it will get killed when in the background.
Look for the explaining image on this site: http://developer.android.com/guide/topics/fundamentals/activities.html
Take note of the red "Process is killed" part on the left, an the subsequent "onCreate()" afterwards.
I've actually seen very similar behaviour that was caused by a NumberFormater trying to parse a null String. After the call to parse(), the application simply reset itself back to the splash screen with no errors at all. Wasn't fun to track down, pretty much stepped through half the code base trying to find out what was happening - the debugger disconnected and the app restarted when stepping past the parse call.
I noticed that when my application encounters an error, the value of my application context variables are also reinitialized to its original value (not the updated value). Based from my understanding, this happened because the application was recreated.
How can I save and restore the values of my application context variables when an application error occurs? I'll also be glad if you could give a more detailed explanation on how things are working on the background of my application when it encounters an error.
Note: I read that one of the solution for this is by using SharedPreferences. However, SharedPreferences saves the data even when the application is dead. I don't want to save the data when the application is dead. I only want to save the data when the application is alive or on background.
How can I save and restore the values of my application context variables when an application error occurs?
First, don't have an unhandled exception.
Second, don't rely on static data members or custom Application subclass instances. There are many scenarios in which your process will be terminated and those values go away. They should be used for an in-memory cache of persistent content, and little else.
Sometimes, unhandled exceptions are truly unexpected, but these should be infrequent and usually tied to specific devices (e.g., ran out of storage space). Everything else represents a bug in your app, and you must fix the bugs.