Library sometimes crashes when mRunningAnimationsManager is null internally about android_additive_animations HOT 6 CLOSED

Hi,

thanks for the report!

We've never experienced this crash in any of our apps – can you provide a small sample that produces the crash?
Are you using the latest version (1.9.0)?
It might also be related to how you create the animator, please show how you create and use the animator in your app.

from android_additive_animations.

Well, unfortunately it is not so easily reproducible, so I cannot provide you direct sample - it was reported over Crashlytics.

Some time ago I had an issue, when I used fadeVisibility and animate alpha on the same item, or on item and their parent - if I remember correctly this also caused crash.

I will get back to you if I found sample for that, but I wonder if this can be in any way secured?

from android_additive_animations.

Yes, there is indeed a crash when animating the same property multiple times for the same target while building the same animation.
I haven't fixed this yet since I wasn't sure what the expected behaviour should be (use the last or first enqueued value?), but the library really should at least log a proper error message for that case.

Animators are also not meant to be reused, so make sure you're not keeping any references to them after creation.
Another potential problem I can think of are infinitely repeating animations that are never removed.

Crashing outright is better than undefined behaviour imo, so I'm a little reluctant to add null-checks there.
Not executing the animation could leave your app in a bad state, where the UI and internal state don't match up anymore.
For example, users could tap on buttons that are meant to be gone, and that could lead to duplicate actions or more crashes down the line.

Have you ever experienced this crash yourself during development? How many of these crashes were reported in Crashlytics?
More info about the crashlytics report might help as well – Android Version, app state etc.

from android_additive_animations.

Hi,
so I tried looking into this and I'm having a hard time reproducing the issue.
The only explanation I can come up with is that you are calling the state method without having set a nonnull target – that's the only way the running animations manager can be null.

Do you build some animations in a dynamic way, where some of the targets could be null?
We've had a few issues with viewBindings that have become invalid after onDestroy, maybe that is something worth looking into on your end.

I still added a few more safety checks and the animator will now throw an exception if you don't set a target before adding animations.
I'll release 1.9.1 with these improvements soon (probably on the weekend).

Can I consider this ticket closed with these changes?

from android_additive_animations.

Hi,
Thanks for all responses.

We have an app where we basically build full custom UI, which is heavily based on your library - so we animate a lot of things.

Animators are not reused - as a fact, we have build small DSL for kotlin, which looks like that:

animate {

}

and which basically create Animator object before the block, and start the animation after.

We don't have the app deployed for the production yet, so the number of crashes cannot give good answer, about how often it happens.

The only explanation I can come up with is that you are calling the state method without having set a nonnull target – that's the only way the running animations manager can be null.

I don't really understand what you have in mind - can you elaborate?

Do you build some animations in a dynamic way, where some of the targets could be null?
We've had a few issues with viewBindings that have become invalid after onDestroy, maybe that is something worth looking into on your end.

Well, I will check that, but in that case I think it would be good to crash with the info that the target object cannot be null? :)

As for closing the ticket - I'm OK with that - will check both the new library and the target objects and reopen if I have more information, or replicable case.

Thanks again for all your work!

from android_additive_animations.

Hi,

1.9.1. has been released, and contains a few more null checks and better error messages!

I don't really understand what you have in mind - can you elaborate?

Sure, sorry if I was being unclear.
Basically, the only code path I could find where the crash you encountered could occur was if a null target had been set prior to calling the state method.
1.9.1 will now throw an IllegalStateException with an explanation message when this happens.

Btw, I would be very interested in seeing what you did with the Kotlin DSL, since I've thought about providing a better Kotlin API myself!

from android_additive_animations.