Develop Reference

Android AppWidgetProvider OnUpdate and Application Upgrade scenario

I wanted to update the widgets information on the Application version update.
I know the onUpdate method of AppWidgetProvider gets called in App upgrade, however, the same method also gets called every time the widget is updated.
Question - is there a way by which we can differentiate whether AppWidgetProvider.onUpdate is called on App update or via the widget uddate?
Note - I know that we can do this by creating the broadcast MY_PACKAGE_REPLACED and have a logic there. However as per my experience this does not gets called on certain devices.
Thanks in advance!!!

Avoid registering duplicate broadcast receivers in Android

I am trying to create my first Android app. I would like a main-thread Activity (in my case: an ActionBarActivity) to receive notification of an event from a background Activity (in my case: an IntentService). I've read that using broadcasts should be the best way to do this.
To register a Broadcast Receiver for listening to broadcasts sent from the background activity, I am using the following code inside the main-thread activity:
// Register broadcast receiver
LocalBroadcastManager bManager = LocalBroadcastManager.getInstance(this);
IntentFilter intentFilter = new IntentFilter();
intentFilter.addAction("com.me.myBroadcast");
bManager.registerReceiver(bReceiver, intentFilter);
I tried putting this in the onCreate() method of my main-thread activity, but I quickly discovered that every time I restart the activity (e.g. closing the app and re-opening it), it seems to create "duplicate" broadcast receivers, which then trigger the Broadcast Receiver's onReceive() method multiple times whenever a single broadcast is sent. This is causing problems.
So I created a SharedPreferences file to save a boolean which remembers whether or not I have already created a Broadcast Receiver, so as to avoid creating duplicates. This works exactly as hoped, until I restart the device of course, after which the Broadcast Receiver is destroyed, and the app doesn't create a new one because the SharedPreferences boolean says it already has one.
I'm guessing I could patch this issue by setting up a new broadcast receiver to listen for a device reboot, which resets the SharedPreferences boolean, but I have this nagging feeling that I am overcomplicating things massively. What am I missing? Thanks for any help offered!!

To answer your question, you can ignore sharedprefs and register the broadcast receiver in onResume and unregister the receiver in onPause. This method is well described in Reporting Work Status(1) android doc. Note that, this way, you will get status updates only if Activity is in foreground. Use appropriate life cycle methods depending on your needs.
To report status back to foreground activity from service, my preference would have been ResultReceiver(2) class which feels natural compared to a broadcast. Also, if you need to report multiple status messages back, it will be clearer with statusCode param in onReceiveResult method of ResultReceiver class.

Android BroadcastReceiver Lifecycle: documentation wrong for dynamically registered receiver?

I define a BatteryInfo extends BroadcastReceiver class. I call its constructor once in my Activity onCreate(). I register it with Activity.registerReceiver in my onCreate().
I am trying to figure out whether I need to unregister it and/or set its reference to null in order to allow my Activity to die without leaking memory or clogging up intent senders in the system, or whether the system gracefully tosses everything associated with this on its own. Towards that end I am pondering the BroadcastReceiver Lifecycle where I read:
A BroadcastReceiver object is only valid for the duration of the call to onReceive(Context, Intent). Once your code returns from this function, the system considers the object to be finished and no longer active."
what does this mean? Obviously the object I have created with new BatteryInfo() and registered with registerReceiver() persists through the entire time my activity persists. I log results from it and see them that entire time. Obviously it has not become invalid after the first time its onReceive() was called.
I am wondering if this section of documentation perhaps applies only to BroadcastReceivers which are registered in the AndroidManifest? And that it is simply incorrect or irrelevant to BroadcastReceivers that are dynamically created and registered?
And of course, I am wondering what is proper clean up and derferencing for my dynamic receivers.

All you need to do for BroadcastReceivers in code is register and unregister them. That statement is to inform you that you can't do any work outside of the onReceive, for example in another thread, and return a value back to the BroadcastReceiver. To do that you would get the BroadcastReceiver to start a Service.

Android widget is broken when device reboots

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.

Android: onAppWidgetChanged doesn't appear to exist

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.