Develop Reference

How to notify a Fragment in the Backstack that it is on top again

Since Fragments were introduced I keep my eyes open for a good solution to update a Fragment to which I'm going back to.
This is my scenario:
I have a One-Activity App. When the App starts it shows a FirstFragment. With a button click the user can open a SecondFragment. Both Fragments are full screen and will be opened via androids NavController.
Note: Both fragments get their data from a rx-based repository. The repository and its underlying classes handle all CRUD operations.
What I want to do:
Updating the FirstFragment as soon as the user clicks back on the SecondFragment OR in other words: I want to update the FirstFragment as soon as it comes on top from the background.
The Problem
The FirstFragment gets no callback or livecycle event if it comes into view again.
In the past I solved this problem with a ListenerInterface that was triggered in the activities onBackPressed or with a broadcast event. But is there no better solution? I question if there is a possibility via LiveData or via NavController or anything else. Or does anybody know how google solves this problem?
What I NOT want to do
As my data layer is based on rx I could of course have a BehaviourSubject that I subscribe on in the FirstFragment. Then when I switch to SecondFragment I could keep the subscription undisposed so the FirstFragment will be updated as soon as i call onNext on the BehaviourSubject. I've seen apps doing this and it seems wrong to me. In my opinion a subscription should be disposed as soon as another ViewModel steps into place.
Thanks in advance
Android, notify backstack fragments on some change

Android navigate up the right graph when using NavController

I'm currently using Android Navigation Architecture in my project. It has a feature that can launch any fragment with a shortcut.
Suppose my navigation graph looks like this: A->B->C->D.
When I'm at fragment A , I directly navigate to fragment D with NavController.navigate(R.id.fragment_d). But when I'm press back button, it returns to fragment A. Is there any way to let the destination navigate back to its parent in navigation graph? (I mean, in this case, D back to C, B then back to A).
Thanks in advance.

Generally, you should always avoid creating a synthetic back stack when within your own app (and only do this when launching your app from a deep link outside your app, i.e., via an app shortcut).
However, you can approach this in one of two ways:
If you're okay with resetting the state on A, you can use NavDeepLinkBuilder to construct a set of Intents suitable for restarting your task on the chosen destination:
navController.createDeepLink()
.setDestination(R.id.destination_d)
.createTaskStackBuilder()
.startActivites()
Just call navigate() multiple times.
navController.navigate(R.id.destination_b)
navController.navigate(R.id.destination_c)
navController.navigate(R.id.destination_d)

I think you should be able to use navControler.navigateUp() on the destination if you have correctly introduced the parent fragment for your fragments. Also, consider the difference between the device back button and up back-arrow to go up to the parent

Saving fragment state on navigating up

Situation:
Starting from my host activityA/fragment A, I click on a button to start host activityB/fragment B. Fragment B is a fragment which enables filtering options for Fragment A. After selecting the options, the user can press the navigate up button to return to fragment A.
Problem:
I would like the state of the options selected to be retained when navigating to Fragment B more than once. Since this is a filtering option, it would be preferable to not save this in storage beyond the duration of the application (It's just filtering. Not necessary to keep the information stored for a long time. Just in between navigation).
Things I've tried:
OnSavedInstanceState - realized that onNavigateUpTo() / finish() don't trigger onSavedInstanceState
android:launchmode="singleTop" - Because the activity is finished and destroyed from the backstack, no instance of the activity is available to receive the new intent.
setRetainInstance - Activity is destroyed so attached fragment also destroyed.
A possible solution I've found is to use setResult and return the values to Fragment A. Then put these values as EXTRAs into a new intent when starting Fragment B again. This solution seems clunky. Is there a cleaner solution that just allows Fragment B to "remember" its state instead of passing values back and forth?

As you have stated the fragment is destroyed when user goes back so there is no way to get the "state" back. Also it does not make sense to store state as logically the fragment/activity is not needed from platform point of view.
So the way to 'remember' the state of fragment is to store the filter data in some other variable(s) and give it back to it when it is re-launched. What you are trying to do it perfectly fine i.e. return the filter data as result and send it back to fragment at re-launch.
To make it simpler you may write a class containing all the filter options and make it Parcelable. You may choose to make it a global so that you may not need to send it across activities, I would not prefer to do that though.
One UX issue is when user presses up/back it is generally expected that user has cancelled the operation. I as a user expect when I press back it cancels the operation and when I press "apply" it applies the filters. You may need to rethink about the user experience about applying filter on back press.

Which one to use NavUtils.navigateUpFromSameTask() vs. onBackPressed()

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.

Retain Fragment state between Activities

Its possible to retain a Fragment between Activities?
Lets say I have Activity A with Fragment F_Left placed at the left and Fragment F_Right placed at the right. If I want to launch a new Activity and keep Fragment F_Left... how can I do it?
Can I retain Fragment F_Left state between activities?
Note that I want to launch a new Activity because Fragment F_Left is my app menu and Fragment F_Right changes completely the context of the user operations... and my app have many of operations, so it makes sense to have an Activity per operation.
I know its possible to retain Fragment within an Activity, but as Fragment life cycle is closely tied to the container Activity I don't know if this is possible keep Fragment state between Activities.

Since API Level 13 (HONEYCOMB_MR2, June 2011), you can save and restore the state of a fragment across activities.
To save the state, use FragmentManager.saveFragmentInstanceState(), providing a reference to the Fragment whose state you wish to save. The Fragment must be attached at the time you attempt to save its state.
To restore the state, use Fragment.setInitialSavedState() with the return value when you instenciate the same Fragment.
myFragment = new MyFragment();
myFragment.setInitialSavedState(appState.getMyFragmentState());
fragmentManager.beginTransaction().add(R.id.container, myFragment).commit();
You can persist the SavedState object across activities as you would any other object; one way is to subclass Application as shown above (appState is the instance of our subclass).

Based on your response to my comment, I have a slightly different answer. It may not end up being the best answer in your specific situation, I'll let you decide that. :)
Right now you are bundling your fragments in activities because that is what made sense to you, but really, you can probably treat the entire process as one activity and use fragment transactions to hide & show (or create and destroy) fragments as needed.
Since you won't be creating and destroying activities, your menu fragment on the left will be left untouched, and you won't have any problems with its UI state. The set of operations you want to run (which no doubt includes all sorts of different fragments on the right) does not need to be launched in a new activity - but you will have to find a way to manage the logic you need for the fragment transactions (either in your one über-activity or in some kind of OperationsManager class).
I think this will end up being a lot smoother for the users of your application since the single activity just remains running - and you are only changing the parts that actually need to change.

If I want to launch a new Activity and keep Fragment F_Left... how can I do it?
Don't launch a new activity.
Can I retain Fragment F_Left state between activities?
Not automatically. It is not the same fragment. You would pass data between the activities for use by the fragment no differently than you would without any fragments at all.

To potentially answer your original question, if you fire off another activity then I believe that you can save your fragment from your first activity by calling FragmentManager::putFragment(...) when onSaveInstanceState(...) is called and then getting it back later, e.g. in onCreate(...).
However, I have to agree with Mark D's response.
Incidentally I'm doing something similar in that I have a dual pane setup whereby the left pane if fixed with a number of options with each option invoking a different fragment in the right pane. Furthermore selecting an entry in the right pane can result in the right fragment being replaced by another one.
However, I have taken the approach whereby by left fragment is only responsible for displaying and handling responses from the immediate fragment which appears in the right hand pane. Furthermore each right-hand fragment is then responsible for 'replacing' itself with a new fragment and handling results sent back to it. I'm using setTargetFragment, getTargetFragment, and calling onto the target fragment's onActivityResult method to pass results back.
For me the approach I've taken is no different from when my app runs on a phone with a single pane whereby the initial option's activity only knows about the activies it fires off and subsequently these new ones fire off further activies which they know about.
It should be mentioned that my activity in my dual pane app doesn't really do much apart from loading the left pane fragment and I can't quite see the need for a single activity to ever have to manage hundreds of fragments.