We have some basics like opacity, but we need to support\nsizing/moving animations as well
I'm not having much luck with opacity animations with latest\ngit:
\n\nUnlike the iphone opacity=0 does not hide the view (it looks\nmore like it's the same as opacity=1), so I have to add\nvisible:false on creation, and if I don't set up a separate timer\nto set visible:false after the animation has finished, it will get\nstuck in a visible state.
\nAnother issue is that if images with alpha channels are created\nin an invisible state, the background colour is not set correctly.\nIf you comment out the visible:false lines you can see that the\npart surrounding the image is white as it should be, but in the\ncode above, but in the code above it ends up as yellow for some\nreason.
(note that I had bottom:-30 in there as an alternative to\nhiding/showing the image, but it doesn't seem to make a\ndifference)
In the meantime... is there a reason that the documentation\ngives no clue that things aren't implemented?
\n\nhttps://developer.appcelerator.com/apidoc/mobile/latest/Titanium.UI...
\n\nhttps://developer.appcelerator.com/apidoc/mobile/latest/Titanium.UI...
\nIt would be HUGELY helpful just to know what is/isn't\nthere...
It looks like rotation, scaling, and translation with\n'transform' are sort of implemented on views (but not on windows at\nall, which may just be a system limitation due to how they map to\nactivities).
\nIn my testing though things seem pretty broken... translation\nalways starts from a fixed point of (0, 0), while the end-point\ntranslate coordinates are relative to the anchor point. This means\nfor instance that while you can translate your way sliding from\nregular screen position to off screen, you can't slide from off\nscreen to regular position because you always start at the\nregular position.
\nTo be compatible with the iPhone implementation, I believe it\nshould be starting from the coordinates that were established by\nthe previously-set transform property on the view...? (Or does it\neven work that way?)
\nSetting the transform property on a view appears to be\nimplemented by starting an animation, and then not actually saving\nthe transform. This at least is unintuitive, and doesn't seem to\nmatch how it works on iPhone.
\nIt also looks like the 2DMatrix class doesn't implement a matrix\nat all, but stores separate values for translation, scaling, or\nrotation factors, which are then used to trigger particular types\nof animation modes. That may be just fine, but it's a bit\nconfusing.
\nMy initial testing of an animated translate on a view also\nshowed really choppy animation (looked like it was\nchunking over like 20-30 pixels at a time on my Nexus 1, versus\ntotally silky-smooth motion on an iPhone 3Gs). It might be faster\nin an isolated test case, though, the app view was a bit busy in\ncontext and other items like web views that were not being animated\nmight have somehow slowed it down.
Don Thorpe asked me to post this, as a use case.
\nGood post, btw, Brion!
\nThis problem is causing me a problem too. See the following\ncode:
\nhttp://gist.github.com/569379
\nArrowhead image available here:
\nhttp://img808.imageshack.us/img808/1225/taskbarmenuicon2.png
This shows a graphical bar (a view) with an arrowhead image at\none end to make it clear what is going on. When the arrowhead image\nis clicked, the bar should flip 180 degrees clockwise, and then\nwhen it is clicked again it should reverse the motion 180\nanticlockwise to return to it's original position. And so on.
\nHowever, this demonstrates two issues:
\n1) As Brion explains, the second time the animation is activated\n(when the arrowhead is at the opposite end of the bar) the view\nresets to it's original position and then rotates it\nanti-clockwise. Obviously, this is not the desired effect, as\nexplained above.
\n2) Although the EventListener is initially fired correctly, for\nthe second animation it is in the original position, rather than\nwhere the image is now actually positioned on the other side of the\nbar.
(from [30f65b114bdcae3af7ffe50f7735d92db4194249])\nexpose all 4 to/from x/y values for the native ScaleAnimation,\ninitial implementation of resize animation for android (this lays\nout on each frame, so may not be performant enough yet). also fixed\na bug where animations would get created based on proxy properties\ninstead of animation properties only. [#839]\n\nhttp://github.com/appcelerator/titanium_mobile/commit/30f65b114bdca...
Animations for Android have been implemented now, but there are\nstill defects that need to be addressed. I'm marking this one as\nfixed, 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\nanimated are not exposed. You can test this by running the KS\nscripts \nbasic_animation.js and \nanimation_points.js that result in a fatal exception at the\nlines in the links.
Titanium SDK version: 1.5.0 (12/01/10 09:30 ac7cfd8), Android\n1.6/2.1, KS
![http://img808.imageshack.us/img808/1225/taskbarmenuicon2.png](\n\"http://img808.imageshack.us/img808/1225/taskbarmenuicon2.png\"){kind=link}