Custom ActivityIndicator?

[nk-alex]

I've been trying to create my own ActivityIndicator. My approach has been to create a ContentView with a lottie animation on it:

<ContentView.Content>
  <Grid BackgroundColor="#CCFFFFFF">
    <Grid.RowDefinitions>
      <RowDefinition Height="*"/>
      <RowDefinition Height="200"/>
      <RowDefinition Height="*"/>
    </Grid.RowDefinitions>

    <Grid.ColumnDefinitions>
      <ColumnDefinition Width="*"/>
      <ColumnDefinition Width="200"/>
      <ColumnDefinition Width="*"/>
    </Grid.ColumnDefinitions>

    <skia:SKLottieView
      Grid.Row="1"
      Grid.Column="1"
      Source="loading.json"
      RepeatCount="-1"
      HeightRequest="200"
      WidthRequest="200"
      HorizontalOptions="Center" />
  </Grid>
</ContentView.Content>

The problem with this approach seems to be SKLottieView running on main thread, so if main thread is busy, I just get a freezed animation.

Is there any other approach I could use instead to achieve the ActivityIndicator behavior?

[wagenheimer]

Is there any update regarding this matter? Additionally, I was also considering utilizing LootieView as an option.

[mobilewares]

I've also had lots of problems with frozen/glitchy animated controls caused by threads being overworked. If you can get away with it (and you have suitable media) - you can actually use an animated gif (transparent supported too) with the regular Image control - and it doesn't get frozen at all no matter what is going on in the app/threads. There's a huge amount of good gif content available for this (ie. spinners/loading animations etc) as it's the most common approach used for websites. There was some issues in past with it not working on Release mode on Android but I think that's fixed now.

[ghost]

What is wrong with Controls.UserDialogs.Maui? From experience, it's very stable and good loking.

[stephenquan]

The question is flawed because one should never keep the main thread busy, as this leads to a poor user experience regardless of the activity indicator, busy animation, or similar visual cues. In a past project, I found unnecessary work on the UI thread. Refactoring to use the task pool improved performance and required developers to be more selective about scheduling work on the UI thread.

[nk-alex]

The original post describes a problem with ui thread blocking due to SKLottieView CoreAnimation Engine.
You are suggesting using UserDialogs.
You should be the one answering how UserDialogs is solving this issue, not me

[ghost]

Totally agree with you. My question was more about how to force **SKLottieView ** to run on different thread than UI. Or an alternative solution.
It's not. It is an alternative solution.

[nk-alex]

You should read (specially OP) for full context. My post is about running SKLottieView without getting a freezing animation (something like the default ActivityIndicator animation).
The answer you are pointing above was about running SKLottieView in a different thread than UI or alternative solution (alternative solution to avoid SKLottieView being freezed while UI is busy).

[ghost]

OK, my mistake then. I am sorry.

The only thing I came up with CoPilot help is to replace SKLottieVeiw with FFImageLoading. It works better then normal Image in MAUI, from my experience. Do not know if that helps.

[stephenquan]

If animations freeze, whether in SKLottieView, FFImageLoading, or ActivityIndicator, it's a sign that the UI thread is overloaded and not a fault in these components. The solution isn't to make those components work better, but to critically assess how your application uses the UI thread.