Comments (23)
Few days ago there was JSON spec created for bodymovin, and I'm working on bringing it to JSON Schema — so it'll be possible in the future autogenerate parser source code.
from lottie-android.
our model classes are still somewhat coupled to the JSON structure, but over time we should decouple them as much as possible in a way that makes us input format agnostic. All you need is a converter that takes an InputStream
and outputs a LottieComposition
from lottie-android.
from lottie-android.
This is gonna require a fair amount of work to decouple JSONObject
from LottieComposition
.
I think first we should flatten the package structure into just com.airbnb.lottie
so you can keep everything package private and prevent from leaking classes to users (and avoid the @RestrictTo
annotation).
@gpeal if you agree with that, I could go ahead and break it down into multiple artifacts (java libs) for model, layers, animation, etc. That way we can keep each module small while maintaining everything under a single package.
That's sort of a pre-requisite change in order for us to be able to have pluggable json parsing implementations. What do you think?
from lottie-android.
@subtleGradient suggested using FlatBuffer. Tracking progress here.
from lottie-android.
@felipecsl That sounds like a good plan. Having better scope protection is also definitely good.
from lottie-android.
Alright, I'll start going down this path then :)
from lottie-android.
K p
from lottie-android.
@felipecsl did you start this? If not I'd like to contribute. I think the core of this is that a composition should be constructable via some conventional way (maybe a builder?). The default could basically be the current JSONObject implementations, with maybe some batteries-included optional artifacts that do it with gson/moshi/etc.
from lottie-android.
@hzsweers nope, I was waiting for @gpeal to finish some major JSON parsing refactoring that he had underway. AFAIK the plan was to move the current implementation to a streaming JsonReader
which should be more memory efficient. Not sure what's the status of that change though, @gpeal can help clarify
from lottie-android.
@felipecsl @hzsweers I spent quite a long time working on the JsonReader refactor which would have been a good end-all solution to this since it's strictly n time. However, there were some issues with the way the json was formatted that made it almost impossible to do proper parsing when only reading the json beginning to end linearly. Here is my WIP if you're interested: d7227b3
I synced up with Hernan on bodymovin about it and he made a few changes to the json that would make it more feasible:
airbnb/lottie-web@6ed7b0f
airbnb/lottie-web@18201cb
I want to give it another try but it would break compatibility with older versions so maybe splitting json parsing into a module and using the new one if you have a new animation would be a good idea and then we can drop support for older versions eventually.
@felipecsl Do you want to take another stab at this?
from lottie-android.
Sounds good to me, thanks for clarifying @gpeal.
@hzsweers I think we're on the same page about how it should work. I can probably work on it this week, we can sync offline on the details. How does that sound?
from lottie-android.
For reference, the longest and most complex json file, LottieLogo2.json (90kb) takes about 30ms to parse.
from lottie-android.
sounds good
from lottie-android.
Alright let me explain the rest of the changes I have in mind for this issue so I can get input from you guys before sending the PR:
We'd have a new class called Lottie
responsible for initializing the library state. It would have a builder where we could specific the desired Converter
implementation to use (similar to how Retrofit works). We could also use this in the future to configure other settings for the library:
Lottie lottie = new Lotite.Builder()
.converter(new DefaultJsonConverter())
.build()
Then, we'd need to use this lottie
object when loading animations so it knows which Converter implementation to use:
animationView.setAnimation(lottie, "hello-world.json");
We'd also move the current LottieComposition.Factory#fromJson()
, etc. APIs to Lottie#fromJson()
. That'd be the entry point for most operations.
LottieAnimationView
would use a default implementation of Lottie
when app:lottie_fileName
is used via XML since we wouldn't have the chance to initialize the Lottie
object properly. We'll have to find a way to cover that scenario by maybe initializing it via a singleton.
Finally, the different Converter
implementations would live in separate artifacts (also Android libraries). In order to use Lottie, you'd have to depend on the correct artifact, for example:
compile 'com.airbnb.android:lottie-converter-default:version'
The lottie-converter-default
artifact depends on lottie
so it would get the dependency transitively.
What do you guys think?
from lottie-android.
Looks good to me; but it's still unclear how will you manage model and logic separation. Also, it's interesting, whether it's possible to parse JSON with databinding; and to provide model automatically from JSON Schema. I wish I had enough time to contribute lot of stuff here
from lottie-android.
There is any advantage to use this new Lottie
class as a parameter of setAnimation
method and not as a parameter of LottieAnimationView's
constructor?
Using as a method parameter is useful if we need to use different JSON loaders with same LottieAnimationView
instance, but i don't see a situation where this will occur, and I need to define Lottie as a member variable of my class to use it every time I call setAnimation
.
A setSingletonInstance
method could be created, like Picasso, to configure the default behavior of Lottie
and use this singleton when a custom one is not specified in LottieAnimationView
constructor.
This will help when instantiating LottieAnimationView
from XML as you suggested.
from lottie-android.
@felipecsl I like the overall approach. What do you think about Lottie including the default parser as a transitive dependency so that a) LottieAnimationView can create the default one and b) users don't have to add a second dependency especially when, as of now, there is only one option
from lottie-android.
@gpeal that's not possible because it would cause a circular dependency.
@fabionuno we can't add Lottie
as a constructor paramterer to LottieAnimationView
because it needs to be instantiated from the XML
from lottie-android.
@felipecsl The idea was to have a new constructor with Lottie
as a parameter and when missing get the singleton instance, however in a situation where I declare the LottieAnimationView in XML but load the JSON animation programmatically, have it as parameter of the method setAnimation
is a better option.
from lottie-android.
@fabionuno Adding View constructors is pretty unconventional. We could also add something like what RV does with LayoutManager: https://developer.android.com/reference/android/support/v7/widget/RecyclerView.html#attr_android.support.v7.recyclerview:layoutManager
from lottie-android.
Should we close this issue? Not sure we're still planning to do anything else for this.
from lottie-android.
@felipecsl Let's close this for now.
from lottie-android.
Related Issues (20)
- Device compatibility issues
- ANR when using lottie 6.3.0 with compose 2024.01.00 HOT 1
- Kaycoins Organizations Cash@ and Personal app
- [Bug] Afterimage Persists in Android HOT 1
- App Crash with EOF error HOT 3
- App Crash with EOF error HOT 1
- Seeking Solutions: Lottie Animation Freezing Issue on Android 10 (Version 5.1.0) HOT 1
- Cache issue introduced in 6.3.0
- How to load lottie file from internal storage (compose) HOT 2
- How to replay the animation after a drawable resource is set to LottieAnimationView?
- Migrating Compose-BOM library to alpha version.
- Lottie-compose feature parity HOT 2
- Uncaught exception on Lottie that causes large canvas allocation HOT 1
- Binary incompatibility between 6.3.0 and 6.4.0 HOT 2
- java.lang.IllegalStateException: Missing values for keyframe.
- LottieAnimationView.duration returns 0 HOT 3
- Incorrect icon loading when manually selecting a dark or light theme HOT 1
- NullPointer crash problem
- [6.3.0] use compatible lottie resource but crash HOT 4
- Provide a Global Configuration to Default Cache Composition to Disabled HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from lottie-android.