> I'm assuming that the intention of the design is that I can grab a > AppWidgetManager instance for my application's context any time I want, so > that I can push an update to my gadgets.
Yep, exactly. If you already have a background service running for other updates, that's a perfect time to push an update. You can also mix the two together--have a requested update interval in your <appwidget-provider>, and push updates when you have special updates. > Combining these two thoughts, why not have updates triggered > by android:updatePeriodMillis only while the widget is visible? So we thought about this, and sometimes when you visit the home screen you might only be doing so for a few seconds, just to casually glance across your desktop. So instead of waiting until just that moment to trigger updates, and possibly showing "loading" or stale data while waiting for the updates to come back, we run the broadcasts in the background to have them always ready. Also, the RemoteViews for all widgets are cached in a backend system service, so even if Launcher gets restarted (say, transitioning back from a heavy browser session), we don't need to spin up all those processes for updates. If we only ran widget updates when on the home screen, this would make it easier to use low update intervals, such as every minute for a clock. But this would mean a user sitting at their home screen might see their battery drain much faster compared to having a random app open. j > 2009/4/15 Jeffrey Sharkey <jeffrey.shar...@gmail.com> >> >> 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 >> >> > > > > > -- Jeff Sharkey jshar...@google.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~----------~----~----~----~------~----~------~--~---
