I just started taking a closer look at what would be needed to make a well-functioning gadget and have an observation. 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. I've verified that this works by creating an Activity with a button that can be clicked to update a gadget. This means I can set up my own alarm if I want regular timed updates to my widget and don't need to use the android:updatePeriodMillis attribute.
I observe that there is no notification of when widgets become visible/invisible. I assume this is because you don't want to generate a storm of process creation each time home screen comes in/out of view. Somewhat surprisingly though, widgets appear to receive update notifications when they are not visible. Combining these two thoughts, why not have updates triggered by android:updatePeriodMillis only while the widget is visible? It would both reduce the number of broadcasts (and associated process launches), be useful for some gadgets to reduce the amount of work they need to do, and provide distinct functionality from the alarm notifications that are already available to widget providers via the AlarmManager. Just an idea. Tom. 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 > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
