Tengo un fragmento (F1) con un método público como este

public void asd() {
    if (getActivity() == null) {
        Log.d("yes","it is null");
    }
}

y sí, cuando lo llamo (de la Actividad), es nulo ...

FragmentTransaction transaction1 = getSupportFragmentManager().beginTransaction();
F1 f1 = new F1();
transaction1.replace(R.id.upperPart, f1);
transaction1.commit();
f1.asd();

Debe ser algo que estoy haciendo muy mal, pero no sé qué es eso

commit programa la transacción, es decir, no sucede de inmediato, pero está programada como trabajo en el hilo principal la próxima vez que el hilo principal esté listo.

Sugeriría agregar un

onAttach(Activity activity)

método Fragmenty poner un punto de interrupción y ver cuándo se llama en relación con su llamada a asd(). Verá que se llama después del método donde realiza la llamada a las asd()salidas. La onAttachllamada es donde Fragmentse adjunta a su actividad y desde este punto getActivity()devolverá no nulo (nb también hay una onDetach()llamada).

Lo mejor para deshacerse de esto es mantener la referencia de actividad cuando se llama a onAttach y usar la referencia de actividad donde sea necesario, por ejemplo

@Override
public void onAttach(Context context) {
    super.onAttach(activity);
    mContext = context;
}

@Override
public void onDetach() {
    super.onDetach();
    mContext = null;
}

Esto sucedió cuando llamas getActivity()a otro hilo que terminó después de que el fragmento ha sido eliminado. El caso típico es llamar getActivity()(por ejemplo, a Toast) cuando finaliza una solicitud HTTP ( onResponsepor ejemplo, en).

Para evitar esto, puede definir un nombre de campo mActivityy usarlo en lugar de getActivity(). Este campo se puede inicializar en el método onAttach () de Fragment de la siguiente manera:

@Override
public void onAttach(Context context) {
    super.onAttach(context);

    if (context instanceof Activity){
        mActivity =(Activity) context;
    }
}

En mis proyectos, generalmente defino una clase base para todos mis Fragmentos con esta característica:

public abstract class BaseFragment extends Fragment {

    protected FragmentActivity mActivity;

    @Override
public void onAttach(Context context) {
    super.onAttach(context);

    if (context instanceof Activity){
        mActivity =(Activity) context;
    }
}
}

Feliz codificación,

Las otras respuestas que sugieren mantener una referencia a la actividad en onAttach solo sugieren una venda al problema real. Cuando getActivity devuelve nulo, significa que el Fragmento no está adjunto a la Actividad. Lo más común es que esto ocurra cuando la Actividad se ha ido debido a la rotación o al final de la Actividad, pero el Fragmento todavía tiene algún tipo de escucha de devolución de llamada registrada. Cuando se llama al oyente si necesita hacer algo con la Actividad pero la Actividad se ha ido, no hay mucho que pueda hacer. En su código solo debe verificargetActivity() != nully si no está allí, no hagas nada. Si mantiene una referencia a la Actividad que se ha ido, está evitando que la Actividad se recolecte basura. El usuario no verá las cosas de la interfaz de usuario que intente hacer. Me imagino algunas situaciones en las que en el oyente de devolución de llamada es posible que desee tener un contexto para algo no relacionado con la interfaz de usuario, en esos casos, probablemente tenga más sentido obtener el contexto de la aplicación. Tenga en cuenta que la única razón por la que el onAttachtruco no es una gran pérdida de memoria es porque, normalmente, después de que se ejecuta la escucha de devolución de llamada, ya no será necesaria y se puede recolectar basura junto con el Fragmento, todas sus Vistas y el contexto de Actividad. Si tusetRetainInstance(true) existe una mayor posibilidad de una pérdida de memoria porque el campo Actividad también se retendrá, pero después de la rotación podría ser la Actividad anterior y no la actual.

Desde el nivel 23 de la API de Android, onAttach (Actividad de actividad) ha quedado en desuso. Debe usar onAttach (contexto de contexto). http://developer.android.com/reference/android/app/Fragment.html#onAttach(android.app.Activity)

La actividad es un contexto, por lo que si simplemente puede verificar el contexto, es una actividad y emitirla si es necesario.

@Override
public void onAttach(Context context) {
    super.onAttach(context);

    Activity a;

    if (context instanceof Activity){
        a=(Activity) context;
    }

}

PJL tiene razón. He usado su sugerencia y esto es lo que he hecho:

1. Variables globales definidas para el fragmento:

   private final Object attachingActivityLock = new Object();

   private boolean syncVariable = false;

2. implementado

@Override
public void onAttach(Activity activity) {
  super.onAttach(activity);
  synchronized (attachingActivityLock) {
      syncVariable = true;
      attachingActivityLock.notifyAll();
  }
}

3) Terminé mi función, donde necesito llamar a getActivity (), en thread, porque si se ejecutara en thread principal, bloquearía el thread con el paso 4. y onAttach () nunca sería llamado.

    Thread processImage = new Thread(new Runnable() {

        @Override
        public void run() {
            processImage();
        }
    });
    processImage.start();

4) en mi función donde necesito llamar a getActivity (), uso esto (antes de la llamada getActivity ())

    synchronized (attachingActivityLock) {
        while(!syncVariable){
            try {
                attachingActivityLock.wait();
            } catch (InterruptedException e) {
                // TODO Auto-generated catch block
                e.printStackTrace();
            }
        }
    }

Si tiene algunas actualizaciones de la interfaz de usuario, recuerde ejecutarlas en el hilo de la interfaz de usuario. Necesito actualizar ImgeView, así que hice:

image.post(new Runnable() {

    @Override
    public void run() {
        image.setImageBitmap(imageToShow);
    }
});

El orden en que se llaman las devoluciones de llamada después de commit ():

1. Cualquiera sea el método que llame manualmente justo después de commit ()
2. onAttach ()
3. onCreateView ()
4. onActivityCreated ()

Necesitaba hacer un trabajo que involucrara algunas vistas, por lo que onAttach () no funcionó para mí; se estrelló. Así que moví parte de mi código que estaba configurando algunos parámetros dentro de un método llamado justo después de commit () (1.), luego la otra parte del código que manejaba la vista dentro de onCreateView () (3.).

Estoy usando OkHttp y acabo de enfrentar este problema.

Para la primera parte, @thucnguyen estaba en el camino correcto .

Esto sucedió cuando llamas a getActivity () en otro hilo que terminó después de que el fragmento ha sido eliminado. El caso típico es llamar a getActivity () (por ejemplo, para un Toast) cuando finaliza una solicitud HTTP (en onResponse, por ejemplo).

Algunas llamadas HTTP se estaban ejecutando incluso después de que se cerró la actividad (porque puede llevar un tiempo completar una solicitud HTTP). Luego, a través del HttpCallbackintento de actualizar algunos campos Fragmento y obtuve una nullexcepción al intentarlo getActivity().

http.newCall(request).enqueue(new Callback(...
  onResponse(Call call, Response response) {
    ...
    getActivity().runOnUiThread(...) // <-- getActivity() was null when it had been destroyed already

En mi opinión, la solución es evitar que se produzcan devoluciones de llamada cuando el fragmento ya no está vivo (y eso no es solo con Okhttp).

La solución: prevención.

Si usted tiene una mirada en el ciclo de vida del fragmento (más información aquí ), usted notará que hay onAttach(Context context)y onDetach()métodos. Estos se llaman después de que el Fragmento pertenece a una actividad y justo antes de dejar de serlo, respectivamente.

Eso significa que podemos evitar que esa devolución de llamada suceda al controlarla en el onDetachmétodo.

@Override
public void onAttach(Context context) {
    super.onAttach(context);

    // Initialize HTTP we're going to use later.
    http = new OkHttpClient.Builder().build();
}

@Override
public void onDetach() {
    super.onDetach();

    // We don't want to receive any more information about the current HTTP calls after this point.
    // With Okhttp we can simply cancel the on-going ones (credits to https://github.com/square/okhttp/issues/2205#issuecomment-169363942).
    for (Call call : http.dispatcher().queuedCalls()) {
        call.cancel();
    }
    for (Call call : http.dispatcher().runningCalls()) {
        call.cancel();
    }
}

¿Dónde llamas a esta función? Si lo llama en el constructor de Fragment, volverá null.

Simplemente llame getActivity()cuando onCreateView()se ejecute el método .

Haz lo siguiente. Creo que te será útil.

private boolean isVisibleToUser = false;
private boolean isExecutedOnce = false;


@Override
public View onCreateView(LayoutInflater inflater, ViewGroup container, Bundle savedInstanceState) {
    View root = inflater.inflate(R.layout.fragment_my, container, false);
    if (isVisibleToUser && !isExecutedOnce) {
        executeWithActivity(getActivity());
    }
    return root;
}

@Override
public void setUserVisibleHint(boolean isVisibleToUser) {
    super.setUserVisibleHint(isVisibleToUser);
    this.isVisibleToUser = isVisibleToUser;
    if (isVisibleToUser && getActivity()!=null) {
        isExecutedOnce =true;
        executeWithActivity(getActivity());
    }
}


private void executeWithActivity(Activity activity){
    //Do what you have to do when page is loaded with activity

}

Aquellos que todavía tienen el problema con onAttach (Actividad de actividad), simplemente cambió a Contexto:

    @Override
public void onAttach(Context context) {
    super.onAttach(context);
    this.context = context;
}

En la mayoría de los casos, guardar el contexto será suficiente para usted; por ejemplo, si desea obtener getResources (), puede hacerlo directamente desde el contexto. Si aún necesita incluir el contexto en su Actividad, hágalo:

 @Override
public void onAttach(Context context) {
    super.onAttach(context);
    mActivity a; //Your activity class - will probably be a global var.
    if (context instanceof mActivity){
        a=(mActivity) context;
    }
}

Según lo sugerido por el usuario1868713.

Puede usar onAttach o si no desea poner onAttach en todas partes, puede poner un método que devuelva ApplicationContext en la clase principal de la aplicación:

public class App {
    ...  
    private static Context context;

    @Override
    public void onCreate() {
        super.onCreate();
        context = this;
    }

    public static Context getContext() {
        return context;
    }
    ...
}

Después de eso, puede reutilizarlo en todas partes en todo su proyecto, de esta manera:

App.getContext().getString(id)

Por favor, avíseme si esto no funciona para usted.

Otra buena solución sería usar LiveData de Android con la arquitectura MVVM. Definiría un objeto LiveData dentro de su ViewModel y lo observaría en su fragmento, y cuando se cambie el valor de LiveData, notificará a su observador (fragmento en este caso) solo si su fragmento está en estado activo, por lo que se garantizará que haría que su IU funcione y acceda a la actividad solo cuando su fragmento esté en estado activo. Esta es una ventaja que viene con LiveData

Por supuesto, cuando se hizo esta pregunta por primera vez, no había LiveData. Dejo esta respuesta aquí porque, como veo, todavía existe este problema y podría ser útil para alguien.

Llame al método getActivity () dentro de onActivityCreated ()