Fix LottieAnimationView.setProgress called from the view init method prevents the progress from being restored from the saved state

[flaringapp]

See #2069

[gpeal]

If you were to set an initial progress but then were to subsequently change it or play the animation, wouldn't restoration overwrite the saved progress with what is set in XML?

[flaringapp]

@gpeal I think it makes sense to check whether there is a progress attribute set in the XML and if yes - treat it as user-provided and prevent saved state restoration from overwriting the progress value.

Also it will be nice to provide an option to restore saved progress even if the progress is set in the XML. I suggest adding an attribute named lottie_useRestoredProgress with default value false. So if user wants to explicitly restore progress state instead of starting the animation from the specified progress, he can use this attribute. Behind the scenes it'll affect the setProgressInternal called from attributes init method. If the attribute is true, then we won't save the UserActionTaken.SET_PROGRESS flag (fromUser = false) or do exactly the opposite with default false value

[gpeal]

@flaringapp I'm still trying to wrap my head around the exact use case that's failing here. Could you create a sample project that highlights the issue?

[flaringapp]

@gpeal Please take a look at this sample project
In scope of this issue I expect the animation to persist it's previous progress when a fragment is restored

[gpeal]

Okay thanks for the sample. I've been very busy lately but found some time to take a look at this. let's move forward with your implementation as-is. Just swap the parameter order here but other than that, LGTM. Thanks for doing this.

[gpeal]

Could you swap the parameter order here?

[flaringapp]

@gpeal Done

[flaringapp]

I've rebased on master as well

[LottieSnapshotBot]

Snapshot Tests
28: Report Diff