Thanks Dianne, for such a detailed answer. I understand the limitations you describe, both of the Compatibility process and AppWidgets themselves.
The use case of animations here could be considered trivial, but I do think it adds tremendous perceived value to an app. Consider a simple Gallery widget, which toggles between a range of the users pre- selected images every few seconds. An alpha animation which fades in the new image instead of simply replacing it gives a lot of polish and wow factor. Without that animation, it still "works", as you point out, but in my particular case, the animations themselves are really part and parcel of my app, it being a Weather Widget which has the unique selling point of being fully animated. With the animation stripped out, the USP is lost. I guess it then comes down to where you draw the line on retaining functionality, from my point of view the animation is part of the functionality, as it is the raison d'etre of the app... As the animations are fully valid and supported by the SDK, I would argue that moving forward they should be a part of the CTS, notwithstanding the difficulty of actually testing that! But wouldn't that same difficultly be present testing that the particular implementation supported animations on normal views and layouts within Activities? I guess you are right and I just lucked out here, the full OpenGL Samsung homescreen sounds like the most likely root of the problem. I logged the issue with Samsung development team, and they reproduced it and marked it for further action in a future firmware, so let's hope that in ICS it is fixed in their homescreen. Anyway thanks again for taking the time to reply and for filing this for future investigation, I appreciate it. Regards, James Dusk Jockeys Android Apps http://duskjockeys.blogspot.com/ On Jan 14, 2:11 am, Dianne Hackborn <[email protected]> wrote: > On Fri, Jan 13, 2012 at 5:13 AM, Dusk Jockeys Android Apps < > > [email protected]> wrote: > > Thanks Dianne, for this infomation on Compatibility Testing. > > > Couuld you clarify the exact scope? Is it the devices core API that > > have to pass or their implementation of it? > > It is everything covered in the CTS tests. These test public APIs amongst > other things. > > > On the latest Samsung Tablets (e.g. Tab 7 Plus) the LayoutAnimation on > > AppWidgets doesn't work in their TouchWiz homescreen. From the log cat > > it seems they are deliberately stripping them out. > > This works perfectly in AppWidgets in the emulator from all APIs since > > 1.5, and on most other realworld devices. > > However, if I install another Homescreen app on the Tablet such as Go > > Launcher, the AppWidgets are fine and display the LayoutAnimations > > correctly. > > Hm, that is certainly unfortunate. I can imagine good reasons for this -- > for example if their home screen is all implemented in OpenGL, they would > need to render the app widgets into a separate texture and draw them to the > screen with that. This would make executing animations and such in them > pretty problematic. I'll file an issue for this to have it investigated. > > > So it their Touchwiz homescreen covered by the CTS, or do they pass > > because their underlying Android implementation supports it, as shown > > by Go Launcher, and it is just my tough luck that their particular > > Home Screen is not fully featured? > > Well to be honest it is hard for CTS specifically to cover this kind of > thing, because it is pretty unclear how to write an API unit test that is > able to verify that some other application is performing the animation on > the screen. > > However, the overall CDD covers a lot of things -- for example if you look > athttp://static.googleusercontent.com/external_content/untrusted_dlcp/s... > there > is section 3.8.1 on app widgets, with the relevant requirement being: > > "Device implementations MAY substitute an alternative to the reference > Launcher (i.e. home screen). Alternative > Launchers SHOULD include built-in support for AppWidgets, and expose user > interface affordances to add, > configure, view, and remove AppWidgets directly within the > Launcher.Alternative Launchers MAY omit these user > interface elements; however, if they are omitted, the device implementation > MUST provide a separate application > accessible from the Launcher that allows users to add, configure, view, and > remove AppWidgets. > Device implementations must be capable of rendering widgets that are 4 x 4 > in the standard grid size. (See the App > Widget Design Guidelines in the Android SDK documentation [Resources, 18] > for details." > > So I think technically right now there is nothing wrong with not showing > animations, as long as the app widget is still functional. It is worth > considering whether this requirement should be more specific... though to > be honest, this may just become irrelevant since with 4.0 the UI is all > hardware accelerated so there would be little benefit anymore to use OpenGL > to implement launcher (if that is what they are doing), and they would need > to support the much more interactive app widgets that were added in 3.0 > which makes just running animations look trivial. > > App widgets are also an interesting topic because there is a certain amount > of control over them you just need to assume you don't have. What you are > doing is offering up a specification to another application of some UI to > show embedded in it. The other application is allowed to have a fair > amount of flexibility in how it displays this, to provide an integrated > experience in its UI. So there is a lack of control that both sides need > to expect -- the hosting app has many limitations on assumptions it can > make about the app widget, and the app widget itself needs to accept that > it is not 100% in control in that it can change in non-breaking ways across > different containers. > > Whether or not running animations is a breaking change... at first glance > I would say it is not, since the functionality is still retained. > > -- > Dianne Hackborn > Android framework engineer > [email protected] > > Note: please don't send private questions to me, as I don't have time to > provide private support, and so won't reply to such e-mails. All such > questions should be posted on public forums, where I and others can see and > answer them. -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
