UIKit.UIProgressView supports four constructors:
public UIProgressView();
public UIProgressView(NSCoder coder);
public UIProgressView(CGRect frame);
public UIProgressView(UIProgressViewStyle style);
protected UIProgressView(NSObjectFlag t);
Currently BindableUIProgressView only exposes
public UIProgressView();
Enable more scenarios, such as UIProgressViewStyle.Bar
Going to leave this as a help wanted and good first issue. See https://github.com/unoplatform/uno/pull/1429 as an example of what needs to be done.
@ghuntley Can I work on this? already created a fork for my changes following the changes for #1429 . Is there any unit test case that I need to update?
Hello @ghuntley, @Niladri24dutta :wave:,
Thanks to the Uno team for open sourcing this platform.
It looks like there are a few places where surfacing some constructors would be useful. If @Niladri24dutta takes this issue, could you create new issues to track based on priority?
Welcome to Uno :wave: I'm chuffed to see two brand new faces to the project digging in and asking to help.
@Niladri24dutta I've assigned this issue to you. Dig in!
@anchepiece rather than open a GitHub issue and pull-request per control could you please instead batch them in a single pull-request?
Here's what you both gotta know, we don't require or need test coverage for src/Uno.UI/Controls/Bindable* as that crosses into the integration test territory and that isn't needed in this case because we trust that Xamarin iOS and Xamarin Android works.
On the topic of constructors it might be worth also reading https://github.com/unoplatform/workshops/tree/master/uno-bootcamp/modules/05-Native-intercompatibility#-native-constructors-are-automatically-provided and the impl of a consumer over at https://github.com/unoplatform/workshops/blob/master/uno-bootcamp/modules/05-Native-intercompatibility/TodoApp/TodoApp.Shared/Controls/NativeProgress.Droid.cs#L14
Anyway src/Uno.UI/Controls/Bindable* exists to make controls bindable from XAML that may not be bindable. A good example of this is with the iOS platform values often aren't exposed as properties and instead values are accessed by calling methods. Thus Bindable are shims. :-)
GitHub
workshops, study guides and learning materials for the Uno Platform - unoplatform/workshops
GitHub
workshops, study guides and learning materials for the Uno Platform - unoplatform/workshops
@ghuntley Thanks, pushed this work into the single pull referenced. Feedback and suggestions welcome.
@jeromelaban @ghuntley I am working on the UIProgressView . is this already done since the issue is closed ?
@Niladri24dutta Nope, UIProgressView was not included in the pull request. I suggest reopening this issue to track your changes.
@jeromelaban Can we return this to track the additional changes? Thanks!
Most helpful comment
Welcome to Uno :wave: I'm chuffed to see two brand new faces to the project digging in and asking to help.
@Niladri24dutta I've assigned this issue to you. Dig in!
@anchepiece rather than open a GitHub issue and pull-request per control could you please instead batch them in a single pull-request?
Here's what you both gotta know, we don't require or need test coverage for
src/Uno.UI/Controls/Bindable*as that crosses into the integration test territory and that isn't needed in this case because we trust that Xamarin iOS and Xamarin Android works.On the topic of constructors it might be worth also reading https://github.com/unoplatform/workshops/tree/master/uno-bootcamp/modules/05-Native-intercompatibility#-native-constructors-are-automatically-provided and the impl of a consumer over at https://github.com/unoplatform/workshops/blob/master/uno-bootcamp/modules/05-Native-intercompatibility/TodoApp/TodoApp.Shared/Controls/NativeProgress.Droid.cs#L14
Anyway
src/Uno.UI/Controls/Bindable*exists to make controls bindable from XAML that may not be bindable. A good example of this is with the iOS platform values often aren't exposed as properties and instead values are accessed by calling methods. Thus Bindable are shims. :-)