add support for loading DotLottieFile by name and filename synchronously #1968
Conversation
ilendemli
changed the title
| /// Decode the lottie. | ||
| let url = URL(fileURLWithPath: filepath) | ||
| let data = try Data(contentsOf: url) | ||
| let lottie = try DotLottieFile(data: data, filename: url.deletingPathExtension().lastPathComponent) |
There was a problem hiding this comment.
I don't think we should provide a synchronous method for loading DotLottie files. This initializer performs file system operations, like decompressing data to a temporary directly and reading various files. This would block the current thread, so we need to make sure we aren't making it too easy for folks to accidentally call this from the main thread.
One reason I think it's especially important to not provide synchronous loading methods for DotLottieFiles is because we do provide synchronous loading methods for LottieAnimations (which are less problematic to load on the main thread). If we provide synchronous methods for both I worry the difference would be too subtle.
|
@ilendemli, can you share more details about your use case here? Why do you want to load these files synchronously? Are you loading them on a background thread or on the main thread? Why can't you use the existing async methods? |
|
@calda In our case, when the app starts we show a static image of the first frame of the lottie animation as the launch screen. When the app is loaded into memory we show a splash screen which is basically the same as the launch screen but with the dotlottie loaded and animated. If we load the animation asynchronously then there is a white flash/screen until the dotlottie is loaded and displayed. I know this is blocking the main thread during the operation. But as it is during the startup process of the app, it's less noticeable. I would suggest to inform the user to use the asynchronous methods whenever possible, but in this (and a few other cases where we have to use dotlottie files) we have to use synchronous loading. |
|
Intentionally doing this on the main thread seems relatively uncommon and something I think we probably don't want to "officially" support for now. I'm open to reconsidering if we get more requests for this in the future, though. Have you explored using a something like a |
| /// Loads an DotLottie from a specific filepath synchronously. | ||
| /// - Parameter filepath: The absolute filepath of the lottie to load. EG "/User/Me/starAnimation.lottie" | ||
| /// - Parameter dotLottieCache: A cache for holding loaded lotties. Defaults to `LRUDotLottieCache.sharedCache`. Optional. | ||
| public static func loadedFrom( |
There was a problem hiding this comment.
I could also imagine being ok with merging this change if we give this method a more scary sounding name like:
| public static func loadedFrom( | |
| public static func loadSynchronouslyBlockingCurrentThread( |
with documentation explaining that this performs file system operations like decompressing a zip archive.
What do you think?
There was a problem hiding this comment.
I would be ok with this but how about using a SynchronouslyBlockingCurrentThread namespace instead?
Edit: see my latest commit.
Head branch was pushed to by a user without write access
We need to be able to load
dotLottiefiles synchronously in out project. This PR enables us to createDotLottieFiledirectly.Reference: #1967