studio - Biblioteca de soporte de Android 27, ¿Actualización de fragmentos?

service on android oreo

Question

Desde que actualicé mi proyecto a SDK versión 27 y los complementos de gradle para la biblioteca de soporte a la versión 27.0.0 necesitaba cambiar mi código.

Con 26.1.0 solo puedo usar getContext() (con el context Kotlin) en mi Fragment ( android.support.v4.app ) y no tengo problemas de nulabilidad, pero como uso Kotlin tengo un problema con la versión 27.0.0 , todas mis llamadas de context ya no funcionaban, necesitaba un operador de seguridad, como context!! , pero como personalmente me parece una tarea difícil hacerlo cada vez que me hago una función alternativa

override fun getContext() = super.getContext()!!

Otra cosa que cambia (de repente y es por eso que pregunto) son los métodos onCreateView() y onViewCreated() . En onCreateView el inflateral ya no es nulo, así que tuve que cambiar la firma de mi función para anularlo correctamente desde onCreateView(inflater: LayoutInflater?...) a onCreateView(inflater: LayoutInflater...) y lo mismo para el parámetro createdView en onViewCreated .

Así que ahora me preguntaba por qué, especialmente el cambio getContext() muy feo (para Kotlin) se realizó y se dirigió a https://developer.android.com/sdk/support_api_diff/27.0.0/changes.html .

Pero espera, ¿al parecer no lo cambiaron? Así que ahora mi pregunta es si estoy haciendo algo mal o si realmente lo cambiaron, y si es así, les podría preguntar por qué.

Por cierto, lo mismo se aplica a getActivity() , creo que se agregó mHost == null check y que el método getActivity es incluso definitivo, por lo que no puedo usar mi solución allí, lo que lo hace muy feo. En realidad, en los archivos de origen, los métodos se ven iguales, pero 26.1.0 tiene el tipo de retorno de Kotlin Context! y 27.0.0 tipo de retorno Context? .

Answer 1

Estos fueron cambios deliberados. Antes de esta versión de la biblioteca de soporte, estas clases no tenían anotaciones de nulabilidad, por lo que desde Kotlin, todos estos tipos eran solo tipos de plataforma . En 27, agregaron las anotaciones necesarias, por lo que ahora estos tipos están marcados definitivamente como anulables o no anulables en Kotlin; no es necesario adivinar si pueden ser null .

En cuanto a los métodos específicos que has mencionado:

• Los métodos getActivity y getContext devuelven tipos anulables porque cuando el Fragment no se adjunta a una Activity , estos métodos ya devolvieron un null . No hay cambios en el comportamiento, solo está explícitamente marcado ahora, para que pueda manejarlo de manera segura.
• El parámetro onCreateView método onCreateView solía ser un tipo de plataforma, por lo que depende de usted si lo marcó como nullable o no. Dado que nunca se llamará con null , se ha anotado explícitamente como @NonNull , por lo que su tipo en Kotlin ahora es estrictamente LayoutInflater lugar del LayoutInflater "más suelto" LayoutInflater! tipo.

Edición: a partir de la biblioteca de soporte 27.1.0, puede utilizar los métodos requireActivity y requireContext , que devuelven tipos no anulables, con la advertencia de que lanzarán una IllegalStateException cuando los métodos normales devuelvan el null .