Android support library 27、Fragment update？
プロジェクトをSDKバージョン27に更新し、サポートライブラリのgradleプラグインをバージョン_27.0.0_に更新したため、コードを変更する必要がありました。
_26.1.0_を使用すると、context（_Android.support.v4.app_）でgetContext()（Kotlin Fragmentを使用）だけを使用でき、nullabilityの問題はありませんが、Kotlinを使用するとバージョンに問題があります_27.0.0_、すべてのcontext呼び出しが機能しなくなったため、_context!!_のような安全演算子が必要でしたが、個人的には、関数を回避するたびにそれを行うのが面倒であることがわかりました
_override fun getContext() = super.getContext()!!
_変更されるもう1つのことは（突然、そしてそれが私が尋ねている理由です）メソッドonCreateView()とonViewCreated()です。 onCreateViewでは、インフレータはおそらくnullではないので、関数変数をonCreateView(inflater: LayoutInflater?...)からonCreateView(inflater: LayoutInflater...)に適切にオーバーライドするように変更する必要があり、createdViewのonViewCreatedパラメーターも同様です。
だから今、私はなぜ、特に（Kotlinにとって）非常にfunctionいgetContext()変更が行われ、 https://developer.Android.com/sdk/support_api_diff/27.0.0 /changes.html 。
しかし、彼らはそれを変更しなかったようです。だから今私の質問は、私が何か間違ったことをしているのか、彼らが本当にそれを変更したのか、そしてもしそうなら、なぜ彼らに尋ねるのか？
ちなみに、getActivity()にも同じことが当てはまります。_mHost == null_チェックが追加され、getActivityメソッドが最終的なものであると思うので、そこで回避策を使用することはできません。実際、ソースファイルではメソッドは同じように見えますが、_26.1.0_にはKotlin戻り値型_Context!_および_27.0.0_戻り値型_Context?_があります。
これらは意図的な変更でした。このバージョンのサポートライブラリの前は、これらのクラスにはnull可能性注釈がありませんでした。したがって、Kotlinからは、これらのタイプはすべて プラットフォームタイプ でした。 27では、必要な注釈が追加されたため、これらの型はKotlinでnull可能またはnull不可として明確にマークされます。nullにできるかどうかを推測する必要はありません。
あなたが言及した特定の方法に関して：
getActivityおよびgetContextメソッドは、FragmentがActivityに付加されていない場合、すでにnullを返しているため、null許容型を返します。動作に変更はありません。現在明示的にマークされているため、安全に処理できます。inflaterメソッドのonCreateViewパラメーターは、以前はプラットフォームタイプであったため、null可能としてマークするかどうかはユーザー次第でした。nullで呼び出されることはないため、@NonNullとして明示的に注釈が付けられているため、Kotlinでの型は、厳密には "looser"LayoutInflater!型ではなくLayoutInflaterです。
編集：サポートライブラリ27.1.0以降では、 requireActivity および requireContext メソッドを使用できます。これらのメソッドはnull不可の型を返し、通常のメソッドがIllegalStateExceptionを返すときにnullをスローすることに注意してください。