Androidサポートライブラリ27、Fragment update？

Question

プロジェクトをSDKバージョン27に更新し、サポートライブラリのプラグインをバージョン27.0.0に変更したので、コードを変更する必要がありました。

26.1.0で、私はただで（Kotlin context付き）getContext()を使用することができ、私のFragment（android.support.v4.app）と私はNULL可能な問題を持っていないが、私はKotlinを使用するので、私はバージョン27.0.0に問題を持っている、すべての私のcontextの呼び出しはもう動作しませんでした、私はcontext!!のように、安全作業が必要でしたが、私は個人的に、すべての時間が、私はちょうど自分自身、私は機能を回避

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

なぜ変更が（突然、それがあることをもう一つ作っていること、行うにはハッスルであることがわかりましたので、尋ねる）方法はonCreateView()とです。 onCreateViewではインフレータがnullではない可能性がありますので、関数署名をonCreateView(inflater: LayoutInflater?...)からonCreateView(inflater: LayoutInflater...)に正しくオーバーライドし、createdViewのパラメータをonViewCreatedに正しく変更する必要がありました。

私はなぜ、特に（コトルのために）非常に醜いgetContext()の変更が行われ、https://developer.android.com/sdk/support_api_diff/27.0.0/changes.htmlに向かうのだろうと思っていました。

しかし、待って、明らかに彼らはそれを変更しませんでしたか？だから私の質問は、私が何か間違っているのか、本当にそれを変えたのか、もしそうなら私はなぜそれを尋ねるのだろうか？ところで

は、同じことが、私はmHost == nullチェックが追加されたと思いますが、getActivity()に適用されるとgetActivity方法でも、最終的なので、私はそれが非常に非常に醜いなりますが、私の回避策を使用することはできません。実際にソースファイルでは、メソッドは同じように見えますが、26.1.0にはKotlin戻り値タイプContext!と27.0.0戻り値タイプContext?があります。

Answer 1

これは意図的な変更です。このバージョンのサポートライブラリの前では、これらのクラスにはnull可否アノテーションはありませんでした。そのため、Kotlinからは、これらのタイプはすべてplatform typesでした。 27では、彼らは必要な注釈を追加しました。今ではこれらの型は、Kotlinでnullableかnon-nullableのどちらかとしてマークされています - nullであるかどうかを推測する必要はありません。あなたが言及した具体的な方法については

：FragmentがActivityに添付されていない場合、これらの方法は、すでにnullを返したため

• getActivityとgetContext方法はNULL可能なタイプを返します。動作の変更はありません。明示的にマークされているので、安全に処理できます。
• onCreateViewメソッドのinflaterパラメータがプラットフォームタイプであったため、nullableかどうかは、あなたが選んだかどうかにかかっていました。それはnullで決して呼び出されないので、@NonNullとして明示的に注釈が付けられているので、Kotlinの型は厳密には "looser" LayoutInflater!タイプの代わりにLayoutInflaterです。