I'm running into a bit of a problem.
I have a PreferenceActivity with a list of headers, each pointing to a fragment. Those fragments are shown as a single pane (small display).
In order to exit a header fragment and go back to the list of headers of the PreferenceActivity itself, I press the back button (as a user), or call getActivity().onBackPressed() if I need to get back to the list after the user pressed a button on the UI.
This brings me back to the header list PreferenceActivity, but it also calls the onDestroy() method of that activity.
This is what I don't understand:
Why does it call the onDestroy() when the activity itself is clearly visible? And why doesn't it call the onCreate() after that, again, since the activity is visible?
This also has a side effect of calling the onReset() of a loader I use to create the list of data that produces the headers in the first place. That in turn makes it look like the header list hasn't changed, even when I have removed an item from the list, and thus reduced the number of headers. If I actually close and reopen the PreferenceActivity, the header list will be correct, which shows that the loader itself is working.
I don't fully understand what is happening here without code. But from the sounds of it you are calling onBackPressed() for the activity, thus what happens happens irrespective of fragments. Try overriding onBackPressed() in the activity and handle your fragment transactions there.
Headers launch new activities in single pane mode. That is likely why you are seeing onDestroy() for the same named activity, as it launches the same activity with a different intent it seems.
For future readers.
Related
I have a problem. According to the drawing, I have an activity that has three fragments, each fragment has its recycleview with the items to choose from, so far so good.
My goal: when I click on an item, it opens another activity, legending it with a variable, so far so good.
When I press the back button, I leave the second activity and go back to the first with the variable, the problem is when I return to the first activity, I tried to trigger a function that analyzes the variable within onResume (), but this function it doesn't work, I repeat, it doesn't work with fragments. What return function works on fragments? Is there another simple alternative?
See the image here
Start your child Activity for result using startActivityForResult() and then in your child Activity set the result, after you have collected your data, using setResult() and manually finish your child Activity using finish(). Then in the Fragment class again, override onActivityResult() to receive the data set in your child Activity.
Refer to this guide for more in depth information: https://developer.android.com/training/basics/intents/result.
I'm writing an app that loads user profiles and user's ratings for different places. The app uses fragments pervasively, and it's relatively easy to jump from a profile to a rated place.
As a user clicks a profile and gets to a rated place, they can click another profile on a rated place and go on and on.
The problem I'm having is memory related, when I'm looking at a ranked place and I click a profile, I switch from one Activity to the next. In both of these activities, after setContentView I load a fragment dynamically into layout space.
Now, as I shuttle between these activities, onSaveInstance state is almost always called, however since the Fragment displaying whatever was in the foreground before the activity switch, onDestroyView is not called.
What I would like is when onSaveInstanceState is called in these dynamic fragments, it to force onDestroyView to be called as well.
The only time onDestroyView seems to be called is when I add a Fragment to the back stack. When another activity comes to the foreground and this fragment is stopped, I'd like on DestroyView to be called as well.
The current workaround I want to implement is have an empty fragment with no view, and every time I call startActivity(Intent i), load this dummy fragment to destroy views and start the next activity. Then, when I come back, pop it off the back stack and restore the actual last fragment.
This however seems excessive. So, for a stopped fragment in a stopped activity with a new activity in front of it, how do I force it to destroy it's View?
First, you should not force or satisfy onDestroyView to fix your code, that's the job of the FragmentManager and the Android lifecyle # Pausing and Resuming an Activity. If you want to work with your existing code, use the other override methods onPause() or onStop().
Without posted code, I assume you're using the replace() method to display one fragment over another. This more or less forces you to manage the fragments yourself, some developers actually succeed in doing so with some struggle (look at other SO questions).
So my suggestion for you is either:
Maintain your own states, and show the proper fragments based on the state.
Use the BackStack and let the Fragment management handle the stack/states.
I have two activities A and B. The A has a ListFragment which uses LoaderManager, whereas B activity shows a details about the item selected in the A's ListFragment. I've just noticed that when I use a back button to get from the B back to the A, the position in the ListFragment preserve, but when I use the up button (left-point caret) in the action bar, the A activity is recreated and thus position in list view is lost.
I would like fix this issue, but I am not sure about the best way how to do it right.
I come up with this solutions:
a) Use onBackPressed()
Replace the default implementation for the android.R.id.home (the up action bar button) in the B activity, and instead of the NavUtils.navigateUpFromSameTask(this) function call the onBackPressed() activity method. I've tested it and it works.
b) Keep use NavUtils.navigateUpFromSameTask(this)
But implement the onSaveInstanceState and restore listView position during onCreate method of the ListFragment used by the A activity. (I've not tested this approach yet)
Which of this solutions is better? Or is there any other (much more better) solution?
Solution a) is pretty simple and straight forward, but b) is probably better because the default implementation of the up caret is used.
Any ideas are welcome. Thanks.
Solution c is the correct option. First, though, an explanation of the problem with solution a.
There is absolutely no point in having two back buttons in your Activity. Furthermore, option a actually breaks the up button. The point of the up button is to provide a way for users to stay within your app when they have landed in your app from an outside source. For example, if you land on activity B from an outside activity C and if you are using your option a, then pressing "up" in activity B will result in activity C being shown. The behavior you would want would be for activity A to be shown.
As you can see, solution b is on the right track. You definitely want to go up to A and not back to C. However, simply storing the state in onSaveInstanceState will not cause the state to be retained. This is because onSaveInstanceState only gets called if your application may be killed by the system. It is not guaranteed to be called if your application was destroyed manually, and it certainly won't be called when a new instance of your Activity is created. If the Intent starts a new activity, then it will not have its state restored from the other activity.
There solution, then, is that you must write anything persistent to a shared preference file (or a custom persistent alternative). When doing this you can guarantee that all instances of an Activity share the same state across multiple tasks so long as their onResume (or wherever you restore state) is called. OR:
If you know exactly how you want your navigation to work, you can avoid writing everything to persistent state by using a combination of Intent flags and Activity task affinities. If you want to use the same activity as up even if you navigate into the application from an outside source, then you can leave your Activity A's affinity as default (linked to the application) and use something like Intent.FLAG_ACTIVITY_CLEAR_TOP.
Personally, I'd try the Intent flag approach first and failing that fall back to writing the state persistently. You just don't really want scroll location sitting on persistent storage if you can avoid it..
check out this presentation: https://speakerdeck.com/jgilfelt/this-way-up-implementing-effective-navigation-on-android. It answers to all of your problems.
As Android newbie I started to wonder about the Activity lifecycle. I'm having an Activity that loads a list of Persons and displays them. Upon the click of a Person I want to open another Activity showing the details of that Person. I'm currently doing this by creating an Intent on the "PersonDetailActivity" which I then start. So far so good. On the PersonDetail page I would like to have a menu action to go back to the Person list. I again applied the same technique, meaning an Intent that brings me back to the PersonListActivity.
Now I started to wonder what returning to the PersonListActivity means. Will a new instance get created and will I have to reload the persons that it displays in the list? Can you come back to the same instance, avoiding having to reload the list again? Do you then have to pass a pointer to yourself via the intent to the other Activity?
So when will and Activity be re-instantiated and when will it not. Any hints or suggestions are more than welcome. Maybe there are some patterns to be applied for these back and forth menu actions that I'm not yet aware of.
Thanks,
Vincent
Yes,,. Call finish() in second Activity instead of starting new Activity..
There is basically something called Activity stack which stores all Activities in the order they were started.. so if start new Actvity , that sits on top of the stack and preveous one gets below it.. when you call finish the Activity is poped out..
if you don't want to call finish() correct waht ever you were doing then add flag ACTIVITY_CLEAR_TOP in manifest for the 1st Activity..
Basically if you just call the finish() method on your PersonDetailActivity
PersonDetailActivity.this.finish();
it will activate the onResume() method from the Activity that is on the top of the finished one, which here would be your PersonsActivity. You can specify in your onResume() method what you want to perform when turning back there.
I am making a activity using Tab-Host.
I have two tabs. When I start the tab-Host activity, the tab-Host opens the activity and the life-cycle of the activity is calling but when I changed the tab and again open that previous tab the activity is not getting its callback methods like resume.
I don't think there is any specific reason it should restart. For changing configuration (like rotating the device or sliding out a keyboard) there is a specific trigger because the app needs to deal with the change. But any other process should go according to the Activitvy lifeCycle
When your app goes to the background (looses focus) for any reason you get onPause() called, and when it goes back, your onResume() will be called. This is the same for when you go home and then back to your app, or when you switch activities like that. No new intent or something like that, just going back to the activity.
You should put your code that needs to run in the onResume().
Do what you need to do in the activity in onResume() instead. That will get called everytime, not just the first time it is created.
http://developer.android.com/reference/android/app/Activity.html#ActivityLifecycle
When you switch from one tab to the other and back, the first tab only gets its onResume method called since it has already had its onCreate called the first time.
You can run the code you like in your onResume method if you want anything specific to happen when it gets focus again.