Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Android support library 27, Fragment update?

Tags:

Since I updated my project to SDK version 27 and gradle plugins for the support library to version 27.0.0 I needed to change my code.

With 26.1.0 I can just use getContext() (with Kotlin context) in my Fragment (android.support.v4.app) and I have no nullability issues, but since I use Kotlin I have a problem with version 27.0.0, all my context calls did not work anymore, I needed a safety operator, like context!!, but since I personally find it to be a hustle to do that every time I just made myself I workaround function

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

Another thing that change (suddenly and that is why I am asking) are the methods onCreateView() and onViewCreated(). In onCreateView the inflater is not possibly null anymore, so I needed to change my function signature to properly override from onCreateView(inflater: LayoutInflater?...) to onCreateView(inflater: LayoutInflater...) and the same for the createdView parameter in onViewCreated.

So now I was wondering why, especially the (for Kotlin) very ugly getContext() change was made and headed over to https://developer.android.com/sdk/support_api_diff/27.0.0/changes.html.

But wait, apparently they did not change it? So now my question is if I am doing something wrong or if they really changed it and if so I might ask them why?

By the way, same applies for getActivity(), I think the mHost == null check was added and the getActivity method is even final, so I cannot use my workaround there, which makes it very very ugly. Actually in the source files the methods look like the same, but 26.1.0 has Kotlin return type Context! and 27.0.0 return type Context?.

like image 543
creativecreatorormaybenot Avatar asked Nov 12 '17 15:11

creativecreatorormaybenot


1 Answers

These were deliberate changes. Before this version of the support library, these classes had no nullability annotations, so from Kotlin, all these types were just platform types. In 27, they added the necessary annotations, so now these types are definitely marked as either nullable or non-nullable in Kotlin - there's no need to guess whether they can be null.

As for the specific methods you've mentioned:

  • The getActivity and getContext methods return nullable types because when the Fragment is not attached to an Activity, these methods already returned null. There's no change in behaviour, it's just explicitly marked now, so you can safely handle it.
  • The inflater parameter of the onCreateView method used to be a platform type, so it was up to you whether you marked it nullable or not. Since it will never be called with null, it has been explicitly annotated as @NonNull, so its type in Kotlin now is strictly LayoutInflater instead of the "looser" LayoutInflater! type.

Edit: starting from support library 27.1.0, you can use the requireActivity and requireContext methods, which return non-nullable types, with the caveat that they'll throw an IllegalStateException when the regular methods would return null.

like image 144
zsmb13 Avatar answered Oct 13 '22 00:10

zsmb13