Databases
StackOverflow2013
Postsdbo
POEnabling/disableing receiver (CONNECTIVITY_CHANGE) causes APPWIDGET_UPDATE broadcast
 

Note that there are some explanatory texts on larger screens.

plurals
  1. POEnabling/disableing receiver (CONNECTIVITY_CHANGE) causes APPWIDGET_UPDATE broadcast
    primarykey
    data
    text
    <p>I have a receiver listening for <code>android.net.conn.CONNECTIVITY_CHANGE</code> so that I can update my appwidget when connectivity is restored. This works fine except I am getting some strange behavior when I enable or disabled my receiver via:</p> <pre><code>ComponentName receiver = new ComponentName(this, NetworkStateReceiver.class); PackageManager pm = getPackageManager(); pm.setComponentEnabledSetting(receiver, PackageManager.COMPONENT_ENABLED_STATE_ENABLED, PackageManager.DONT_KILL_APP); </code></pre> <p>When the state is changed I also receive an <code>android.appwidget.action.APPWIDGET_UPDATE</code> broadcast to my appwidget's receiver causing my appwidget to update again after detecting connectivity lost, and then twice when connectivity is returned (Once intentionally from my NetworkStateReceiver and then again from the <code>APPWIDGET_UPDATE</code> broadcast).</p> <p>Also, this only seems to happen on my 4.04 device and not on my 2.1 device.</p> <p>Manifest for NetworkStateReceiver and AppWidgetProvider</p> <pre><code> &lt;receiver android:name=".AppWidgetProvider" android:label="@string/widget_name" &gt; &lt;intent-filter&gt; &lt;action android:name="android.appwidget.action.APPWIDGET_UPDATE" /&gt; &lt;/intent-filter&gt; &lt;meta-data android:name="android.appwidget.provider" android:resource="@xml/appwidget" /&gt; &lt;/receiver&gt; &lt;receiver android:name=".NetworkStateReceiver" android:enabled="false"&gt; &lt;intent-filter&gt; &lt;action android:name="android.net.conn.CONNECTIVITY_CHANGE" /&gt; &lt;/intent-filter&gt; &lt;/receiver&gt; </code></pre> <p>I have tried a few ways to work around this, but none are very good solutions.</p> <p>I can ignore any update from an <code>APPWIDGET_UPDATE</code> broadcast. Actually I do this already since all my appwidget updating happens through a service via an alarm manager or config activity when first created. For some reasons though (and perhaps indicative of whats going on), the <code>APPWIDGET_UPDATE</code> broadcast also causes my remoteviews to revert back to its XML state like its been added for the first time. I could probably work around that too by saving extra state, which would include bitmaps. Not ideal.</p> <p>I could have the NetworkStateReceiver listen all the time instead of enableing/disabling, but this goes against Android's recommendations and for good reasons since it means unnecessary broadcasts.</p> <p>Other ideas?</p> <p><strong>EDIT</strong>: Further explanation of my current workaround.</p> <p>I can't ignore the <code>APPWIDGET_UPDATE</code> broadcast even though I use alarms to trigger my updates. This is because the <code>APPWIDGET_UPDATE</code> also resets my widget to its initial state like its been added to the homescreen for the first time. In cases where I have a connection I can do double updates because all the info can be re-populated. I also still have to do my own update since the bug seems device specific and non-affected devices still need an update.</p> <p>In cases where I do not have connectivity, I then restore the widget from earlier saved state. This means that every time I do a successful update, I also save everything to SharedPreferences so it can be restored under one of these "forced updates" when internet isn't available to properly re-populate the data.</p> <p>In my <code>AppWidgetProvider</code> I do (simplified):</p> <pre><code>Intent intent = new Intent(context, WidgetUpdateService.class); intent.putExtra("loadFromSaved", true); // this will be false when coming from AlarmManager context.startService(intent); </code></pre> <p>WidgetUpdateService.onStartCommand() (also simplified):</p> <pre><code>if (intent.getExtras().getBoolean("loadFromSaved") { widgetLoader.loadFromSavedData(); } else { widgetLoader.load() } </code></pre>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PTQuestion
    1. USpaul
    1. USpaul
    plurals
    1. PL
      singulars
      1. LTLinked
    2. PL
      singulars
      1. LTLinked
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PO
      singulars
      1. PTAnswer
    1. VO
      singulars
      1. POEnabling/disableing receiver (CONNECTIVITY_CHANGE) causes APPWIDGET_UPDATE broadcast
      1. USelectricSunny
      1. VTFavorite
    2. VO
      singulars
      1. POEnabling/disableing receiver (CONNECTIVITY_CHANGE) causes APPWIDGET_UPDATE broadcast
      1. USpaul
      1. VTBountyStart
    3. VO
      singulars
      1. POEnabling/disableing receiver (CONNECTIVITY_CHANGE) causes APPWIDGET_UPDATE broadcast
      1. This table or related slice is empty.
      1. VTUpMod
    1. COPaul - I have exactly the same issue. Its driving me crazy!.....
      singulars
      1. POEnabling/disableing receiver (CONNECTIVITY_CHANGE) causes APPWIDGET_UPDATE broadcast
      1. USelectricSunny
    2. COI still haven't found a good solution. I am working around it right now by saving extra state. Please post if you figure something out! I saw this [bug report](https://code.google.com/p/android/issues/detail?id=21635) which is different, but perhaps related.
      singulars
      1. POEnabling/disableing receiver (CONNECTIVITY_CHANGE) causes APPWIDGET_UPDATE broadcast
      1. USpaul
    3. COPaul - I'm still no further forward. I'd be interested to hear your workaround for this, saving extra state. Would you please mind sharing? ta
      singulars
      1. POEnabling/disableing receiver (CONNECTIVITY_CHANGE) causes APPWIDGET_UPDATE broadcast
      1. USelectricSunny
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload