Open MSDarwish2000 opened 4 months ago
Compose doesn't use the header magic bytes like the view code path but in the next release, it will check for file extension. Would that be sufficient for your use case? https://github.com/airbnb/lottie-android/pull/2488
Compose doesn't use the header magic bytes like the view code path but in the next release, it will check for file extension. Would that be sufficient for your use case? #2488
Thank you for your quick response. For me, this isn't sufficient as my Gzip files have no extensions. Actually, this PR was what I'm talking about.
Of course, migrating user data is possible, but it is more error prone than just supporting detecting the format using magic bytes or specifying the type explicitly. As a workaround, I can copy the LottieAnimation
and rememberLottieComposition
functions and force the type myself in case you prefer not implementing it.
Lottie is supported and developed on nights and weekends. Issues from Lottie sponsors will be prioritized.
Is your feature request related to a problem? Please describe. You have done great work, adding support for G-zipped animations, but this feature depends on file extension for content providers and file sources. This is good for most cases, but in some cases when dealing with data without extensions from external sources or pre-existing data where migration is hard, an alternative method may be needed.
Describe the solution you'd like One solution that won't introduce breaking changes would be using
isGzipCompressed
andisZipCompressed
which are already present in the codebase and used byRawRes
andAsset
. I think it is a better and foolproof detection method but may need early file probing.Describe alternatives you've considered Another method could be adding optional argument to each
LottieCompositionSpec
(exceptJsonString
of course), which allows users to explicitly specify the animation type.Additional context Not applicable