rlottie: now loadFromData() api takes resourcePath for loading external resource

[smohantty]

#2

[hermet]

In API point of view, how about an static api to set global resource path?
It could be easier to use rather then setting resource path every time.
ex)
static rlottie::Config::defaultResPath("../res/lottie");
static rlottie::Animation::defaultResPath(...);
whatever default/global/(skip), Res/Resource, Path/Dir ...

And here resource path could be shared through lottie font, image, etc.

What do you think?

[smohantty]

i thought about the static api, the problem is this is a library and can be used by multiple client inside the same application . then if they have different resource path they will conflict with each other.(one will override other)

And because the resourcePath argument is default , most of time you don't have to specify resource path , if you don't have external resource.

so i think passing the argument in the api will give more flexibility .

[hermet]

As the ui app, multiple clients inside a same app? if multiple clients as multiple process, it doesn't any problems. If you mean multiple clients in a process, they must be packaged in one space. It means the process definitely needs share the resource and data (that's why they are using it). That case, it doesn't really need to have separate environments. We should consider convenient apis for the major scenario.

[smohantty]

For example, application has 2 lottie player instance one using the theme resource (for example through edc) and other one just set a file path from the system (it could haven from 2 different thread as well) . In that case how this will guarantee the last resource set is still valid .. someone else might change that .
Anyway static api that changes changes global data is always a bad idea (in a multi thread environment).
So i don't think there is any convenient about adding a static api . it will just add more subtle bugs .
Passing explicitly when needed is much cleaner approach in my opinion.

[hermet]

then go on please.