Bug: animation doesn't execute if not called from main thread about kinetic

[u10int]

In iOS, you can't perform any UIKit/interface work on a thread other than the main thread. I don't want to automatically make this the default as it should be the responsibility of the implementation to ensure you're performing animations on the main thread if you happen to switch to a background one at any time.

[markuswinkler]

I can't really follow. If animations won't execute on a background thread and this library main purpose is to animate UI elements why would I ever switch to a background thread if it doesn't execute there (except the keypath one maybe)?
This is especially tricky if you have a onComplete handler you rely on that never gets executed.

[u10int]

Your original issue said that there was a bug b/c animations weren't executing when Kinetic methods weren't called from the main thread, but this is the default behavior in iOS. Anything related to UIKit and the interface must be done on the main thread, which is why you had to wrap your Kinetic animation within the dispatch_get_main_queue async block.

You may not have directly performed some action in a background thread, but it sounds like your code related to video permissions (or something else) ended up getting fired from a thread other than the main one if it wasn't executing. Without seeing additional code to gain more context it's difficult to say what exactly is happening in your code to get there.

My initial response is just saying that if you're code ends up switching to an alternate thread other than the main thread, then it should also be responsible for wrapping calls to Kinetic (UIKit) within an dispatch_async(dispatch_get_main_queue()) {} block as well when an animation should be performed.

[markuswinkler]

For me it's more an issue of "fire and forget", if I tell an animation to be executed it should just happen from anywhere without worrying about it at (especially since the syntax of dispatch_get_main_queue isn't really intuitive or short).
I am just trying to understand your push back since I am not familiar with threads but you are. Why wouldn't you want to always force run this on the main thread if it only can run there? Are there any implications performance or otherwise? Genuinely curious.

[u10int]

Main reason is I'd prefer to keep the expectation of how Kinetic performs animation similar to that of UIView.animate and CoreAnimation (and any other UIKit API), where they aren't automatically forced onto the main thread if you happen to call them on a background thread even though they require it. Not entirely sure if there performance implications without doing some testing, but there probably aren't any major ones. However, I don't think the occasional need for this justifies automatically applying it to every case.

Also with Swift 3.0, running code on different threads has been greatly improved and much less verbose, so dispatch_async(dispatch_get_main_queue()) {} would be replaced by: DispatchQueue.main.async {}, further reducing the need to bake that into the Kinetic methods.

[markuswinkler]

Good reason!
What do you think about adding this check to Kinetic? This way it would be really easy to spot if you try to run in error from a background thread.

if (NSThread.isMainThread() == false) {
    print("Warning. Kinetic can only execute on main thread.")
}

[u10int]

The main thread and the main queue aren't exactly the same as you can have multiple queues on the main thread, so NSThread.isMainThread() won't always work as other developers have noticed. However, it looks like there's a better, more recent GDC queue comparison check that works now that dispatch_get_current_queue () has been deprecated:

if dispatch_queue_get_label(dispatch_get_main_queue()) == dispatch_queue_get_label(DISPATCH_CURRENT_QUEUE_LABEL) { ... }

I think for now the best course of action is to keep this thread/queue stuff a responsibility of the implementation, but would be willing to revisit in the future if necessary.