Skip to content

Fix ProgressBar binding hierarchy#45

Merged
colemancda merged 2 commits into
masterfrom
feature/progress-bar-binding
Jul 22, 2026
Merged

Fix ProgressBar binding hierarchy#45
colemancda merged 2 commits into
masterfrom
feature/progress-bar-binding

Conversation

@colemancda

Copy link
Copy Markdown
Member

android.widget.ProgressBar was bound as extending JavaObject rather than View, and declared no constructors — so it could not be instantiated, and could not be used anywhere a View is expected. That also affects everything below it in the hierarchy, since AbsSeekBar and SeekBar inherit from it.

Changes

  • ProgressBar now extends AndroidView.View, with the four standard view constructors and the AndroidContent/AndroidUtil/AndroidView imports that requires.
  • Methods it declares that are also declared on View are marked override. Same for AbsSeekBar.onRtlPropertiesChanged, which needs it once ProgressBar sits under View — without it the compiler reports cannot override more than one superclass declaration.

The constructor taking a style attribute matters in particular: ProgressBar's horizontal track is only selectable at construction time via android.R.attr.progressBarStyleHorizontal, so determinate progress is unreachable without it.

Verification

swift build --swift-sdk aarch64-unknown-linux-android28 completes on this branch.

Consumed downstream in AndroidSwiftUI#12, which renders ProgressView as a native progress bar and is blocked on this merging.

`ProgressBar` extended `JavaObject` rather than `View` and declared no
constructors, so it could not be instantiated or used as a view. Inherited
methods are marked as overrides accordingly.
@colemancda
colemancda merged commit dfa558b into master Jul 22, 2026
4 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant