-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Nullability Annotations to Java Classes] Replace findViewById
with ViewBinding
for History (relatively safe
)
#19172
[Nullability Annotations to Java Classes] Replace findViewById
with ViewBinding
for History (relatively safe
)
#19172
Conversation
This is done in order to avoid using the 'if (mBinding != null) { ... }' check everywhere and only use that where absolutely necessary, which usually is only needed when a 'binding' is required via an SDK related '@OverRide' method, that is, it being the 'binding' starting point. FYI: This way, when this class gets converted to Kotlin (in the future), instead of using the 'binding' as a parameter to a method, the same method will get converted to a 'binding' extension function, and then, everything will become much more straightforward. For what is worth, this pattern is already used as such with Kotlin classes. For example, see 'PreviewImageFragment.kt' class and its 'initializeViews()' extension function.
Warnings: - "'setHasOptionsMenu(boolean)' is deprecated" - "Overrides deprecated method in 'androidx.fragment.app.Fragment'" - "'androidx.fragment.app.FragmentStatePagerAdapter' is deprecated" - "'FragmentStatePagerAdapter(androidx.fragment.app.FragmentManager)' is deprecated "
Warning: "Inner class 'HistoryDetailFragmentAdapter' may be 'static'"
Warning: "Anonymous new Runnable() can be replaced with lambda"
FYI: 'nl-a' stands for 'nullable annotation'.
FYI: 'nl-a' stands for 'nullable annotation'.
📲 You can test the changes from this Pull Request in Jetpack by scanning the QR code below to install the corresponding build.
|
📲 You can test the changes from this Pull Request in WordPress by scanning the QR code below to install the corresponding build.
|
findViewById
with ViewBinding
for History (relatively safe
)findViewById
with ViewBinding
for History (relatively safe
)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the PR, @ParaskP7. I've tested WP and JP and everything is working as expected 🎉
I've left a small comment about the mBinding
null check. Please let me know if it makes sense.
resetOnPageChangeListener(); | ||
|
||
return rootView; | ||
return mBinding.getRoot(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
💡 We're checking if mBinding
is null
on line 115
but we're using it here without checking it. I wonder if we should do something here if mBinding
is null
(e.g. throwing an exception) or if we can just drop the null check in line 115
🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeaaa, and thanks for this comment @RenanLukas , ideally I would like to drop the null check on line 115
. Unfortunately, when I do that, for some reason, the IDE is warning us about it, I just doesn't understand that mBinding
is already set, just a few lines above: Dereference of 'mBinding' may produce 'NullPointerException'
Also, when I do that, that is, dropping the null check on line 115
, the IDE now starts warning us about line 163
, as expected, I don't know why it is warning us on that already, probably an IDE bug of some kind: Method invocation 'getRoot' may produce 'NullPointerException'
🤷 🤷 🤷
I ended-up choosing to throw an IllegalStateException
and guard the mBinding.getRoot()
call. Let me know what you think and again, thanks for this suggestion:
This is done here: 724f91b
This is done in order to include the 'mBinding.getRoot()' return within the 'mBinding' nullability check and avoid getting a NPE on it, just like it is already done for every 'mBinding' related call above. PR Comment: https://github.com/wordpress-mobile/WordPress-Android/ pull/19172#discussion_r1329379578
Thanks for reviewing and testing this @RenanLukas , much appreciated! 🙇 ❤️ 🚀 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for updating the PR, @ParaskP7. LGTM
Considering the PR instructions I'm going to merge it to trunk
.
Thank you for merging @RenanLukas ! 🙇 ❤️ 🚀 |
Parent #18906
This PR's main focus is to replace
findViewById
withViewBinding
for the HistoryDetailContainerFragment.java class.Additionally, this PR is also dealing with adding any missing nullability annotations to this fragment class, focusing mainly on its fields, and, any effected neighbour classes. But first, all existing warnings on this class are being resolved/suppressed so as to make it easier to deal with any missing nullability checks (with help from the IDE), especially when a
@Nullable
annotation is added.FYI: This change is
relatively safe
, meaning that although there are compile-time changes associated with this change, and it needs testing, the changes included in this PR are very targeted and specific to one screen, and one screen only. Thus, if this screen is tested appropriately, it should be safe to merge this totrunk
.PS: @RenanLukas I added you as the main reviewer, randomly so, since I just wanted someone from the Jetpack/WordPress mobile team to be aware of and sign-off on that change for JP/WPAndroid. Feel free to merge this PR directly yourself if you deem so.
findViewById
->ViewBinding
Nullability Annotation List:
Warnings Resolution List:
Warnings Suppression List:
To test:
History Details Screen [HistoryDetailContainerFragment.java]
ℹ️ This test applies to both, the
Jetpack
andWordPress
app.Posts
screen and tap on any post.top-right
) and tap onHistory
.History
screen, tap on any revision.History Details
screen is shown and functioning as expected.Regression Notes
Potential unintended areas of impact
What I did to test those areas of impact (or what existing automated tests I relied on)
To test
section above.What automated tests I added (or what prevented me from doing so)
PR submission checklist:
RELEASE-NOTES.txt
if necessary.UI Changes testing checklist: