I'm building an application using a service and the fragment compatibility pack and am running into some weird behavior. I have a FragmentActivity and a ListFragment which implements LoaderCallbacks, and when the FragmentActivity starts it kicks off a service to download data and fill in a database.
Suppose I'm on that screen, and I navigate past it by clicking on one of the rows of the ListFragment. If I then hit a nullpointer, or any other exception that causes the regular force close dialog to pop up, I hit the force close button on the dialog and the activity I'm on does indeed get shut down, but I end up back on the FragmentActivity screen, rather than say my Android/launcher home screen.
To me this says that the app is crashing but somehow the fragment activity is getting restarted. The behavior occurs if I hit the red stop button in the debug view in eclipse - the current activity gets killed but that damn fragment activity is still there.
Obviously I don't want my app to ever get a force close dialog, but really what I'm trying to figure out is if this is a symptom of me not coding something correctly. Currently I never stop the service, mostly because it gets reused over and over again throughout the app and I haven't gotten around to coding up a way to close the service safely without prematurely ending a new request to it.
Is the service keeping a reference to the Activity via the ListFragment and LoaderCallback or something? Why is this FragmentActivity seemingly invincible?
This is happening because your process is killed, but there are other activities on the activity stack. This is the expected behavior, as the system attempts to start a new process on the next activity on the stack once your offending activity was removed. See here and here.
If you want to remove all of your activities off the stack after a force close, one thing you can do is hit the back button until you are taken to the home screen. Unless you override the behavior of the back button in your app, it destroys your current activity and takes you to the previous activity. Once there are no more activities left, you will be taken to the home screen and can start your app again from eclipse, and it will start you off at your main activity.
i had run into similar problems, with Databse loading and Nullpointer Exceptions. I don't know your special case but it might help to separate the Databse out into a Content Provider if you aren't already doing that, that way you are decoupling the Fragments form the Database more, it might help with the errors.
Related
When a user enters an activity on my app I want to perform some logic during onStart and possibly launch a second activity before letting the user see the first activity (think of this as a pin protected activity)
I have a small issue where the contents of the first activity are shown for a second before the second activity is started. This happens when the user uses the home button to get out and in to the app. Is there a way to prevent the first activity to be visible at all before performing the logic validation?
This is more of a "design" solution to your problem and not clear if it'll work for you. I had something similar in the app I'm working on. What I did instead, was to create an interstitial Activity that resembled the same starting state (i.e. not yet completely loaded) of the Activity (Pin-protected Activity in your case) that is about to be started. Once I'd made my appropriate decision about whether or not I could go on, I just navigated to that initial Activity. In your case, I could see you making the decision on this interstitial Activity, and then navigating to the Pin-protected Activity or to the other one if conditions were not met properly.
The only downside to this approach is that the app does a quick flash with the additional Activity, but I think the increased separation of logic is worth it.
I am running into problems where if a user navigates through several child activities without returning to the MainActivity in between, when they press the back button it closes to the Android Home screen. I never call finish() on my MainActivity, it doesn't happen consistently, and not from the same screens. It happens when I have gone through many different Activities without returning to the MainActivity.
I'm assuming that the system is terminating the Activity while its in the background, but I'm not sure. Is there anyway to ensure that my parent activity doesn't get terminated?
I did not create the project. I'm aware that the navigation structure he used isn't right, but as of right now I'm not in the position to fix it.
Please do not tell me to do things a different way. I am asking only if there is a way to keep a particular activity from being terminated by the system.
While it's not possible to stop your activity from being destroyed, you can check if there's no activities in the backstack, and restart your MainActivity when the back button is pressed in this particular case.
You could try to put a handler in it that doesn't do anything besides giving itself another task (which is to give itself another task) every few seconds.
In my application i have a listView.
I populated this listView 10 items at a time.
So, i fetch the 1st 10 items in the background when i am showing a spalsh screen. and once the splash screen goes away user can see the 1st 10 items.
Now in the Activity which contains this listView i wrote something like this:
onLastItemReached(){
getNextten();
}
works fine. and when i am going to someother activity from this listViewActivity i set the flag so that all the items browsed till then will be retained when back is pressed(i mean if user scrolled down to 100 items and clicked one item and went to some activity and clicks device back button, he will be shown the 100th item and the rest 99 items doesn't need to be fetched again)
the problem is when i close the application and open it after some 5-10 mins it gets crahsed saying:
ArrayIndexOutOfBoundsException
if i am reopening it in 1-3 mins it works fine.
Sorry i cannot post any code because all the activity has around 800 lines.
Any one has any idea why i get this exception always. and 1 thing i want to know is, is there anything like if an app is in background for more than 5 mins remove all its data
Edit:
my closing my application, i mean when i am on the ListView Screen i press Home button, reopen the app after 5-10 mins
This is the StackTrace i get, I was trying to Handle unCaughtExceptions:
threadid=1: thread exiting with uncaught exception (group=0x40020660)
java.lang.RuntimeException: Unable to start activity ComponentInfo{com.Android.WiC_MobileApp/com.Android.WiC_MobileApp.FeedListViewActivity}: java.lang.ArrayIndexOutOfBoundsException
at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:1728)
at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:1747)
at android.app.ActivityThread.access$1500(ActivityThread.java:155)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:993)
So after looking at my log cat it says the error is at line 201, and that line contains:
Log.d("array of product names", SplashActivity.products_array[0] + "--"
+ SplashActivity.products_array[1]);
This is an array populated in SplashActivity and made public static.
if an app is in background for more than 5 mins remove all its data
This could actually happen within 1 minute. It's just dependent on the environment that the system is running on. When you press the home button (or back button on the top activity) the system will put your app in a hibernation sort of mode. It keeps it in memory until that memory is needed. This allows the user to quickly go back to it on the event that they simply wanted to switch real quick and go back. After a few minutes though, if the user opened up a game or something, the OS may decide to wipe the app from memory. In which case, when the user reopens your app, you have to rebuild everything from scratch.
The reason your app crashes is because you're trying to retrieve the element before the app has actually rebuilt the ListView. If the app is still in memory, it works because everything is still built. If the app was removed, then the list must be rebuilt, re-inflated, or whatever. Then you try to retrieve the element.
When your app is in the background, Android can kill it at any time (simply by killing the process that your activities are running in). If the user then wants to return to your app, Android creates a new process for your app and then recreates only the activity that was on the top of the activity stack (ie: the one that was showing when your app went to the background).
From the logs it looks like your app crashes when trying to launch FeedListViewActivity. Since this is probably the activity that was showing when your app went to the background it looks like Android is trying to recreate the activity, which would imply that your process was killed while the app was in the background (see my explanation above).
You say that the data you are trying to access is set up by SplashActivity and kept in a static variable. The problem is that when Android creates a new process for you, it only recreates the top activity, not all the activities underneath that. It doesn't recreate the SplashActivity so that variable has not yet been initialized.
Here are some possible alternatives to deal with this:
Check if the process has been recreated in onCreate() of FeedListViewActivity and, if so, you'll need to recreate the list of data that the SplashActivity had previously set up for you. You can tell if the process has been recreated by having SplashActivity set a public static boolean variable to true when it runs and by checking that variable in FeedListViewActivity.
Check if the process has been recreated in onCreate() of FeedListViewActivity and, if so, simply redirect to your SplashActivity to start the application all over again.
Persist the data by saving it to a Bundle in onSaveInstanceState(). Android will call this method on your activity before the process gets killed so you have a chance to save any data you may need later when the activity/process is recreated. You'll need to restore the data in onCreate() and/or onRestoreInstanceState().
Persist the data in a file or in an SQLlite database.
You are getting ArrayIndexOutOfBoundsException because every time when you reaches to last item you are trying to read 10 more records.
But suppose your array has 50 records. When you reach to 50 you are again going to read new 10 records. it means 51-60
which are not available that's why you are getting exception
onLastItemReached(){
if(totalDispayed < yourArray.length()) <-----
getNextten();
}
You need to implement something like as i have mentioned above
What I have:
I have 3 activities in my app with a basic nested structure:
Activity 1 --> Activity 2 --> Activity 3
Activity 2 contains data embedded in an ArrayList<CustomClass>. CustomClass extends application (as taught here) and Activity 3 uses this to modify the CustomClass data for Activity 2.
What I want:
When the user hits the Home button and then opens my App again later, I want to return to whichever activity was on the top of my stack. (I thought this is supposed to be Android default behaviour.)
It works fine on my Eclipse emulator but on both my Google Nexus One and Huawei Honour, the task is completely restarted.
I have tried setting my activities to run in standard, singleTop and singleTask launch modes. The best result I could get on the phones was to return to Activity 1 (which is just a form) and still display what I had entered into the text fields before creating Activity 2.
I did also notice that if I hit Home then check the Running Applications under Settings, my app is not listed. Maybe Android might be destroying my task and I need to save the activity state. But this doesn't make sense if I press home and immediately re-enter the app?
Advice is appreciated.
There is no guarantee that once you hit the Home button and your Activity goes in onPause() it will keep its state (even it it keeps the same state, there is no guarantee on the actual amount of time the activity will remain in memory). This depends on the device in particular and how it handles its internal memory. (see this figure which shows the Android Activity Lifecycle).
The best practice is to always save your state in the onSaveInstanceState method. This post provides a good and easy example on how to do that.
I have read the other window leak posts and have tried what what suggested there to no avail.
I have 3 activities: A, B, and C. Activity A gathers information from the user. Activity B displays a spinning ProgressDialog while it communicates with a server on another thread. When the thread finishes, it dismisses the ProgressDialog and starts the next activity. Activity C displays the information from the server to the user. Activity B is set up so that when the user hits back from C, they fall back to A.
It is important that these tasks be in separate Activities.
As of now the app successfully does what it is supposed to in most cases, except in the following scenario: If the user changes the orientation while in activity C before returning to Activity A, the app crashes due to a window leak.
I am dismissing the ProgressDialog inthe onPause() of Activity B before istart C.
I have tried dismissing the
ProgressDialog on the main thread
using a handler as well as in the
separate thread.
When the user does not change the
orientation in C, no window leak
occurs.
Any ideas? TIA
This often happens where ProgressDialogs are used. I experimented with ProgressDialog a while back and found the thing to do was dismiss() it from onPause() and create it anew from onResume(). The background task obviously needs to survive your Activity & dialog so I used onRetainNonConfigurationInstance() to pass the task instance from the destroyed Activity to the new one.
An alternative, cheatier workaround might be to simply prevent your Activity from being destroyed and created anew merely because the screen orientation changed. Do this by adding android:configChanges="orientation" to the tag(s) in your AndroidManifest.xml.
I solved my problem by completely changing how i handled everything. I now have only two activities (A and B) and display the ProgessDialog in activity B while handling the savedInstanceState as needed in order to work around the problem.
Even though I have fixed the problem on my app, I still dont know why it was occuring before and would like to learn more about window leaks and why i was having problems. If anyone knows more about the problem i was having, please post as I'm sure there are others with the same problem.
Thanks
Not sure if this was related to your specific problem, but I had a similar issue which had to do with leaky windows for dialogs that are created in the onCreate method of an activity. So if your activity starts up showing a dialog, and you do a config change, the OS remembers which dialogs were shown, so when the activity is killed & restarted, the OS attempts to restore your old dialog while your activity tries to show the same dialog again (since it's in onCreate). I found by only showing the dialog during onCreate if it's not a config change (ie. savedInstanceState != null), the leaky window problem went away.