patternjavaMinor
Communicating upwards from nested fragments in Android
Viewed 0 times
androidfragmentsnestedupwardscommunicatingfrom
Problem
I recently asked this question on Stack Overflow, but now that I have a working example, I would like to have it checked.
I set up the layout like this:
I am going off the idea that parents can talk directly to their children, but children should use an interface to talk to parents (docs). The docs where not clear, though, about communication between nested fragments. That is why I made this project.
MainActivity.java
ParentFragment.java
```
import android.content.Context;
import android.os.Bundle;
import android.support.v4.app.Fragment;
import android.support.v4.app.FragmentTransaction;
import android.util.Log;
import android.view.LayoutInflater;
import android.view.View;
import android.view.ViewGroup;
public class ParentFragment extends Fragment implements View.OnClickListener, ChildFragment.OnChildFragmentInteractionListener {
// start interesting part ****
private OnFragmentInteractionListener mListener;
@Override
public void onClick(View v) {
mListener.messageFromParentFragmentToActi
I set up the layout like this:
I am going off the idea that parents can talk directly to their children, but children should use an interface to talk to parents (docs). The docs where not clear, though, about communication between nested fragments. That is why I made this project.
MainActivity.java
import android.support.v4.app.FragmentTransaction;
import android.support.v7.app.AppCompatActivity;
import android.os.Bundle;
import android.util.Log;
public class MainActivity extends AppCompatActivity implements ParentFragment.OnFragmentInteractionListener, ChildFragment.OnChildFragmentToActivityInteractionListener {
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
FragmentTransaction ft = getSupportFragmentManager().beginTransaction();
ft.replace(R.id.parent_fragment_container, new ParentFragment());
ft.commit();
}
@Override
public void messageFromParentFragmentToActivity(String myString) {
Log.i("TAG", myString);
}
@Override
public void messageFromChildFragmentToActivity(String myString) {
Log.i("TAG", myString);
}
}ParentFragment.java
```
import android.content.Context;
import android.os.Bundle;
import android.support.v4.app.Fragment;
import android.support.v4.app.FragmentTransaction;
import android.util.Log;
import android.view.LayoutInflater;
import android.view.View;
import android.view.ViewGroup;
public class ParentFragment extends Fragment implements View.OnClickListener, ChildFragment.OnChildFragmentInteractionListener {
// start interesting part ****
private OnFragmentInteractionListener mListener;
@Override
public void onClick(View v) {
mListener.messageFromParentFragmentToActi
Solution
I have a few suggestions about your code.
First, the easy one, is that you can follow this "standard" for the onAttach method:
Why I say this is the standard? Principally because when you make in Android Studio New --> Fragment --> Fragment (Blank) and select the option to communicate with the Activity, this is code generated, with the catch directly instead of checking the instance of.
The second part could have more debate.
Before start, remember that a Fragment should be agnostic of the activity is contained, that is the reason we use activity cast in the onAttach, to ensure we can use that fragment in whatever Activity.
Saying that, we have to know if the child fragment is agnostic of the parent fragment or is always related to it and we can ensure ChildFragment can't live without the partent.
If the ChildFragment is agnostic to the parent the correct solution should have in the ChildFragment only a listener with the Activity and the responsibility of communicate with the ParentFragment is of the Activity.
If the ChildFragment is always related with the ParentFragment, childFragment should only communicate with it and the Parent pass that "messages" to the activity.
With this approach, that I know is a little more boring, you can assure that every class only has dependencies with the classes that should know and maintain SOLID
First, the easy one, is that you can follow this "standard" for the onAttach method:
@Override
public void onAttach(Activity activity) {
super.onAttach(activity);
try {
mMinInfoToApplyCallback = (MinInfoToApplyCallback) activity;
} catch (ClassCastException e) {
throw new ClassCastException(activity.toString() + " must implement MinInfoToApplyCallback");
}
}Why I say this is the standard? Principally because when you make in Android Studio New --> Fragment --> Fragment (Blank) and select the option to communicate with the Activity, this is code generated, with the catch directly instead of checking the instance of.
The second part could have more debate.
Before start, remember that a Fragment should be agnostic of the activity is contained, that is the reason we use activity cast in the onAttach, to ensure we can use that fragment in whatever Activity.
Saying that, we have to know if the child fragment is agnostic of the parent fragment or is always related to it and we can ensure ChildFragment can't live without the partent.
If the ChildFragment is agnostic to the parent the correct solution should have in the ChildFragment only a listener with the Activity and the responsibility of communicate with the ParentFragment is of the Activity.
If the ChildFragment is always related with the ParentFragment, childFragment should only communicate with it and the Parent pass that "messages" to the activity.
With this approach, that I know is a little more boring, you can assure that every class only has dependencies with the classes that should know and maintain SOLID
Code Snippets
@Override
public void onAttach(Activity activity) {
super.onAttach(activity);
try {
mMinInfoToApplyCallback = (MinInfoToApplyCallback) activity;
} catch (ClassCastException e) {
throw new ClassCastException(activity.toString() + " must implement MinInfoToApplyCallback");
}
}Context
StackExchange Code Review Q#141407, answer score: 2
Revisions (0)
No revisions yet.