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

feat: added crate to manage .lotties #23

Merged
merged 21 commits into from
Jan 22, 2024
Merged

Conversation

samuelOsborne
Copy link
Member

No description provided.

Copy link

changeset-bot bot commented Jan 9, 2024

⚠️ No Changeset found

Latest commit: e07a70e

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

@samuelOsborne samuelOsborne force-pushed the feat/dotlottie-support branch 2 times, most recently from d73b9c4 to 6887648 Compare January 16, 2024 08:42
@samuelOsborne samuelOsborne marked this pull request as ready for review January 17, 2024 13:07
Copy link
Member

@theashraf theashraf left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • The demo player is no longer building.
image
  • I'm getting emcc link error with make all
image

} else if let Ok(animations) = manifest.animations.read() {
id = animations.index(0).id.clone();
} else {
panic!("No animations found in dotLottie file");
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's generally better to return an error instead of panicking as panics are not recoverable

Comment on lines 42 to 48
DotLottieManager {
current_animation_id: String::new(),
manifest: Manifest::new(),
zip_data: vec![],
animation_settings_cache: HashMap::new(),
animation_data_cache: HashMap::new(),
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if the new returns a Result, we can just propagate the error here.

} else if let Ok(animations) = manifest.animations.read() {
id = animations.index(0).id.clone();
} else {
panic!("No animations found in dotLottie file");
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

same as previous comment

self.zip_data = dotlottie;
}
Err(error) => {
eprintln!("Unable to initialize dotLottie manager: {}", error);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

same as previous comment

pub fn get_playback_settings(
&mut self,
animation_id: &str,
) -> Result<ManifestAnimation, DotLottieError> {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

from the implementation, i notice that the animation_id may not exists in the map and that would return an Error, while we should return a more appropriate value to the consumer.

Suggested change
) -> Result<ManifestAnimation, DotLottieError> {
) -> Result<Option<ManifestAnimation>, DotLottieError> {

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@theashraf if the animation_id isnt present we return an error, otherwise it will be there so we return a manifestAnimation, dont see why it needs to be an option in that case?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@samuelOsborne currently it doesn't return a manifestAnimation not found error, instead it returns a MutexLockError

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changed it to return AnimationNotFound if its not there

return self.load_animation_data(&animation_data, width, height);
}
Err(error) => {
eprintln!("Error: {:?}", error);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

same here

return self.load_animation_data(&animation_data, width, height);
}
Err(error) => {
eprintln!("Error: {:?}", error);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i don't think we should have any instances of println in our lib, we should either rely on Result or Option or ignore the error if it's not going to affect the flow

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll add bool returns so the frameworks can detect errors

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

things like setting values to the config doesnt need to return Result

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@samuelOsborne if we want the frameworks to detect errors then we have to change our exposed our API exposed to contain Result<T, Error>. i think that's the best approach, need to experiment how uniffi udl would look like and check if it's supported in the uniffi-cpp bindgen.

so this way all we need to do is just to propagate the errors up to the consumers.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@theashraf As this will require refactoring the other load functions, should we tackle in a separate PR?

Comment on lines 134 to 136
pub fn manifest(&self) -> Manifest {
self.dotlottie_manager.manifest()
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if a lottie json was loaded, the Manifest shouldn't exist, i think we should return an Option here

self.config.loop_animation = loop_animation;
}
Err(error) => {
eprintln!("Error: {:?}", error);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

same here

Comment on lines +8 to +11
zip_data: Vec<u8>,
animation_settings_cache: HashMap<String, ManifestAnimation>,
animation_data_cache: HashMap<String, String>,
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think both hash maps would hold the same keys, maybe we can combine both together in a single HashMap, where the value is a tuple ?

animations_map: HashMap<String, (ManifestAnimation, String)>

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what would the String in the tuple contain?

(ManifestAnimation, String)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@samuelOsborne it would contain the what this HashMap holds as a value animation_data_cache: HashMap<String, String>

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@theashraf Im going to create a ticket for this refactoring as at the moment having a single map containing both creates an endless loop inserting in to the map as both functions (getting playback setting, animation_data) will depend on each other

get an animationData -> needs to get the ManifestAnimation -> needs to get animation
get ManifestAnimation -> needs to get animationData -> needs to get ManifestAnimation

@theashraf theashraf merged commit 68201b4 into main Jan 22, 2024
1 check passed
@github-actions github-actions bot mentioned this pull request Jan 22, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants