Awesome, great to hear people are jumping into it. :) For performance, the one thing to keep in mind is that each widget update will spin up your process, which is somewhat expensive. (So you probably want to avoid updating more often than once per hour to help save battery.) Also, while pushing bitmaps across RemoteViews is possible, it /is/ expensive. We experimented with pushing modified full-size album art to a larger desktop widget and started triggering ANRs in other foreground apps because it was so expensive.
One lightweight method to write a clock would be to use a combination of animated/leveled drawables. Using an example of a single digit from a base-10 clock, you might have something like this: <level-list xmlns:android="http://schemas.android.com/apk/res/ android"> <item android:maxLevel="0"> <animation-list xmlns:android="http://schemas.android.com/apk/ res/android" android:oneshot="false"> <item android:drawable="@drawable/digit0" android:duration="60000" /> <item android:drawable="@drawable/digit1" android:duration="60000" /> ... <item android:drawable="@drawable/digit9" android:duration="60000" /> </animation-list> </item> ... <item android:maxLevel="5"> <animation-list xmlns:android="http://schemas.android.com/apk/ res/android" android:oneshot="true"> <item android:drawable="@drawable/digit5" android:duration="60000" /> ... <item android:drawable="@drawable/digit9" android:duration="60000" /> </animation-list> </item> </level-list> Where the levels would be used when performing a clock update mid- cycle. Then, performing an exact update at an hour edge to start it down the full 0-9 repeating cycle. Each of the digits above lasts for a full minute before changing, so you would bump that to 600000ms for the minute 10's digit. And updating the hour digits manually each hour might work nicely. However, I'm not sure if it the animated drawable will correctly "catch up" if you leave the screen for a period of time, as it might continue the animation where you left off. Worth peeking into. :) > Also is there a way for thewidgetprovider to know (receive a hint > for) the size at which thewidgetwill be rendered? This is useful in > this instance since one doesn't want to make the bitmap any larger > than necessary. There isn't right now, but if you use drawables defined using <shape> instead of bitmaps, it should scale nicely. > A final question: is there a way for a provider to request that a > wedget be 'oversized' (like the search bar or media control)? When you say oversized, you mean filling multiple cells? Setting the minimum size should let you take up multiple cells. Here's a quick equation that should work: Minimum size in dip = (Number of cells * 74dip) - 2dip j --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
