On Sun, Jan 15, 2012 at 2:44 AM, Dusk Jockeys Android Apps <[email protected]> wrote: > My point was more that although there is no explicit law requiring > home screens to support animations, from my reading of the CTD there > is also no explicit law requiring views in normal Activities to > support animations, but I think there would be a lot of complaints > from developers if those kind of animations suddenly stopped working > in the latest handsets.
You are writing your own activity. You are not writing the home screen. If you were to publish your RemoteViews to a non-home-screen activity of a third-party app, the same "anything goes" environment would apply. Could a device manufacturer change the Android framework such that no animations worked anywhere? Yes. That should fail the CTS, not necessarily the CDD. The CDD leans more towards hardware stuff. If it doesn't fail the CTS, that's a hole in the CTS. > But having said that I realise I am on shaky ground here... as we are > talking about homescreen apps which are not part of the framework per > se. More importantly, they are written by everyone from major device manufacturers to solo developers. > However, from the user's point of view (who I would guess in 99% > of cases use the Home screen which came with their phone), it is part > of the framework, they would naturally think it is due to that phones > implementation of Android, rather than understanding it is the Home > screen app itself. This is an issue of user education as much as anything. Don't get me wrong. IMHO, Samsung screwed up. I would think the same thing of any other home screen implementer with the same limitation, **unless such animation disabling was a specific feature of that home screen**. And that caveat is the rub. Just as you don't like it when home screen implementers block app widget layout animations, a home screen implementer would not like it if they were *forced* to display whatever a RemoteViews had in it. From Google's standpoint, it's a whack-a-mole situation -- one developer's solution becomes another developer's problem. This is reminiscent of developers complaining about how such-and-so IME does not honor certain android:inputType or android:imeOptions values. IME developers can do what they want, and users can choose what IME to run. Home screen developers can do what they want, and users can choose what home screen to run. We need to teach users that IMEs and home screens are replaceable, just as we needed to teach Windows users in 1995 that they could, indeed, run a different Web browser than IE. That will take time. -- Mark Murphy (a Commons Guy) http://commonsware.com | http://github.com/commonsguy http://commonsware.com/blog | http://twitter.com/commonsguy _The Busy Coder's Guide to Android Development_ Version 3.7 Available! -- 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
