Add View Binding

[Jatin887]

2026 update: Task List

• Audit adapter/ViewHolder usage: chore: convert GradeNowDialog to ViewBinding #19565 (comment)
• Remove the merge tag in toolbar.xml
  • it's not needed(we already have a single view as root and we don't append this included layout to a Toolbar view) and it also breaks ViewBinding(Missing required view with ID: com.ichi2.anki.debug:id/toolbar).
• architecture review: vendor 'vbpd' David Allison 18/09/2025, 14:50
• refactor: use BrowserColumnCellBinding #20188
• refactor: remove 'layout' from MultimediaFragment David Allison 12/09/2025, 02:51
• chore: convert MultimediaImageFragment to ViewBinding #20186
• chore: convert DeckSelectionDialog to ViewBinding #20185
• chore: convert BrowserColumnSelectionFragment to ViewBinding #20184
• chore: convert FlagAdapter to ViewBinding #20183
• chore: convert RepositionCardFragment to ViewBinding #20165
• Convert FindAndReplaceDialogFragment to ViewBinding #19940
• chore: convert ColumnSelectionDialogFragment to ViewBinding #20153
• chore: convert ResizingDivider to ViewBinding #20152
• chore: convert AboutFragment to ViewBinding #20151
• chore: convert AudioRecordView to ViewBinding #20150
• chore: convert MultiColumnViewHolder to ViewBinding #20149
• chore: convert ControlPreferenceDialogFragment to ViewBinding #20148
• chore: convert GesturePicker to ViewBinding #20139
• chore: convert AlertDialogFacade to ViewBinding #20138
• chore: convert TemplatePreviewerPage to ViewBinding David Allison 12/09/2025, 00:29
• chore: convert SettingsFragment to ViewBinding #20137
• chore: convert KeyPicker to ViewBinding #20135
• chore: convert MultimediaBottomSheet to ViewBinding #19620
• chore: convert AudioVideoFragment to ViewBinding #20134
• chore: convert AudioRecordingFragment to ViewBinding #20132
• chore: convert HelpDialog to ViewBinding #20083
• chore: convert AxisPicker; AxisSelector; GestureDisplay to ViewBinding  #19564
• chore: convert DeckPickerFloatingActionMenu to ViewBinding #20081
• chore: convert ScheduleRemindersAdapter to ViewBinding #20080
• chore: convert SharedDecksDownloadFragment to ViewBinding #20079
• chore: convert NoteTypesAdapter to ViewBinding #20076
• chore: convert TagLimitFragment & IncludedExcludedTagsAdapter to ViewBinding #20075
• refactor(custom-study): use userInputValue #20074
• CustomStudyDialog: 12ef705
• chore: convert SchedulerReminders to ViewBinding #20012
• WhiteboardFragment: 8e869ad
• chore: convert CheckPronunciationFragment to ViewBinding #20011
• chore: convert PreviewerFragment to ViewBinding #20010
• chore: convert ReviewerMenuView to ViewBinding #20009
• chore: convert ReviewerMenuSettingsFragment to ViewBinding #20008
• chore: convert ReviewerMenuSettingsAdapter to ViewBinding & document class #19621
• chore: convert AudioPlayView to ViewBinding #19900
• refactor: remove DeckDropDownAdapter #19899
• chore: convert TagsDialog to ViewBinding #19894
• chore: convert EditDeckDescriptionDialog to ViewBinding #19566
• chore: convert EmptyCardsDialogFragment to ViewBinding #19637
• chore: convert FlagRenameDialog to ViewBinding #19892
• chore: convert SavedBrowserSearchesDialogFragment to ViewBinding #19891
• chore: convert LocaleSelectionDialog to ViewBinding #19890
• chore: convert TtsVoicesDialogFragment to ViewBinding #19482
• chore: convert GradeNowDialog to ViewBinding #19565
• chore: convert BrowserOptionsDialog to ViewBinding #19591
• chore: convert ExportDialogFragment to ViewBinding #19889
• chore: convert BrowserColumnSelectionAdapter to ViewBinding #19608
• chore: convert NoteFieldAdapter to ViewBinding #19888
• chore: convert ImageCropper to ViewBinding #19708
• chore: convert ForgetCardsDialog to ViewBinding #19593
• chore: convert WidgetConfigScreenAdapter to ViewBinding #19707
• chore: convert TagsArrayAdapter to ViewBinding #19706
• chore: convert DeckAdapter.ViewHolder to ViewBinding #19705
• chore: convert MediaCheckFragment to ViewBinding #19568
• chore: convert AddNewNotesType to ViewBinding #19704
• chore: convert ReviewerFragment to ViewBinding #19496
• chore: convert FieldEditLine to ViewBinding #19567
• chore: convert SetDueDateDialog to ViewBinding  #19483
• chore: convert AllPermissionsExplanationFragment to ViewBinding #20202
• chore: convert PermissionsUntil29Fragment & PermissionsStartingAt30Fragment to ViewBinding #20201
• chore: convert PermissionsItem to ViewBinding #19525
• chore: convert SetupCollectionFragment to ViewBinding #19524
• ImageOcclusionBottomSheetFragment
  • Move Image Occlusion's "Camera" and "Gallery" out of "Select image" submenu #19396
• chore: convert TtsVoicesDialogFragment to ViewBinding #19482
• chore: convert InstantNoteEditorActivity to ViewBinding #20200
• chore: convert CardAnalysisWidgetConfig to ViewBinding #19523
• chore: convert DeckPickerWidgetConfig to ViewBinding #19522
• refactor: IntroductionActivity (ViewBinding) #19526
• chore: convert SharedDecksActivity to ViewBinding #19521
• chore: convert CardTemplateBrowserAppearanceEditor to ViewBinding #19511
• chore: convert TemplatePreviewerFragment to ViewBinding #19520
• chore: convert CardTemplateEditor to ViewBinding #19502
• chore: convert SingleFragmentActivity to be ViewBinding compatible #19501
• chore: convert AnkiDroidCrashReportDialog to ViewBinding #20199
• chore: convert Info to ViewBinding  #19471
• chore: convert Preferences to ViewBinding David Allison 10/09/2025, 22:27
• chore: convert MultimediaActivity to ViewBinding #19442
• chore: convert NoteTypeFieldEditor to ViewBinding #19440
• chore: convert PermissionsActivity to ViewBinding #20187
• chore: convert ManageNotetypes to ViewBinding #19439
• chore: convert CardBrowser to ViewBinding #19429
• chore: convert StudyOptionsFragment to ViewBinding David Allison 10/09/2025, 21:12
• chore: convert StudyOptionsActivity to ViewBinding #19428
• chore: convert DeckPicker to ViewBinding #19420
• chore: convert DrawingActivity to ViewBinding David Allison 10/09/2025, 18:57

Implement View Binding
Advantages of using it over findViewById
Null safety – Properties in the generated class are non-null. In the case of multiple layout versions, e.g. layout file for different screen orientation or size, if some configuration contains an id that is not present in others, the generated property will be nullable.
Type safety – Binding properties will be correctly typed, even with custom views.

Describe the solution you'd like
I will try to implement ViewiBinding for all activities and fragments.

Describe alternatives you've considered
This issue can be marked as good first issue so it will be helpful for new contributors. I will make a readme for this issue which have all the information about how to implement viewBinding for activities and fragments .

Additional context
Advantages
Interoperability – Generated classes are in Java and are optimized for Kotlin-Java interoperability.
Injection capability – Generated class can be injected in activity or fragment.
Speed – There are no impacts on build speed, as it doesn’t use an annotation processor. After the first build with View Binding is enabled, it will dynamically generate new properties. And if you add new view elements to your XML, there is no need to rebuild every time

[welcome]

Hello! 👋 Thanks for logging this issue. Please remember we are all volunteers here, so some patience may be required before we can get to the issue. Also remember that the fastest way to get resolution on an issue is to propose a change directly, https://github.com/ankidroid/Anki-Android/wiki/Contributing

[UvrajSB]

Why not go for data binding in case we are migrating to binding from findViewById, we can achieve several other objectives as well (if not currently then in near future for sure)

https://medium.com/geekculture/android-view-binding-v-s-data-binding-5862a27524e9

[Jatin887]

Why not go for data binding in case we are migrating to binding from findViewById, we can achieve several other objectives as well (if not currently then in near future for sure)

https://medium.com/geekculture/android-view-binding-v-s-data-binding-5862a27524e9

Yes, you are right. We can implement both depending on the project's needs. Because databinding isn't necessary in many activities, we can achieve better speed and fatter compilation by utilising viewbinding. However, databinding may undoubtedly be employed in more complex scenarios.

[david-allison]

View Binding: I'm concerned we've got a lot of work in the pipeline already, but I'd support this if someone were willing to estimate the time it will take and commit to seeing it through to completion. We've got 299 cases of findViewById, which is a fair amount of work, but it's feasible to switch easily for most activities. I don't think there are associated performance or stability costs.

Data Binding: likely not right now, we've already got a lot of architectural work in the pipeline, and it's a long commitment with downsides.

[puranjayK]

View Binding: I'm concerned we've got a lot of work in the pipeline already, but I'd support this if someone were willing to estimate the time it will take and commit to seeing it through to completion. We've got 299 cases of findViewById, which is a fair amount of work, but it's feasible to switch easily for most activities. I don't think there are associated performance or stability costs.

Data Binding: likely not right now, we've already got a lot of architectural work in the pipeline, and it's a long commitment with downsides.

We can start with shifting to view binding activity by activity/ fragment by fragment. This would allow multiple contributors to work on it and will split the work.
If we have to begin with this, I'll like to start with it.

[mikehardy]

View Binding: I'm concerned we've got a lot of work in the pipeline already, but I'd support this if someone were willing to estimate the time it will take and commit to seeing it through to completion. We've got 299 cases of findViewById, which is a fair amount of work, but it's feasible to switch easily for most activities. I don't think there are associated performance or stability costs.

Data Binding: likely not right now, we've already got a lot of architectural work in the pipeline, and it's a long commitment with downsides.

I agree with all of this - really want to see things completed not started, if that makes sense. Partially completed transitions are terrible as it means you've now got 2 things to maintain not one, it's worse then doing nothing.

Please if you start this, alter the description above to have a list (with checkboxes) for each of the files that need converting so that there is a real idea of how much work there is and we know when it is "done". Perhaps make a lint check that looks for the old usage and generates warning, and make a PR for that - we can periodically rebase the PR and see the current state. Then we know we can actually complete it

Thanks!

[Jatin887]

View Binding: I'm concerned we've got a lot of work in the pipeline already, but I'd support this if someone were willing to estimate the time it will take and commit to seeing it through to completion. We've got 299 cases of findViewById, which is a fair amount of work, but it's feasible to switch easily for most activities. I don't think there are associated performance or stability costs.

Data Binding: likely not right now, we've already got a lot of architectural work in the pipeline, and it's a long commitment with downsides.

Please assign this issue to me because I initiated it. I am happy to give as much of my time as possible.

[Jatin887]

View Binding: I'm concerned we've got a lot of work in the pipeline already, but I'd support this if someone were willing to estimate the time it will take and commit to seeing it through to completion. We've got 299 cases of findViewById, which is a fair amount of work, but it's feasible to switch easily for most activities. I don't think there are associated performance or stability costs.
Data Binding: likely not right now, we've already got a lot of architectural work in the pipeline, and it's a long commitment with downsides.

I agree with all of this - really want to see things completed not started, if that makes sense. Partially completed transitions are terrible as it means you've now got 2 things to maintain not one, it's worse then doing nothing.

Please if you start this, alter the description above to have a list (with checkboxes) for each of the files that need converting so that there is a real idea of how much work there is and we know when it is "done". Perhaps make a lint check that looks for the old usage and generates warning, and make a PR for that - we can periodically rebase the PR and see the current state. Then we know we can actually complete it

Thanks!

should i start working on this?

[david-allison]

I think we'd like to understand the amount of effort that this will take before we take this on.

Is this something that you can get a reasonable estimate for?

[Jatin887]

I think we'd like to understand the amount of effort that this will take before we take this on.

Is this something that you can get a reasonable estimate for?

1st approach
I think we can make this issue same as kotlin-cleanup where anyone can choose onefile and implement viewBinding for that.
2nd approach
I alone can work on this issue and i assure you that i will complete this approximately in a month
We can make a readme for the same which will help new contributers to understand viewBinding in the project.
We can make a lint check also.

[david-allison]

Could you elaborate on what's needed for completion in (2) and how long you expect each of these tasks will take. Ideally in "hours required". How confident are you in these estimates?

I expect most screens will be fairly easy, but some will require a lot more work (maybe testing, maybe not initializing in one place) and it would be useful to see a breakdown of what needs to occur

[Jatin887]

Could you elaborate on what's needed for completion in (2) and how long you expect each of these tasks will take. Ideally in "hours required". How confident are you in these estimates?

I expect most screens will be fairly easy, but some will require a lot more work (maybe testing, maybe not initializing in one place) and it would be useful to see a breakdown of what needs to occur

I will be start working on this issue and it will take approx 80-90 hours to complete it.

[david-allison]

What is involved in the 80-90 hours of work? Where will most of the effort go? What are the risky parts? Have you had experience with this before?

[Jatin887]

I'll start by going through each activity and fragment to see where the layout files are utilised, and then I'll move on to the activities that just have one layout file because they're easier to implement and test. Then I'll go on to more difficult activities that require many layout files to complete. Because I have to go through each and every layout file to find the specific use of the id, I believe this will be the most challenging and time consuming component. I'll keep the maintainers informed of my progress and ask questions if I get stuck. I've worked on a lot of projects that use viewBinding and have a lot of experience with it.

[ihrishix]

Can I work on this ?