J'ai un écouteur de clic très simple dans mon fragment:
button?.setOnClickListener { val intent = Intent(MyActivity.createIntent(context!!)) // crash here because context is null startActivity(intent) }
Crashlytics montre que certains utilisateurs obtiennent des plantages de KotlinNullPointerException
lorsqu'ils cliquent sur ce bouton spécifique. Maintenant, je sais que le problème se produit parce que je suis obligé de déballer le contexte. Si je l'enveloppais simplement dans un nullcheck, cela ne planterait pas.
Mais je suppose qu'il y a un problème sous-jacent plus important dans mon code car je force toujours le déroulement du contexte lorsque j'en ai besoin et je n'ai de problèmes qu'avec cela morceau de code spécifique.
Quelle est la règle ici? Devrions-nous toujours vérifier notre contexte ou non?
3 Réponses :
À l'intérieur du bouton, vous pouvez facilement utiliser: view.getContext ()
pour obtenir le contexte ou dans Kotlin
button?.setOnClickListener { val intent = Intent(MyActivity.createIntent(it.context)) // this wont ever crash startActivity(intent) }
ie,
it.context // which will be never null
Très probablement, vous serez d'accord avec un code comme celui-ci
button?.setOnClickListener {startActivity(MyActivity.createIntent(it.context))}
Je crois que sur votre amusement My Activity.create Intent () vous renvoyez Intent
Si vous regardez le code source de la méthode fragment.getContext ()
, vous verrez:
view.setOnClickListener { it.context }
Ce qui signifie que getContext code> peut renvoyer
null
. En interne, mHost
représente un fragment Activity
auquel est attaché. Le fragment n'est pas toujours associé à son activité d'hébergement, vous pouvez l'observer en utilisant les rappels du cycle de vie onAttach
/ onDetach
.
Dans votre cas, comme déjà mentionné , la meilleure approche serait d'utiliser le contexte d'une View
@Nullable public Context getContext() { return mHost == null ? null : mHost.getContext(); }
Mais en général, vérifiez toujours les choses pouvant être nulles et ne faites pas !!
même si vous êtes sûr qu'il n'est pas null
. De cette manière, vous aurez moins de code sujet aux erreurs, offrant une autre façon de gérer null
s.