Your entire question is phrased around "the Widget". There is no "the Widget". From the opening sentence of your question, I am interpreting "the Widget" to mean "a subclass of AppWidgetProvider that handles the processing for an app widget or family of app widget instances".
On Sat, Feb 12, 2011 at 5:42 AM, AndroidDevTime <androiddevd...@gmail.com> wrote: > 1) If the Application needs to always listen for certain events > whether they show up in the widget or not where should this go? In the > Widget? There is no reason for an AppWidgetProvider to respond to other broadcasts, since anything can update the app widget's RemoteViews. And an AppWidgetProvider cannot register listeners (e.g., PhoneStateListener). Hence, I would say the answer here is "no". > 2) Should the widget issue notification? or request a service to issue > them? ie should the notification logic reside in the widget itself or > in the service. Technically, AFAIK, raising a notification is cheap and therefore safe for an AppWidgetProvider to do. Logically, an AppWidgetProvider should never have any reason to raise a notification, IMHO. > 3) Should the widget issue broadcasts or ask a service to do this? Technically, AFAIK, sending a broadcast is cheap and therefore safe for an AppWidgetProvider to do. Logically, an AppWidgetProvider should never have any reason to send broadcasts, IMHO. > 4) Should the widget ever access any system services like like > Notification Manager, PowerManager etc Why, Why not? This cannot be answered in the abstract. > 5) Should the widget keep any of its own state? If it should not keep > state how can it change what it displays? Like a different text or > icon? It may need to. For example, suppose you have an app widget that shows the weather for a certain city. The configuration activity for that app widget allows the user to choose the city. Somewhere, you need to store that city, and distinct from the cities that any other instance of that app widget may need (e.g., user adds two copies of the app widget to track weather in two cities). > 6) Should the widget start off activities or let a service handle > this? An AppWidgetProvider should never have a reason to directly "start off activities", nor should a service triggered from an AppWidgetProvider have any reason to directly "start off activities", IMHO. However, either are perfectly welcome to create PendingIntents that "start off activities" and attach them as click handlers for widgets in an app widget's RemoteViews. > 7) is it ok to user the context passed to update and receiver or > should one use ctx.getApplicationContext() to do things like > context.startService? ( Perhaps the one passed in is the application > context ? ) Most things you can just use the passed-in Context. One thing that will not work for is using registerReceiver() with a null receiver to get the last value of a sticky broadcast, such as ACTION_BATTERY_CHANGED -- for that, you will need to use getApplicationContext(). -- 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.4 Available! -- 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
