So right now I have a situation in which I have three fragments are committed in such an order:
Fragment A -> Fragment B -> Fragment C
Then, I start an Activity from Fragment C. The issue arises when I want to pop the back stack so the user is brought to Fragment B after the activity finishes. If I attempt to pop the back stack from the Activity before calling finish(), I get an IllegalStateException, saying that the action cannot be performed after onSaveInstanceState. Thus, is it even possible to make changes to the FragmentManager responsible for the fragments from the Activity?
How does this sound myrocks2? Android: how to make an activity return results to the activity which calls it?
First activity can start a second activity and expect a result. Upon getting back a result it knows second activity did its job, and now it's required to remove fragment c. (I don't know the logic of your app, but that can work)
Someone who thinks he is so smart gave you a negative vote, but I made sure to go away. There are no dumb questions.
Related
I have one Activity with 3 fragments which form a workflow to collect user input.
Normally, Fragment A is the first fragment -> Launches B -> Launches C. B is supposed to launch A if the back button is pressed, and similarly C's Back button is supposed to launch B.
However, in some cases, A is supposed to launch C directly, and then C's back should launch A again.
I prefer that C should not know who launched it. I.e. I want C's "backstack" to operate without C knowing who launched it.
I tried using the usual addToBackstack approach, but I'm facing a problem when the Activity gets killed after the user lets the app go into the background while C was open.
I would like the user to return to "C" instead of starting all over from A. To achieve this I'm using the saved Instance state, and detecting which fragment was previously active, and launching it from the activity.
The problem starts when the user wants to go back from C, after the Activity was recreated after being killed. C doesn't know who launched it: A or B. How do I make the Back button work as expected for this case?
Found some answers in this excellent video by Android Developers + Adam Powell:
Fragments: Google I/O 2016
In summary, Fragments and the Fragment BackStack are considered part of the navigational state of the app, so, as long as I don't mess with the backstack when the activity is launched, the OS will also restore the FragmentBackStack, thus the BackStack will know who launched C (A or B) even if the activity gets re-created. Thus, popBackStack will move from C to A or B as required.
I have researched numerous posts regarding Activity back stacks, as well as the Android Developer website, but still can't find a solution to a problem I'm having.
Scenario:
I have Activity A, I navigate to Actvity B, from A and then press the back button to go to Activity A again:
Actvity A --> Activity B --> Actvity A
Nothing out of the ordinary..
Problem
When I press the back button to go to from Activity B --> Activity A, Activity B is not destroyed straight away, as expected it goes into a pause state and this is where I have strange problem. If I want to return to Activity B from Activity A and IF Activity B is still in a pause state all its life cycle methods are called when use startActivity(B) from Activity A:
Activity B - onCreate() > onPause > onStop > onDestroy <-- why is this happening
At this point, to me it shouldn't exist anymore, and I can't explain why it went through all its lifecycle methods, rather than just the start initialisation lifecycle methods. The fall out from this strange behaviour is that the Activity is still visible on screen but doesn't populate a RecyclerView which in first initialisation did so as expected. At this point if I press back Activity B enters a pause state again.
If Activity B is in a pause state (Activity A is at top of stack) and the framework ends Activity B through lifecycle callbacks and I navigate to Activity B again from A it works as expected (RecyclerView is populated), basically a fresh instance always works fine.
All I can assume, when referring to the Activity Lifecycle diagram, is that Activity B enters a pause state, however is destroyed without calling onStop, onDestroy etc.. meaning any Activity clean up operations I have in those callbacks aren't happening?
Things I've Tried
Changing various Intent filters, and combinations, when starting Activity B:
FLAG_ACTIVITY_NEW_TASK
FLAG_ACTIVITY_CLEAR_TOP
FLAG_ACTIVITY_SINGLE_TOP
Calling finish() when onBackPressed() is called in Activity B
Various other fingers crossed and hope changes, nothing seems to work.
Can anyone help please!
Ok, so I found the answer to the problem - not obvious at first, but now I understand what was happening.
The root cause of the problem was to do with 2 instances of the same Activity (Activity B) referencing the same Objects (Objects supplied from DI library).
Firstly when returning to Activity A from Activity B, Activity B was not immediately destroyed, and this causes a complication - this instance would never be reused, however still existed for a period of a few seconds. In this situation when using startActivity(B) from Activity A it would create a new instance and destroy the old (hence why I was seeing logging in both creation and activity ending callbacks), if it still existed. In this scenario both instances were sharing the same object, and this object "cleaned up" the Activity when destroyed. So the object (Presenter in this case) was being told by the old instance that it should clean up the Activity as its being destroyed, however this was not the case, because a new instance had been created.
The solution
Quite simple really, every time a new instance of Activity B was created, store in the Presenter a unique number (startId), and when Activity B called onDestroy() pass its current unique number, and check they match - if they don't match its not the latest instance, so do nothing. Very similar idea when you want to stop a Service, and check its the latest Activity calling the service from the startId.
Personally I don't know why Activities aren't destroyed straight away on pressing back, but thats the reason why this was happening.
I have an activity A which contains fragment F. A shows F by pushing it onto fragment manager's back stack. This fragment may show a dialog(more specifically, a DialogFragment) D, also by pushing it to the same fragment manager's back stack.
I need to be able to dismiss dialog D under certain circumstances that are determined by fragment F. Normally I would check if D is on the fragment manager's back stack and use getFragmentManager().popBackStack() to remove it. But this doesn't work if the activity gets destroyed and then recreated:
Say I set "Don't keep activities" flag in Android Settings. Now I background the app. Activity gets destroyed, and the fragments are too. Now I foreground the app again. At what point do the fragments F and D get added to fragment manager's back stack? This is a screenshot I took after I put a breakpoint on A's onPostResume() method, which I assume is the very last one to run in the activity lifecycle, before the user can use the app:
You may notice that mAdded field contains 2 elements - those are the restored fragments F and D. But they are not on the back stack yet, as mBackStack is null!
I would like to be able to remove D, but Android won't let me do it, since it's waiting to restore pre-existing state of fragments and it won't add them to the back stack until some time after onPostResume.
So in essence, I can't remove the fragment from the stack, since it's not on the stack yet. And I also can't prevent it from being added to the stack at some point, since, as you can see from the screenshot above, fragment manager stores it in a separate list mAdded and there's no methods that I can use to remove it from mAdded.
How can I prevent a saved fragment from being restored?
Maybe Im wrong but AFAIK AOS doesn't store the fragment backstack at all if activity stops. It could only restore the last shown fragment without all the previous fragments on a stack.
However you could store the stack and fragments state yourself. Just remove your dialog in onPause storing some flag via onSaveInstanceState and then in onResume restore it or don't.
Imagine the following scenario:
Push Fragment A onto BackStack
Push Fragment B onto BackStack
Push Fragment C onto BackStack
Fragment B tries to make a async web request when its onResume is method is called.
Fragment C has a button called "Clear Backstack" that clears the backstack by calling popBackStackImmediate(null, FragmentManager.POP_BACK_STACK_INCLUSIVE).
When PopBackStackImmediate is called it pops the Fragments off one by one until the stack is cleared. As each fragment is popped the fragment's onResume method is called. For Fragment B, I don't want the async web request to trigger since its going to be immediately destroyed/removed after its popped (because the entire backstack is being cleared).
In this case how can I detect if the entire backstack is being collapsed and skip the async web request on Fragment B in the OnResume method? Note: I'd still want the async web request to execute if Fragment B is popped/displayed by using the Back button.
Note: I'm using the latest compatibility/support library.
Option 1:
Have you determined what other lifecycle methods are being called - if it's only on resume, then move the async call further down in the lifecyle (onCreateView or onAttach for example) so that it's only called when moving through it in the normal manner.
Option 2:
When onResume is called you could do a getFragmentByTag on the fragment which has already been destroyed. If this is null you could then assume that the operation in action is the destruction.
This one seems pretty ugly to me.
Option 3:
Have C pass some flag up to the controlling activity (we'll call it Main), move the async call up, and when B wants to do the web request, have it call up to main to do so. If C has set the "I'm Destroying" flag, then don't perform the request.
Update: I was previously removing the old fragment and then adding the new fragment using FragmentTransaction.remove and FragmentTransaction.add respectively. Switching to FragmentTransaction.replace solved most of my problems when working with the backstack. See below:
The Android documentation has this to say about FragmentTransaction.replace:
Replace an existing fragment that was added to a container. This is essentially the same as calling remove(Fragment) for all currently added fragments that were added with the same containerViewId and then add(int, Fragment, String) with the same arguments given here.
I found the documentation to be slightly misleading because there is an important difference between replace vs. remove+add when the backstack is involved:
If the backstack A->B->C is built using remove+add, then popped back to fragment A, then fragment B's onResume method will be triggered.
If the backstack A->B->C is build using replace, then popped back to fragment A, then fragment B's onResume method will NOT be triggered.
I want to avoid that in this navigation use case: A -> B -> A -> B -> A -> B ...
Where all the fragment instances are kept in the back stack. Reason: Avoid out of memory error.
I tried creating an own navigation workflow, like described here: https://stackoverflow.com/questions/18041583/fragments-backstack-issue?noredirect=1#comment26393904_18041583 (which is supposed to mimic activity behaviour calling always finish() after starting a new one, together with letting only the very first one (home) in the navigation stack).
But it seems to be either very wrong or ununderstandable.
So I thought, also, to implement a behaviour like activity "bring to front" flag. But I don't know how to do it. Maybe something with popBackStack - but I don't know how to ask the fragment if the transaction already is in the backstack. And I don't know if I'm on the right path.
This should be a quite standard task, since every navigation menu basically has this problem. But still, seems not to be straight forward to implement, and also can't find information about it.
Any idea?
Take a look at the FragmentManager backstack. It has facilities for looking at/popping entries in the fragment backstack. You might want logic something along the lines of: if the user is asking for a fragment that is at the top of the stack (the previous fragment) then exit this fragment (go back) otherwise start a new one.
That would produce:
A (user asks for B)
A->B (user asks for A again)
A
.. but would not prevent
A (user asks for B)
A->B (user asks for C)
A->B->C (user asks for A)
A->B->C->A
That would require rewinding the stack back to "A" from "C", which you can do.. but then if that is the case, perhaps you should be unconditionally popping the fragment stack before starting a new fragment (I.E. No back stack at all..)