Dynamically download and load flare animation at runtime

[yuwen-yan]

Regarding current API, we always need to provide a Flare filename from the AssetBundle.

/// Name of the Flare file to be loaded from the AssetBundle.
final String filename;

But sometime, we'll have a lot of Flare animation to show, and don't want to including all of them in binary, instead we want to download it at runtime first, then show it later. So how to achieve it?

[jkurtw]

/cc @luigi-rosso

[luigi-rosso]

I posted this on our discord channel last week (we're working on getting this into our manual right now). Example code for this is here: https://github.com/luigi-rosso/flare_network_load

Hey sultan, definitely open to improving FlareActor to support network load, but it's already getting really bloated. FlareActor was originally meant to be an example implementation, instead it has become the widget that everyone uses. That's our fault for not documenting Flare well enough.
Here's an example of how easy it is to use existing functionality in both Flare and Flutter to create a widget that supports it. https://github.com/luigi-rosso/flare_network_load
GitHub
luigi-rosso/flare_network_load
Example for loading and displaying Flare files from the network. - luigi-rosso/flare_network_load

This could easily be extended to also load files from the AssetBundle without all the bloat for the many features of FlareActor. We want to encourage developers to learn the fundamentals of how Flare artboards are initialized (this example shows it pretty comprehensively) and how easy it is to build lightweight widgets that do what you need them to do without a jack of all trades widget.
Flare is the widget I created that encapsulates the network loading, FlareArtboard is the widget that displays that artboard (and controls it with a controller) once the artboard is loaded.
Both are very readable and short (~100 line) classes when compared to the FlareActor behemoth :slight_smile:

Let me know if you're looking for something even more specific, happy to provide further examples. I'll drop a line (and link) here when this is finally merged into our manual too.

[luigi-rosso]

It sounds like what you're trying to do is actually cache it locally after downloading it and then displaying it from that local cache. The example I linked above doesn't use a local cache, but it could be extended to support this. It'd be nice to integrate with a fully-fledged http caching library that honors etags, etc.

[yuwen-yan]

@luigi-rosso so sorry for missing this thread... (used to only check my working mailbox frequently). do we have ETA for this feature right now? may I know the API design (or WIP pull request link) for this new feature?

[yuwen-yan]

/cc @luigi-rosso , I just submitted a PR to support this feature, could you help review? thanks!

[luigi-rosso]

Wow awesome. Apologies for not seeing your reply back either. I’ll be looking into this today!

[luigi-rosso]

Got this merged into master via #214, thanks again for the contribution.

[yuwen-yan]

@luigi-rosso thanks! For NetworkFlare , I have implemented on my side, but I just find that I'm using a google internal package to download&cache flare, which I can't submit it to public project right now. I'm pushing internally to publish that package asap, will add NetworkFlare once it's available. Before that, I'd like to add MemoryFlare to follow [Image.memory], with this provider, we can at least download&cache flare data by ourselves and pass the data in memory to FlareActor directly.

[yuwen-yan]

Closing this issue for now as MemoryFlare is merged and we can download&cache flare data by ourselves and pass the data in memory to FlareActor directly.