fluttie icon indicating copy to clipboard operation
fluttie copied to clipboard

Suggestion: Merge with lottie-flutter

Open MarkOSullivan94 opened this issue 5 years ago • 4 comments

I'm posting this suggestion on both repositories. I noticed in the official documentation for Lottie they include both fluttie and lottie-flutter with no information about the pros / cons of each.

I think it would be great if the two repositories could join together and have a really solid, highly tested lottie plugin for Flutter hosted within the Flutter Community organisation so contributors to both projects will get credit.

Hope you like this suggestion!

MarkOSullivan94 avatar Oct 18 '18 15:10 MarkOSullivan94

https://github.com/fabiomsr/lottie-flutter/issues/6

MarkOSullivan94 avatar Oct 18 '18 15:10 MarkOSullivan94

Hey, thanks for the suggestion. The scope of lottie-flutter is way bigger than the one of this repository: This one only works on Android and just pipes the output of the regular Lottie-Android library into a texture that is then displayed by Flutter. The lottie-flutter library (as far as I know) however is aiming at implementing lottie entirely in Dart, thus making it available on all platforms, having more control over how the animation will be shown and being more integrated with other Flutter widgets. The downside (at the moment, according to their readme) seems to be that some Skia APIs that would be needed aren't available to Dart yet and that the library doesn't support all Lottie features yet. Looking at these two approaches that are radically different from each other, I think that of the lottie-flutter library, once it's more polished, will be the best one to use, especially considering multi-platform availability. Personally, the main reason I started this library was that lottie-flutter didn't seem usable at that point and I didn't need iOS support. I don't know the current state of that project, but I think in the long-term, the best approach is to only use lottie-flutter and deprecate this library.

Long story short: Given that the implementation is completely different, merging both together doesn't seem beneficial to me. However, I'll watch this issue and the one on lottie-flutter and see if there are any good points that speak in favor of merging them together in the near-future. If it turns out to be a good idea, I certainly wouldn't mind it and would be glad to help in that process.

simolus3 avatar Oct 18 '18 16:10 simolus3

I also just realized that this fork already implements everything except for dashed paths, but also has dashed paths checked in it's todo list. @dnfield Can you please clarify whether that feature is already available? If it has feature-parity with the official Lottie for Android implementation, I'll try to figure out if I can turn this library into some abstraction layer that uses lottie-flutter internally so that existing users don't have to migrate their usages.

simolus3 avatar Oct 18 '18 16:10 simolus3

My fork of Lottie Flutter renders a good number of Lottie files correctly, however, I wouldn't quite regard it as production ready, for at least the following reasons:

  • I'm pretty sure there are issues with the widget structure wrt probably needing to be a little more sophisticated than just using a CustomPaint class.
  • We're not really caching any of the data we parse, and parsing is all pretty tightly coupled to rendering so it makes it hard to do that.
  • There is no implementation around fetching images for rendering (I'm pretty sure Android supports that, but not 100%).

I want to see Lottie work on Flutter, but I'm leaning more towards piecing together a solution involving more direct Skia usage than this - but there's a bigger backstory to make that work. That said, if you'd like to somehow merge these efforts I have nothing against that either.

dnfield avatar Oct 18 '18 17:10 dnfield