Práctica recomendada para crear instancias de un nuevo fragmento de Android

He visto dos prácticas generales para instanciar un nuevo Fragmento en una aplicación:

Fragment newFragment = new MyFragment();

y

Fragment newFragment = MyFragment.newInstance();

La segunda opción hace uso de un método estático newInstance()y generalmente contiene el siguiente método.

public static Fragment newInstance() 
{
    MyFragment myFragment = new MyFragment();
    return myFragment;
}

Al principio, pensé que el principal beneficio era el hecho de que podía sobrecargar el método newInstance () para dar flexibilidad al crear nuevas instancias de un Fragmento, pero también podía hacerlo creando un constructor sobrecargado para el Fragmento.

¿Me he perdido algo?

¿Cuáles son los beneficios de un enfoque sobre el otro? ¿O es solo una buena práctica?

Si Android decide recrear su Fragmento más tarde, llamará al constructor sin argumentos de su fragmento. Por lo tanto, sobrecargar el constructor no es una solución.

Dicho esto, la forma de pasar cosas a tu Fragment para que estén disponibles después de que Android haya recreado un Fragment es pasar un paquete al setArgumentsmétodo.

Entonces, por ejemplo, si quisiéramos pasar un número entero al fragmento, usaríamos algo como:

public static MyFragment newInstance(int someInt) {
    MyFragment myFragment = new MyFragment();

    Bundle args = new Bundle();
    args.putInt("someInt", someInt);
    myFragment.setArguments(args);

    return myFragment;
}

Y más adelante en el Fragmento onCreate()puedes acceder a ese número entero usando:

getArguments().getInt("someInt", 0);

Este paquete estará disponible incluso si el fragmento es recreado de alguna manera por Android.

También tenga en cuenta: setArgumentssolo se puede llamar antes de que el Fragmento se adjunte a la Actividad.

Este enfoque también está documentado en la referencia del desarrollador de Android: https://developer.android.com/reference/android/app/Fragment.html

El único beneficio al usar lo newInstance()que veo son los siguientes:

1. Tendrá un solo lugar donde todos los argumentos utilizados por el fragmento podrían agruparse y no tiene que escribir el código a continuación cada vez que cree una instancia de un fragmento.

   Bundle args = new Bundle();
   args.putInt("someInt", someInt);
   args.putString("someString", someString);
   // Put any other arguments
   myFragment.setArguments(args);

2. Es una buena manera de decirle a otras clases qué argumentos espera que funcionen fielmente (aunque debería ser capaz de manejar casos si no hay argumentos agrupados en la instancia del fragmento).

Entonces, mi opinión es que usar una estática newInstance()para instanciar un fragmento es una buena práctica.

También hay otra forma:

Fragment.instantiate(context, MyFragment.class.getName(), myBundle)

Mientras que @yydl da una razón convincente sobre por qué el newInstancemétodo es mejor:

Si Android decide recrear su Fragmento más tarde, llamará al constructor sin argumentos de su fragmento. Por lo tanto, sobrecargar el constructor no es una solución.

Todavía es bastante posible utilizar un constructor . Para ver por qué esto es así, primero debemos ver por qué Android usa la solución anterior.

Antes de que se pueda usar un fragmento, se necesita una instancia. Android llama YourFragment()(el constructor sin argumentos ) para construir una instancia del fragmento. Aquí se ignorará cualquier constructor sobrecargado que escriba, ya que Android no puede saber cuál usar.

Durante la vida útil de una Actividad, el fragmento se crea como se describe arriba y Android lo destruye varias veces. Esto significa que si coloca datos en el propio objeto de fragmento, se perderá una vez que se destruya el fragmento.

Para solucionarlo, Android le pide que almacene datos utilizando un Bundle(llamada setArguments()), al que luego se puede acceder desde YourFragment. Los argumentos bundleestán protegidos por Android y, por lo tanto, se garantiza que sean persistentes .

Una forma de configurar este paquete es mediante el uso de un newInstancemétodo estático :

public static YourFragment newInstance (int data) {
    YourFragment yf = new YourFragment()
    /* See this code gets executed immediately on your object construction */
    Bundle args = new Bundle();
    args.putInt("data", data);
    yf.setArguments(args);
    return yf;
}

Sin embargo, un constructor:

public YourFragment(int data) {
    Bundle args = new Bundle();
    args.putInt("data", data);
    setArguments(args);
}

puede hacer exactamente lo mismo que el newInstancemétodo.

Naturalmente, esto fallaría, y es una de las razones por las que Android quiere que uses el newInstancemétodo:

public YourFragment(int data) {
    this.data = data; // Don't do this
}

Como explicación adicional, aquí está la Clase de Fragmento de Android:

/**
 * Supply the construction arguments for this fragment.  This can only
 * be called before the fragment has been attached to its activity; that
 * is, you should call it immediately after constructing the fragment.  The
 * arguments supplied here will be retained across fragment destroy and
 * creation.
 */
public void setArguments(Bundle args) {
    if (mIndex >= 0) {
        throw new IllegalStateException("Fragment already active");
    }
    mArguments = args;
}

Tenga en cuenta que Android solicita que los argumentos se establezcan solo en la construcción y garantiza que se retendrán.

EDITAR : Como se señaló en los comentarios de @JHH, si proporciona un constructor personalizado que requiere algunos argumentos, Java no proporcionará a su fragmento un constructor predeterminado sin argumentos . Por lo tanto, esto requeriría que defina un constructor sin argumentos , que es un código que podría evitar con el newInstancemétodo de fábrica.

EDITAR : Android ya no permite usar un constructor sobrecargado para fragmentos. Debes usar el newInstancemétodo.

No estoy de acuerdo con la respuesta de yydi diciendo:

Si Android decide recrear su Fragmento más tarde, llamará al constructor sin argumentos de su fragmento. Por lo tanto, sobrecargar el constructor no es una solución.

Creo que es una solución y una buena, esta es exactamente la razón por la que fue desarrollada por el lenguaje central de Java.

Es cierto que el sistema Android puede destruir y recrear tu Fragment. Entonces puedes hacer esto:

public MyFragment() {
//  An empty constructor for Android System to use, otherwise exception may occur.
}

public MyFragment(int someInt) {
    Bundle args = new Bundle();
    args.putInt("someInt", someInt);
    setArguments(args);
}

Le permitirá avanzar someIntdesde getArguments()este último, incluso si el sistema lo Fragmentha recreado. Esta es una solución más elegante que el staticconstructor.

En mi opinión, los staticconstructores son inútiles y no deberían usarse. También lo limitarán si en el futuro desea ampliar esto Fragmenty agregar más funcionalidades al constructor. Con el staticconstructor no puedes hacer esto.

Actualizar:

Android agregó una inspección que marca todos los constructores no predeterminados con un error.
Recomiendo deshabilitarlo, por las razones mencionadas anteriormente.

Algún código de kotlin :

companion object {
    fun newInstance(first: String, second: String) : SampleFragment {
        return SampleFragment().apply {
            arguments = Bundle().apply {
                putString("firstString", first)
                putString("secondString", second)
            }
        }
    }
}

Y puedes obtener argumentos con esto:

val first: String by lazy { arguments?.getString("firstString") ?: "default"}
val second: String by lazy { arguments?.getString("secondString") ?: "default"}

La mejor práctica para instanciar fragmentos con argumentos en Android es tener un método de fábrica estático en su fragmento.

public static MyFragment newInstance(String name, int age) {
    Bundle bundle = new Bundle();
    bundle.putString("name", name);
    bundle.putInt("age", age);

    MyFragment fragment = new MyFragment();
    fragment.setArguments(bundle);

    return fragment;
}

Debe evitar configurar sus campos con la instancia de un fragmento. Porque cada vez que el sistema Android recrea tu fragmento, si siente que el sistema necesita más memoria, entonces recreará tu fragmento usando un constructor sin argumentos.

Puede encontrar más información sobre las mejores prácticas para crear instancias de fragmentos con argumentos aquí.

Desde las preguntas sobre las mejores prácticas, agregaría, que a menudo es una buena idea utilizar un enfoque híbrido para crear fragmentos al trabajar con algunos servicios web REST

No podemos pasar objetos complejos, por ejemplo, algún modelo de usuario, para el caso de mostrar fragmentos de usuario

Pero lo que podemos hacer es registrar a onCreateese usuario! = Nulo y si no, luego traerlo de la capa de datos, de lo contrario, usar el existente.

De esta manera, obtenemos tanto la capacidad de recrear por ID de usuario en caso de recreación de fragmentos por parte de Android como la facilidad para las acciones del usuario, así como la capacidad de crear fragmentos al mantener el objeto en sí o solo su ID

Algo le gusta esto:

public class UserFragment extends Fragment {
    public final static String USER_ID="user_id";
    private User user;
    private long userId;

    @Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        userId = getArguments().getLong(USER_ID);
        if(user==null){
            //
            // Recreating here user from user id(i.e requesting from your data model,
            // which could be services, direct request to rest, or data layer sitting
            // on application model
            //
             user = bringUser();
        }
    }

    public static UserFragment newInstance(User user, long user_id){
        UserFragment userFragment = new UserFragment();
        Bundle args = new Bundle();
        args.putLong(USER_ID,user_id);
        if(user!=null){
            userFragment.user=user;
        }
        userFragment.setArguments(args);
        return userFragment;

    }

    public static UserFragment newInstance(long user_id){
        return newInstance(null,user_id);
    }

    public static UserFragment newInstance(User user){
        return newInstance(user,user.id);
    }
}

usa este código 100% soluciona tu problema

ingrese este código en el primer fragmento

public static yourNameParentFragment newInstance() {

    Bundle args = new Bundle();
    args.putBoolean("yourKey",yourValue);
    YourFragment fragment = new YourFragment();
    fragment.setArguments(args);
    return fragment;
}

esta muestra envía datos booleanos

y en SecendFragment

yourNameParentFragment name =yourNameParentFragment.newInstance();
   Bundle bundle;
   bundle=sellDiamondFragments2.getArguments();
  boolean a= bundle.getBoolean("yourKey");

debe valor en el primer fragmento es estático

código feliz

La mejor manera de crear una instancia del fragmento es usar el método predeterminado Fragment.instantiate o crear un método de fábrica para crear una instancia del fragmento
Precaución: siempre cree un constructor vacío en otro fragmento mientras restaura la memoria del fragmento generará una excepción en tiempo de ejecución.

Últimamente estoy aquí. Pero algunas cosas que acabo de saber que podrían ayudarte un poco.

Si está utilizando Java, no hay mucho que cambiar. Pero para los desarrolladores de kotlin, aquí hay un fragmento de código siguiente que creo que puede convertirlo en un sótano para ejecutar:

• Fragmento principal:

inline fun <reified T : SampleFragment> newInstance(text: String): T {
    return T::class.java.newInstance().apply {
        arguments = Bundle().also { it.putString("key_text_arg", text) }
    }
}

• Llamada normal

val f: SampleFragment = SampleFragment.newInstance("ABC")
// or val f = SampleFragment.newInstance<SampleFragment>("ABC")

• Puede extender la operación de inicio principal en la clase de fragmento secundario mediante:

fun newInstance(): ChildSampleFragment {
    val child = UserProfileFragment.newInstance<ChildSampleFragment>("XYZ")
    // Do anything with the current initialized args bundle here
    // with child.arguments = ....
    return child
}

Feliz codificación

setArguments()es inútil Solo trae un desastre.

public class MyFragment extends Fragment {

    public String mTitle;
    public String mInitialTitle;

    public static MyFragment newInstance(String param1) {
        MyFragment f = new MyFragment();
        f.mInitialTitle = param1;
        f.mTitle = param1;
        return f;
    }

    @Override
    public void onSaveInstanceState(Bundle state) {
        state.putString("mInitialTitle", mInitialTitle);
        state.putString("mTitle", mTitle);
        super.onSaveInstanceState(state);
    }

    @Override
    public View onCreateView(LayoutInflater inflater, ViewGroup container, Bundle state) {
        if (state != null) {
            mInitialTitle = state.getString("mInitialTitle");
            mTitle = state.getString("mTitle");
        } 
        ...
    }
}

Creo que tengo una solución mucho más simple para esto.

public class MyFragment extends Fragment{

   private String mTitle;
   private List<MyObject> mObjects;

   public static MyFragment newInstance(String title, List<MyObject> objects)
   MyFragment myFrag = new MyFragment();
   myFrag.mTitle = title;
   myFrag.mObjects = objects;
   return myFrag;
   }