Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide a Global Configuration to Default Cache Composition to Disabled #2485

Closed
rluick15 opened this issue Mar 28, 2024 · 10 comments
Closed

Comments

@rluick15
Copy link

Is your feature request related to a problem? Please describe.
Currently Lottie animations are cached by default and it is required to add the app:lottie_cacheComposition="false" flag in the xml on a per LottieAnimationView basis. This is a fairly easy thing to miss in cases where we do not desire a cache which can lead to large animations remaining in memory when we do not need them to be.

Describe the solution you'd like
Ideally this could be solved by a simple boolean field on the LottieConfig class to indicate if we want to globally default the cacheComposition value to false.

Describe alternatives you've considered
The only other alternative I see is to use LottieCompositionFactory.setMaxCacheSize and set it to 0 which totally disables the cache. While this may work for some, this does not work in cases where we want to selectively cache specific animations while not caching the majority of them.

Other future iterations could be a cap on memory size for the cache or maybe a configuration to only cache animations under a specific size.

@gpeal
Copy link
Collaborator

gpeal commented Apr 1, 2024

How would you imagine the API would look?

boolean field on the LottieConfig class to indicate if we want to globally default the cacheComposition value to false.

On the surface, your proposal sounds very similar to setting the max cache size to 0.

@gpeal
Copy link
Collaborator

gpeal commented Aug 2, 2024

@rluick15 bump

@rluick15
Copy link
Author

rluick15 commented Aug 5, 2024

@gpeal apologies for missing your first comment there.

So my understanding is that setting the max cache size to 0 would effectively disable the cache here, which is not what I am looking to do.

What I am looking to do is be able to globally default caching specific animations to false and instead opt into caching them as desired. What we have today is the opposite, we are automatically opted in and have to opt out on a case by case basis. It would be nice to be able to configure this globally.

@gpeal
Copy link
Collaborator

gpeal commented Aug 5, 2024

@rluick15 Out of curiosity, what is the use case?

@rluick15
Copy link
Author

rluick15 commented Aug 5, 2024

@gpeal The use case here is that due to memory constraints we want to only selectively cache lottie animations that we use more often. Otherwise we want the caching disabled by default.

@gpeal
Copy link
Collaborator

gpeal commented Aug 5, 2024

@rluick15 One option here would be to make your own class that extends LottieAnimationView which sets cacheComposition to false and then lets you selectively enable it per your requirements. Would that work?

@rluick15
Copy link
Author

rluick15 commented Aug 5, 2024

@gpeal Sure, something like that would work though I feel that isn't so much better than adding the existing xml attribute for each usage. I still believe this is something that would be nice to have as a global configuration.

@gpeal
Copy link
Collaborator

gpeal commented Aug 5, 2024

@rluick15 My main concern is over-complicating the public API. cacheComposition is a boolean and adding another could get it into a state where you have ambiguous and conflicting attributes.

For the most part, LottieAnimationView is mostly in maintenance mode in favor of Jetpack Compose at this point as well.

@rluick15
Copy link
Author

rluick15 commented Aug 6, 2024

@gpeal That is fair enough, we are mostly using compose for newer things but could benefit from this for some legacy flows. However, this is not anything major from us, just a suggestion we had after running into this

@gpeal
Copy link
Collaborator

gpeal commented Aug 6, 2024

@rluick15 It's a reasonable suggestion but I think it's best done within your app at this time.

@gpeal gpeal closed this as completed Aug 6, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants