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 David Allison 12/09/2025, 04:53
• refactor: remove 'layout' from MultimediaFragment David Allison 12/09/2025, 02:51
• chore: convert MultimediaImageFragment to ViewBinding David Allison 12/09/2025, 02:49
• chore: convert DeckSelectionDialog to ViewBinding David Allison 12/09/2025, 02:33
• chore: convert BrowserColumnSelectionFragment to ViewBinding David Allison 12/09/2025, 02:26
• chore: convert FlagAdapter to ViewBinding David Allison 12/09/2025, 02:24
• chore: convert RepositionCardFragment to ViewBinding David Allison 12/09/2025, 01:55
• chore: convert FindAndReplaceDialogFragment to ViewBinding David Allison 12/09/2025, 01:47
• chore: convert ColumnSelectionDialogFragment to ViewBinding David Allison 12/09/2025, 01:42
• chore: convert ResizingDivider to ViewBinding David Allison 12/09/2025, 01:35
• chore: convert AboutFragment to ViewBinding David Allison 12/09/2025, 01:27
• chore: convert AudioRecordView to ViewBinding David Allison 12/09/2025, 01:20
• chore: convert MultiColumnViewHolder to ViewBinding David Allison 12/09/2025, 01:16
• chore: convert ControlPreferenceDialogFragment to ViewBinding David Allison 12/09/2025, 01:09
• chore: convert GesturePicker to ViewBinding David Allison 12/09/2025, 01:06
• chore: convert AlertDialogFacade to ViewBinding David Allison 12/09/2025, 01:02
• chore: convert TemplatePreviewerPage to ViewBinding David Allison 12/09/2025, 00:29
• ! chore: convert SettingsFragment to ViewBinding David Allison 12/09/2025, 00:24
• chore: convert KeyPicker to ViewBinding David Allison 12/09/2025, 00:18
• chore: convert MultimediaBottomSheet to ViewBinding #19620
• chore: convert AudioVideoFragment to ViewBinding David Allison 11/09/2025, 23:57
• chore: convert AudioRecordingFragment to ViewBinding David Allison 11/09/2025, 23:48
• 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
• refactor: remove unused layout from PermissionsFragment David Allison 11/09/2025, 01:08
• chore: convert AllPermissionsExplanationFragment to ViewBinding David Allison 12/09/2025, 02:40
• chore: convert PermissionsUntil29Fragment to ViewBinding David Allison 11/09/2025, 01:07
• chore: convert PermissionsStartingAt30Fragment to ViewBinding David Allison 11/09/2025, 01:06
• 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 David Allison 11/09/2025, 00:33
• 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 David Allison 10/09/2025, 22:41
• 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 David Allison 10/09/2025, 21:47
• 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 ?