java - DialogFragment getActivity() "podría ser nulo" aviso de pelusa en AndroidStudio 3.0.1

lint

Question

La pregunta más cercana que puedo encontrar respecto a esto son las advertencias de pelusas de Android Studio 3.0 para referencias a la actividad , pero no ayuda.

Usando AndroidStudio 3.0.1, tengo un DialogFragment donde hago estas cosas habituales:

 @Override
@NonNull
public Dialog onCreateDialog(Bundle savedInstanceState) {
AlertDialog.Builder builder = new AlertDialog.Builder(getActivity());
...

Tengo un aviso de pelusa que me gime que el Argument ''getActivity()'' might be null .

Entiendo por qué getActivity() puede ser nulo, y entiendo cómo la inspección de pelusa lo sabe (de la anotación @Nullable ).

Mi pregunta es: está muy bien que getActivity() sea ​​nulo, pero en la práctica, ¿cómo se supone que debo lidiar con esto de manera elegante y ordenada? onCreateDialog debe devolver un Dialog (debido a la superclase '' @Nullable anotación), así que debo tener el contexto de la Actividad para crearlo.

Podría suponer que nunca se llamará a DialogFragment si el DialogFragment no está adjuntado a una actividad, pero aún así, ¿cómo dirijo la advertencia de pelusa desordenada?

Answer 1

Este es un duplicado de las advertencias de pelusas de Android Studio 3.0 para las referencias a la actividad .

tldr; getActivity() obtuvo con Support lib 27.0.0 la anotación @Nullable y las herramientas de análisis estático lo recogen ahora.

Answer 2

Estos métodos se agregaron en la Versión 27.1.0: Los fragmentos ahora tienen los requireContext() , requireActivity() , requireHost() y requireFragmentManager() , que devuelven un objeto NonNull de los métodos equivalentes de obtención o lanzan una excepción IllegalStateException.

Answer 3

La respuesta de @Niklas explica por qué recibe esta advertencia ahora. Me gustaría compartir mis pensamientos sobre lo que realmente debería hacer.

En primer lugar, todo lo que hace esta nulabilidad agregada es exponer la deficiencia de diseño anterior que estuvo presente todos estos años; este método siempre podría devolver el valor nulo (por ejemplo, un fragmento desprendido).

Preferiría si anotaran el valor de retorno como @NonNull y lanzaran una excepción internamente si se llama a este método cuando la Actividad es realmente nula, pero entiendo que rompería la compatibilidad hacia atrás y, como tal, sería muy arriesgado (aunque apenas puedo ver por qué cualquiera llama a este método cuando la Actividad puede ser nula).

Entonces, ¿qué debemos hacer al respecto?

En primer lugar, ya que la funcionalidad no cambió en absoluto, si el código en cuestión ya funcionó, haga lo que sugirió @CommonsWare: suprimir la advertencia o ignorarla.

También puede ajustar cada llamada en cheque nulo con, por ejemplo, una excepción.

Sin embargo, lo que voy a hacer es poner este método en mi BaseDialog (que se extiende con todos los demás cuadros de diálogo):

protected FragmentActivity getActivityNonNull() {
if (super.getActivity() != null) {
return super.getActivity();
} else {
throw new RuntimeException("null returned from getActivity()");
}
}

Tenga en cuenta que todas estas opciones indican efectivamente que realmente no espera que se devuelva el valor nulo y está bien si la aplicación falla si eso sucede. Por eso dije que preferiría tener esto en el código de la biblioteca de soporte.

Editar:

Se agregó un nuevo método para admitir Fragmentos - requireActivity() . Este método es equivalente a getActivityNonNull() descrito anteriormente (aunque lanza la IllegalStateException si no se adjunta a la Actividad).

Use este método en lugar de getActivity() y debería ser bueno.