web-dev-qa-db-fra.com

Android support library 27, Fragment update?

Depuis que j'ai mis à jour mon projet vers la version 27 du SDK et les plugins gradle pour la bibliothèque de support vers la version 27.0.0, J'ai dû changer mon code.

Avec 26.1.0 Je peux simplement utiliser getContext() (avec Kotlin context) dans mon Fragment (Android.support.v4.app) Et je n'ai aucun problème de nullité , mais depuis que j'utilise Kotlin, j'ai un problème avec la version 27.0.0, tous mes appels context ne fonctionnaient plus, j'avais besoin d'un opérateur de sécurité, comme context!!, mais comme je personnellement, je trouve que c'est difficile de le faire à chaque fois que je viens de me créer une fonction de contournement

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

Une autre chose qui change (soudainement et c'est pourquoi je demande) sont les méthodes onCreateView() et onViewCreated(). Dans onCreateView, le gonfleur n'est probablement plus nul, j'ai donc dû changer ma signature de fonction pour passer correctement de onCreateView(inflater: LayoutInflater?...) à onCreateView(inflater: LayoutInflater...) et la même chose pour createdView dans onViewCreated.

Alors maintenant, je me demandais pourquoi, en particulier le changement (pour Kotlin) très laid getContext() a été effectué et dirigé vers https://developer.Android.com/sdk/support_api_diff/27.0.0 /changes.html .

Mais attendez, apparemment, ils ne l'ont pas changé? Alors maintenant, ma question est de savoir si je fais quelque chose de mal ou s'ils l'ont vraiment changé et si oui, je pourrais leur demander pourquoi?

Par ailleurs, la même chose s'applique pour getActivity(), je pense que la vérification mHost == null A été ajoutée et la méthode getActivity est même définitive, donc je ne peux pas utiliser ma solution de contournement là-bas, ce qui c'est très très moche. En fait, dans les fichiers source, les méthodes se ressemblent, mais 26.1.0 A le type de retour Kotlin Context! Et 27.0.0 Le type de retour Context?.

androidandroid-fragmentskotlinandroid-support-libraryandroid-8.0-oreo
20
creativecreatorormaybenot

Il s'agissait de changements délibérés. Avant cette version de la bibliothèque de support, ces classes n'avaient pas d'annotations de nullité, donc de Kotlin, tous ces types étaient juste types de plate-forme . En 27, ils ont ajouté les annotations nécessaires, donc maintenant ces types sont définitivement marqués comme nullables ou non nullables dans Kotlin - il n'est pas nécessaire de deviner s'ils peuvent être null.

Quant aux méthodes spécifiques que vous avez mentionnées:

  • Les méthodes getActivity et getContext renvoient des types nullables car lorsque le Fragment n'est pas attaché à un Activity, ces méthodes ont déjà renvoyé null. Il n'y a pas de changement de comportement, il est maintenant explicitement marqué, vous pouvez donc le gérer en toute sécurité.
  • Le paramètre inflater de la méthode onCreateView était un type de plate-forme, donc c'était à vous de décider si vous l'aviez marqué ou non. Comme il ne sera jamais appelé avec null, il a été explicitement annoté comme @NonNull, donc son type dans Kotlin est maintenant strictement LayoutInflater au lieu du "plus lâche" LayoutInflater! type.

Edit: à partir de la bibliothèque de support 27.1.0, vous pouvez utiliser les méthodes requireActivity et requireContext , qui renvoient des types non nullables, avec la mise en garde qu'ils jetteront un IllegalStateException quand les méthodes régulières retourneraient null.

37
zsmb13