ActivityIndicator rendered as a ProgressRing in UWP

Currently ActivityIndicator is rendered as a ProgressBar in UWP (apparently this behavior is carried from WP 8 https://bugzilla.xamarin.com/show_bug.cgi?id=58651). This behavior makes the ActivityIndicator complicated to be used in many scenarios, as it is completely different in iOS and Android. If ProgressRing were used instead of ProgressBar to be rendered in UWP, the control would look much more homogeneous and it could be used in more scenarios.

0
0 votes

Open · Last Updated

Posts

  • ClintStLaurentClintStLaurent USUniversity ✭✭✭✭✭

    Devil's advocate:

    Xamarin leverages native UI as part of giving an app a native look and feel on each platform.
    On iOS it feels_like an iOS app. On Android your app _feels like an Android app with all the user-expected themeing and conventions.

    The goal of a Xamarin.Forms app is not to make an app look the same on all platforms. It is to use shared code across all platforms, while giving a native feeling experience.

    If you want to side-step that native experience, you can code that in your app. I don't think its the responsibility of the the eco-system to do that.

  • AlvaroRivoirAlvaroRivoir USMember ✭✭

    There is a native ProgressRing in UWP, which makes your argument void.

    If a user of Xamarin Forms users can't use controls and have more or less the same ui, it's impossible to build something decent. In the practice it isn't making the ui to feel native, it is making the ui to looks horrible.

    The XF advantage is to reuse the ui, but if a simple control like ActivityIndicator can't be reusable, forcing users to write the control again and implement everything from scratch, including a renderer per platform, how do you think this can be a good strategy for the platform? I'm ok XF giving a native feeling, but it also have to be easy to compose controls to create a ui, otherwise XF is only useful to build a hello world app.

  • ClintStLaurentClintStLaurent USUniversity ✭✭✭✭✭

    Currently ActivityIndicator is rendered as a ProgressBar in UWP

    I'm pretty sure that's OS version dependent. The current Windows ActivityIndicator is a horizontal line of dots that come in from the left and pass out on the right - not a progress bar.

    I could be wrong about this... but I'm fairly certain that is the 'busy' indicator for an up to date system. If you're saying it isn't I'd be curious enough to build up a new test solution just to test it out. I'm happy to prove myself wrong.

  • AlvaroRivoirAlvaroRivoir USMember ✭✭

    FYI the "horizontal line of dots that come in from the left and pass out on the right" is actually a ProgressBar in "Indeterminate" state.

    In iOS and Android, ActivityIndicator is showing a ProgressRing, not a ProgressBar. Fixing this is rather simple for you, makes complete sense for all the users, and it will continue feeling native.

    If you have doubts, I hope you can research about this. I'm sure you will conclude the same.

  • ClintStLaurentClintStLaurent USUniversity ✭✭✭✭✭

    Given the additional information from that last post - makes sense. Those details help. Thanks!

  • AlvaroRivoirAlvaroRivoir USMember ✭✭

    Awesome!

    To clarify a little more. One scenario which can help to understand why the current solution is not good is setting the ActivityIndicator a squared size, lets say 50x50 px, in iOS and Android the control renders perfectly fine, but in UWP it looks bad as the dots are crowded. This makes the control to be only usable in scenarios where the control takes the whole screen, but that's limiting the control to a very reduced number of scenarios unnecessarily, and forcing users to have to re-implement something that should work from the box.

    The proposed solution makes sense, feels native, and expands the control usability.

  • TorbjrnRosendahlTorbjrnRosendahl USMember ✭✭

    Hi @AlvaroRivoir,

    We have managed to use a ProgressRing ActivityIndicator through the following code:

    Create an empty custom ActivityIndicator that you can use in your XAML or codebehind:

    public class CustomActivityIndicator : ActivityIndicator
    {
    }
    

    And in the UWP project, create a custom renderer:

    using Windows.UI;
    using Windows.UI.Xaml.Controls;
    using Windows.UI.Xaml.Media;
    using Xamarin.Forms.Platform.UWP;
    
    [assembly: ExportRenderer(typeof(CustomActivityIndicator), typeof(CustomActivityIndicatorRenderer))]
    
    namespace WinUniversal.Renderers
    {
        public class CustomActivityIndicatorRenderer : ViewRenderer<CustomActivityIndicator, ProgressRing>
        {
            protected override void OnElementChanged(ElementChangedEventArgs<CustomActivityIndicator> e)
            {
                base.OnElementChanged(e);
                if (Control != null) { return; }
                var progressRing = new ProgressRing
                {
                    IsActive = true,
                    Visibility = Windows.UI.Xaml.Visibility.Visible,
                    IsEnabled = true,
                    Foreground = new SolidColorBrush(Color.FromArgb(255, 255, 255, 255)) // Set to your foreground colour
                };
                SetNativeControl(progressRing);
            }
        }
    }
    
  • AlvaroRivoirAlvaroRivoir USMember ✭✭
    @TorbjrnRosendahl thanks for the workaround, anyway the post is about fixing the current mistake. It doesn't make any sense any developer having to workaround a simple control that should work from the box.
  • TorbjrnRosendahlTorbjrnRosendahl USMember ✭✭

    Your welcome @AlvaroRivoir. Maybe useful to someone to know that there is a workaround :).

  • AlvaroRivoirAlvaroRivoir USMember ✭✭
    I agree. Thanks again.
  • MatthiasBruzekMatthiasBruzek USMember ✭✭

    Just leaving this here (MSDN Docs): https://docs.microsoft.com/en-us/windows/uwp/controls-and-patterns/progress-controls

    The recommendation for using a ProgressRing over an indeterminate ProgressBar is when the user is actually forced to wait, while a ProgressBar is usually just a hint that something is going on. Ideally there should be a platform-specific switch on the UWP side. Something like ActivityControl.On<UWP>().SetDisplayAsRing(true) but with better naming, I am really bad at this...

  • AlvaroRivoirAlvaroRivoir USMember ✭✭
    IMO Xamarin should provide both ActivityIndicator and ProgressBar as separate controls.
  • JoeMankeJoeManke USMember ✭✭✭

    @AlvaroRivoir said:
    IMO Xamarin should provide both ActivityIndicator and ProgressBar as separate controls.

    They do.

  • AlvaroRivoirAlvaroRivoir USMember ✭✭

    @JoeManke you are right. Thanks for clarifying.

Sign In or Register to comment.