When the device is restarted, my appWidgets are all broken. In my WidgetProvider class i have implemented only the onRecieve method, since i'm using a ConfigureActivity to create the widget. What method should I override on the WidgetProvider for my widget to be updted properly when the device is restarted?
When the device reboots, all the desktop widgets are rebuilt via the onUpdate method in the WidgetProvider class. Just implement this method to recreate your widget as shown here.
If I understand your problem correctly, register to receive the ACTION_BOOT_COMPLETED broadcast, and re-create your widget when you receive it.
Make sure you also hold the RECEIVE_BOOT_COMPLETED permission.
It's best practice to make sure you respond and exit from your BOOT_COMPLETED handler as quickly as possible - spending too long responding to BOOT_COMPLETED will give a poor user impression of the platform.
Related
The Android widget documentation (http://developer.android.com/guide/topics/appwidgets/index.html#AppWidgetProvider) seems to indicate that you can set your own broadcast receiver to handle widget activity instead of using the AppWidgetProvider helper class. For reasons of activity/service structure this would be the most convenient way for me to manage the widget I would like to create.
Is it possible to do this with a broadcast receiver registered in OnCreate as opposed to on in it's own class. The trouble, I think, is that it then isn't registered in the manifest, and thus the widget never shows up in the list.
Documentation/examples of this setup are essentially non-existent. Does anyone know if this is possible or have a good example?
Is it possible to do this with a broadcast receiver registered in OnCreate as opposed to on in it's own class.
Not really. In theory, you could have two receivers registered, one in the manifest and one via registerReceiver(). I cannot imagine a scenario in which this would be a good idea, as your activity will not be running all of the time anyway, and so you need the manifest-registered receiver to do everything anyhow.
Does an onUpdate AppWidget called on boot?
I'm setting an alarm in the onUpdate and I wanted to know if the onUpdate will get called on boot or should I use the BOOT_COMPLETED intent.
Thanks.
I didn't find anything in the docs regarding this so I just tested it out. I set a Toast in the onUpdate() method of my widget to see when it's triggered. After restarting the device it got triggered, so I assume that you don't need to use the BOOT_COMPLETED intent, but sometimes you can't be sure enough(there is nothing against still using it).
Edit:
onUpdate() does get called on boot and the Android docs do cover this:
onUpdate()
Called in response to the ACTION_APPWIDGET_UPDATE and ACTION_APPWIDGET_RESTORED broadcasts when this AppWidget provider is being asked to provide RemoteViews for a set of AppWidgets. Override this method to implement your own AppWidget functionality.
Source
ACTION_APPWIDGET_UPDATE
This may be sent in response to a new instance for this AppWidget provider having been instantiated, the requested update interval having lapsed, or the system booting.
Source
I am not trying to create a BOOT_COMPLETED receiver (and doing so would not solve my problem).
Is there a way to determine if BOOT_COMPLETED has occurred? I have a library which is being called before (as well as after) Android has finished booting, and I do not want my library to complete its request if the system has not finished booting. Setting up a BOOT_COMPLETED receiver in every application that may use this library is not a reasonable approach for several reasons.
Are there any Android calls I can make to determine if the device's boot has completed? It appears that there is a property, dev.bootcomplete, which I may have to use if no better method exists.
I'm afraid the only official way of achieving this is to create RECEIVE_BOOT_COMPLETED receiver.
I would advise you not to rely on properties, since they often are OEM specific. Otherwise you may end up with your application working on one Android model, but not another.
Setting up a BOOT_COMPLETED receiver in every application
I guess you mean to say you dont want BOOT_COMPLETED receiver in each activity .
Its very much possible.
You can register BOOT_COMPLETED receiver for Activity A.and once Activity A a gets broadcast it can notify other activities using sendBroadcast (custom broadcast).
To see how to use custom broadcast look here
Widget Provider is a specialized BroadcastReceiver.
Assuming there exists an Application, 1-n android service,1-k activities, and potentially additional 0-n broadcast receivers that are not widgets, I would like to verify what belongs and does not belong logically inside the broadcast receiver. Here are some items ..
And assuming that generally what gets launched is the widget first.
Please comment on any of the items as to whether they belong inside or outside the widget and why. Thanks.
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? If not what would keep the broadcast receiver available to listen to the events for the application?
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.
3) Should the widget issue broadcasts or ask a service to do this?
4) Should the widget ever access any system services like like Notification Manager, PowerManager etc Why, Why not?
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?
6) Should the widget start off activities or let a service handle this?
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 ? )
Quoting myself from your cross-post to the android-developers Google Group:
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".
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().
This is the description of AppWidgetHost.startListening():
Start receiving onAppWidgetChanged
calls for your AppWidgets
I can't find any reference to this mysterious onAppWidgetChanged thing anywhere. The only Google hits are quotes from the same piece of documentation.
What is it actually referring to? What does one need to call, override, or implement to get widget updates?
Its very unlikely that you need to implement a Widget host yourself. The home page is an existing Widget Host. Most likely what you are looking to do is Implement a WidgetProvider which basically means extending android.appwidget.AppWidgetProvider and overriding two methods:
onUpdate() and onReceive() some time onEnabled too. You almost never need to implement a Widget host, but if this is your goal please clarify. The widget provider is essentially a broadcast receiver which is designed to run inside widget host (usually home). The widget provider might live for only milliseconds, to process the broadcasted events and processing one of them is mandatory and must be specified in the manifest. To communicate out information the widget provider like any broadcast receiver extends context and can issue startActivity(intent) or startService(intent) I think this is most likely what you need to do unless you really are implementing a Widget Host.