Is it a normal practice to consider every parameter/variable coming from android framework nullable?...

# android

[aeruhxi]

Is it a normal practice to consider every parameter/variable coming from android framework nullable? I feel It's not ergonomic to deal with optionality everywhere even though some variables can never be null. Is there any cheeatsheet or anything I should read on to know which parameters can be null or not?

[gildor]

What do you mean “every parameter/variable”? Not all Android Framework API are nulalble, many of them are nullable, some non-nullable, but still most of them has platform type (Kotlin doesn’t know about nullability)

[gildor]

Maybe you can provide particular example of such case

[gildor]

any cheeatsheet or anything I should read on to know which parameters can be null or not?

Yes, for most cases Android API reference can provide such information
https://developer.android.com/reference/packages.html

[tateisu]

The source code of the recent Android SDK is now marked up as Nullable / NonNull, but Android Support Library is not yet. We have to be careful when overriding onActivityResult, onSaveInstanceState, etc., on AppCompatActivity.

[gildor]

Support Library has nullable annotations too, especially for version 27. And only very small part of Android Framework API is marked with nullability annotations (I may be wrong, but I don't see many annotations on AF)

[tateisu]

I use Support Library Revision 27.0.2 , at least it's AppCompatActivity is not markuped.

[gildor]

You can check sources of AppCompatActivity, there is a bunch of Nullable and NonNull annotations

[tateisu]

oh, you're right. The functions I mentioned were overridden from Framework's FragmentActivity. It was not a Nullable markup.