[TIMOB-839] Implement Animations in Android

I'm not having much luck with opacity animations with latest git:

http://pastebin.com/xCMp7BbA">http://pastebin.com/xCMp7BbA

Unlike the iphone opacity=0 does not hide the view (it looks more like it's the same as opacity=1), so I have to add visible:false on creation, and if I don't set up a separate timer to set visible:false after the animation has finished, it will get stuck in a visible state.

Another issue is that if images with alpha channels are created in an invisible state, the background colour is not set correctly. If you comment out the visible:false lines you can see that the part surrounding the image is white as it should be, but in the code above, but in the code above it ends up as yellow for some reason.

(note that I had bottom:-30 in there as an alternative to hiding/showing the image, but it doesn't seem to make a difference)

In the meantime... is there a reason that the documentation gives no clue that things aren't implemented?

https://developer.appcelerator.com/apidoc/mobile/latest/Titanium.UI.Animation-object.html"> https://developer.appcelerator.com/apidoc/mobile/latest/Titanium.UI...

https://developer.appcelerator.com/apidoc/mobile/latest/Titanium.UI.Window.animate-method.html"> https://developer.appcelerator.com/apidoc/mobile/latest/Titanium.UI...

It would be HUGELY helpful just to know what is/isn't there...

It looks like rotation, scaling, and translation with 'transform' are sort of implemented on views (but not on windows at all, which may just be a system limitation due to how they map to activities).

In my testing though things seem pretty broken... translation always starts from a fixed point of (0, 0), while the end-point translate coordinates are relative to the anchor point. This means for instance that while you can translate your way sliding from regular screen position to off screen, you can't slide from off screen to regular position because you always start at the regular position.

To be compatible with the iPhone implementation, I believe it should be starting from the coordinates that were established by the previously-set transform property on the view...? (Or does it even work that way?)

Setting the transform property on a view appears to be implemented by starting an animation, and then not actually saving the transform. This at least is unintuitive, and doesn't seem to match how it works on iPhone.

It also looks like the 2DMatrix class doesn't implement a matrix at all, but stores separate values for translation, scaling, or rotation factors, which are then used to trigger particular types of animation modes. That may be just fine, but it's a bit confusing.

My initial testing of an animated translate on a view also showed really choppy animation (looked like it was chunking over like 20-30 pixels at a time on my Nexus 1, versus totally silky-smooth motion on an iPhone 3Gs). It might be faster in an isolated test case, though, the app view was a bit busy in context and other items like web views that were not being animated might have somehow slowed it down.

Don Thorpe asked me to post this, as a use case.

Good post, btw, Brion!

This problem is causing me a problem too. See the following code:

http://gist.github.com/569379">http://gist.github.com/569379
Arrowhead image available here:
http://img808.imageshack.us/img808/1225/taskbarmenuicon2.png">http://img808.imageshack.us/img808/1225/taskbarmenuicon2.png

This shows a graphical bar (a view) with an arrowhead image at one end to make it clear what is going on. When the arrowhead image is clicked, the bar should flip 180 degrees clockwise, and then when it is clicked again it should reverse the motion 180 anticlockwise to return to it's original position. And so on.

However, this demonstrates two issues:

1) As Brion explains, the second time the animation is activated (when the arrowhead is at the opposite end of the bar) the view resets to it's original position and then rotates it anti-clockwise. Obviously, this is not the desired effect, as explained above.

2) Although the EventListener is initially fired correctly, for the second animation it is in the original position, rather than where the image is now actually positioned on the other side of the bar.

(from [30f65b114bdcae3af7ffe50f7735d92db4194249]) expose all 4 to/from x/y values for the native ScaleAnimation, initial implementation of resize animation for android (this lays out on each frame, so may not be performant enough yet). also fixed a bug where animations would get created based on proxy properties instead of animation properties only. [#839] http://github.com/appcelerator/titanium_mobile/commit/30f65b114bdcae3af7ffe50f7735d92db4194249"> http://github.com/appcelerator/titanium_mobile/commit/30f65b114bdca...

Animations for Android have been implemented now, but there are still defects that need to be addressed. I'm marking this one as fixed, and we'll file separate bugs for the known defects.

As far as I can tell, the x and y properties of a view being animated are not exposed. You can test this by running the KS scripts https://github.com/appcelerator/titanium_mobile/blob/master/demos/KitchenSink/Resources/examples/basic_animation.js#L27"> basic_animation.js and https://github.com/appcelerator/titanium_mobile/blob/master/demos/KitchenSink/Resources/examples/animation_points.js#L46"> animation_points.js that result in a fatal exception at the lines in the links.

Titanium SDK version: 1.5.0 (12/01/10 09:30 ac7cfd8), Android 1.6/2.1, KS