I have a widget that needs to perform a potentially long-running operation in onUpdate(). Just performing the operation directly resulted in ANR's. To solve this, my first attempt was to create a thread therein. I noticed that the widget would not get updated in some cases. My guess here is that once onUpdate() exits, Android may kill the process along with the unfinished thread.
My next attempt was to create an intent service. The widget's onUpdate() just starts the intent service, which does the work directly and updates the widget when done. This works, but much to my surprise it appears that onHandleIntent() is single-threaded. If I have two widgets, and then both update and start the intent service, they update sequentially ...
The two widgets case is not really important, but I'm just wondering about a best practice for this type of pattern.
To solve the two widgets case I ended up updating all the widget instances with the same data whenever any one of them is clicked. e.g., I perform the long-running process once and apply the results to all the widget instances. In my scenario this doesn't matter, but for many widgets, it might be important not to do that.
Thoughts?
but much to my surprise it appears that onHandleIntent() is single threaded
Yes.
if i have two widgets, and then both update and start the intent service, they update sequentially ...
Yes.
but i'm just wondering about a best practice for this type of pattern.
Your IntentService was a fine upstanding solution, IMHO. Remember that Android runs on slow CPUs, with devices with little RAM. Running lots of threads in parallel is generally not a good idea.
then i'm getting into starting a thread in onHandleIntent(), which requires a wake lock, and it just seems it's getting all too complicated.
Try my WakefulIntentService.
make onUpdate call your own function to cycle through the widgets and update them. Do your async task before the cycle. You will want two separate actions, one that asks for the update to start, and one that your IntentService will broadcast to let the widgets know they are finished. Hope this helps.
#Override
public void onUpdate(Context context, AppWidgetManager appWidgetManager,
int[] appWidgetIds) {
updateWidget(context, appWidgetManager, appWidgetIds);
}
private void updateWidget(Context context){
ComponentName widget = new ComponentName(context, MyWidget.class);
AppWidgetManager appWidgetManager = AppWidgetManager.getInstance(context);
int[] appWidgetIds = appWidgetManager.getAppWidgetIds(widget);
updateWidget(context, appWidgetManager, appWidgetIds);
}
private void updateWidget(Context context, AppWidgetManager appWidgetManager, int[] appWidgetIds) {
final boolean isEnabled = true; //took out code didn't want you to see
// start intent service here
for(int i = 0; i< appWidgetIds.length; i++){
int appWidgetId = appWidgetIds[i];
Intent intent = new Intent(isEnabled ? ACTION_TOGGLE_OFF : ACTION_TOGGLE_ON);
PendingIntent pi = PendingIntent.getBroadcast(context, 0, intent, 0);
RemoteViews views = new RemoteViews(context.getPackageName(), R.layout.widget_layout);
views.setOnClickPendingIntent(R.id.widget , pi);
views.setImageViewResource(R.id.widget_image, isEnabled? R.drawable.widget_on : R.drawable.widget_off);
appWidgetManager.updateAppWidget(appWidgetId, views);
}
}
Related
I have created an Appwidget that displays an image file (test.png) that is provided to it's RemoteViews via Uri.
In onUpdate i run a service that changes the content of the file. I have also set an onClickListener for the image that will call onUpdate.
-If I create an instance of the AppWidget it displays the most recently changed version of the Uri file.
-If I click the widget, my service makes the approporaite changes to the file (which I can verify with a file explorer), but it does not update the image displayed in the AppWidget.
-(and most importantly)If I delete the AppWidget and create a new one, It displays the current/correct version of the image file.
I'm aware that my service may be taking too long to take effect on the first pass, but it should display the most recent image on the next onClick/call of onUpdate.
As it stands now, the AppWidget only displays the version of the image file that exists on the first call of onUpdate.
Question:
What is the proper way to refresh the RemoteView content of an Appwidget, am I missing something in my Approach here?
thanks for your time!
Update:
I have tried calling the AppWidgetManager.notifyAppWidgetViewDataChanged() method from AppWidgetProvider.onReceive(), and still not change to the RemoteViews content after onUpdate().
public class CCWidgetProvider extends AppWidgetProvider {
#Override
public void onUpdate(Context context, AppWidgetManager appWidgetManager,int[] appWidgetIds)
{
// Get all ids
ComponentName thisWidget = new ComponentName(context,CCWidgetProvider.class);
int[] allWidgetIds = appWidgetManager.getAppWidgetIds(thisWidget);
for (int widgetId : allWidgetIds)
{
RemoteViews remoteViews = new RemoteViews(context.getPackageName(),R.layout.widget_layout04);
/*
* it's here that I run a service that changes the content of the file /test/test.png
*/
RelativeLayout RL_widget = new RelativeLayout(context);
LayoutInflater inflater = (LayoutInflater)context.getSystemService( Context.LAYOUT_INFLATER_SERVICE );
RL_widget = (RelativeLayout)inflater.inflate(R.layout.widget_main, null);
Uri uri = Uri.parse(Environment.getExternalStorageDirectory().getPath()+"/test/test.png");
remoteViews.setImageViewUri(R.id.IV_widget_image,uri);
Intent intent = new Intent(context, CCWidgetProvider.class);
intent.setAction(AppWidgetManager.ACTION_APPWIDGET_UPDATE);
intent.putExtra(AppWidgetManager.EXTRA_APPWIDGET_IDS, appWidgetIds);
//PendingIntent pendingIntent = PendingIntent.getBroadcast(context,0, intent, PendingIntent.FLAG_CANCEL_CURRENT);
PendingIntent pendingIntent = PendingIntent.getBroadcast(context,0, intent, PendingIntent.FLAG_UPDATE_CURRENT);
remoteViews.setOnClickPendingIntent(R.id.IV_widget_image, pendingIntent);
appWidgetManager.updateAppWidget(widgetId, remoteViews);
}
}
}
There are various things that I have found can make widgets hard.
A. onUpdate isn't really an update mechanism
Contrary to how it sounds, onUpdate is only called in two situations:
When the widget is created.
Whenever the update cycle time (updateMillis defined in the xml definition file file for the widget) elapses.
Key point: onUpdate is never called at other times. (As far as I have ever seen in practice).
If you want the widget to update at another time, it is necessary to create a separate mechanism with knowledge of the widget and the capacity to be triggered. Typically this would be a Service which you start in the onUpdate routine. This might look like:
public void onUpdate(Context context, AppWidgetManager appWidgetManager, int[] appWidgetIds )
{
// start the service in case it ain't started yet, this also force a widget update to ensure correct status on them
Intent intent = new Intent(context, MyService.class);
intent.putExtra('service.startCode', /*A number to identify what is going on*/);
context.startService(intent);
// Everything else is triggered from the service!!
}
The service then sets the content sof the widget, and updates them as necessary, either through internal timekeeping or through the use of the Broadcast mechanism.
B. You can't really update a bit of the widget
It might seem logical to create a remoteViews when you create the widget and then update that, or the Views in it, when things change. In my experience this doesn't work predictably. When you want to change anything in a widget, create a new remoteViews, fill it out correctly and then assign it to the widget.
I ran into some device dependency with the way RemoteView was handling URIs, and found my way to a solution like this:
RemoteViews remoteViews = new RemoteViews(context.getPackageName(),R.layout.widget_layout);
Uri uri = Uri.parse("file://"+Environment.getExternalStorageDirectory().getPath()+"/test/test.png");
Bitmap bitmap = BitmapFactory.decodeResource(context.getResources(), R.drawable.crap);
bitmap = MediaStore.Images.Media.getBitmap(context.getContentResolver(), uri);
remoteViews.setImageViewBitmap(R.id.IV_widget_image, bitmap);
It also eliminated the need to cycle RemoteViews, as in my other answer.
Certainly not elegant, or memory efficient, but I found that if I duplicated my RemoteViews
RemoteViews remoteViews = new RemoteViews(context.getPackageName(),R.layout.widget_layout01);
RemoteViews remoteViews2 = new RemoteViews(context.getPackageName(),R.layout.widget_layout02);
duplicate the code surrounding them, and swap them intermittently between image updates (kind of like a buffer), resetting the RemoteViews each time forces an update on their content!
Works for me for now, please feel free chime in with a more correct solution.
So far, all the AppWidgetProvider code example I had seen, they placed UI event handler register code in onUpdate.
However, isn't this is some how inefficient? As I thought UI event handler registration just need to be done 1 time.
onUpdate will always be triggered repeatably.
Is there any more efficient way?
public class MyWidgetProvider extends AppWidgetProvider {
private static final String ACTION_CLICK = "ACTION_CLICK";
#Override
public void onUpdate(Context context, AppWidgetManager appWidgetManager,
int[] appWidgetIds) {
...
// Register an onClickListener
Intent intent = new Intent(context, MyWidgetProvider.class);
intent.setAction(AppWidgetManager.ACTION_APPWIDGET_UPDATE);
intent.putExtra(AppWidgetManager.EXTRA_APPWIDGET_IDS, appWidgetIds);
PendingIntent pendingIntent = PendingIntent.getBroadcast(context,
0, intent, PendingIntent.FLAG_UPDATE_CURRENT);
remoteViews.setOnClickPendingIntent(R.id.update, pendingIntent);
appWidgetManager.updateAppWidget(widgetId, remoteViews);
}
}
}
Let me put it in this way.
Remote views are not the real views, but rather a set of rules, which is used to create real views. Then you call updateAppWidget(), then this set of rules gets sent to Android, and Android creates new views by applying these rules. OnClickPendingIntent is one of those rules. If it's there, then it gets applied and you have a listener set.
If you create a new instance of remoteViews, then you have to provide a OnClickPendingIntent to this instance too. If you don't, then there will be no listener registered and you won't get a callback. In this regards, you do not set listener twice or multiple times at the same instance - because you always re-create remoteViews too - and this is optimal.
Android might apply additional optimization by reusing already existing views, if remote views were not changed. But this is something out of your control.
I'm adding a widget to an old app which I'm updating from a service I'm using to poll for data in the background (on an alarm). I update the widget every time the service gets a result. This is currently working correctly.
// Called from inside my service when it has results
private void updateWidget(List<Earthquake> earthquakes) {
AppWidgetManager manager = AppWidgetManager.getInstance(this);
int[] appWidgetIds = manager.getAppWidgetIds(new ComponentName(this, WhatsShakingWidgetProvider.class));
if (appWidgetIds == null || appWidgetIds.length == 0)
return;
Earthquake earthquake = earthquakes.get(0);
RemoteViews views = new RemoteViews(getPackageName(), R.layout.widget_detail);
// Update views
views.setTextViewText(R.id.widget_detail_latest_magnitude, earthquake.getFormattedMagnitude());
// etc...
// Update each widget
for(int appWidgetId : appWidgetIds) {
manager.updateAppWidget(appWidgetId, views);
}
}
This polling service is optional; it can be turned on or off in the app's settings.
If the service is off when the user adds the widget, the widget_error layout is shown, as expected. The user can tap on the widget to enter the settings and turn the background updates on. When they do this (turn the setting on or off), I broadcast ACTION_APPWIDGET_UPDATE. The widget enters onUpdate correctly, and is updated correctly by the service the next time it runs (I've set it up so the widget triggers a service call in onUpdate - see below).
The widget does not correctly display the widget_error layout when the service becomes disabled after being enabled - it leaves the old layout in place, even though all the disabled-case code is run.
This is the code that gets called when the user toggles the setting (Source):
// If our user has widgets, we should update those - let the widget do the updating depending on the prefs, though.
Intent intent = new Intent(this, WhatsShakingWidgetProvider.class);
intent.setAction(AppWidgetManager.ACTION_APPWIDGET_UPDATE);
// Use an array and EXTRA_APPWIDGET_IDS instead of AppWidgetManager.EXTRA_APPWIDGET_ID,
// since it seems the onUpdate() is only fired on that:
int[] ids = { R.xml.widget_info };
intent.putExtra(AppWidgetManager.EXTRA_APPWIDGET_IDS, ids);
sendBroadcast(intent);
And this is the code in onUpdate which should be updating the widgets, but isn't:
#Override
public void onUpdate(Context context, AppWidgetManager appWidgetManager,
int[] appWidgetIds) {
super.onUpdate(context, appWidgetManager, appWidgetIds);
SharedPreferences prefs = PreferenceManager.getDefaultSharedPreferences(context);
boolean backgroundUpdatesEnabled = prefs.getBoolean(PreferenceActivity.KEY_PREF_ALLOW_BG_NOTIFICATIONS,
DefaultPrefs.BG_NOTIFICATIONS_ENABLED);
if (!backgroundUpdatesEnabled) {
RemoteViews views = new RemoteViews(context.getPackageName(), R.layout.widget_error);
// Update click to take to preferences
Intent intent = new Intent(context, PreferenceActivity.class);
intent.setFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
PendingIntent pendingIntent = PendingIntent.getActivity(context, 0, intent, PendingIntent.FLAG_UPDATE_CURRENT);
views.setOnClickPendingIntent(R.id.widget_error_parent_container, pendingIntent);
// Update each widget
appWidgetManager.updateAppWidget(appWidgetIds, views);
} else {
// Let's get some data for the user! Service does the work of updating the views.
WakefulIntentService.sendWakefulWork(context, GeonetService.class);
}
}
There are no errors logged in Logcat. Stepping through this, I correctly enter each part of the if when expected (that is, if the user turned the setting off, then I create RemoteViews views as widget_error, otherwise I start the service).
Why does the widget_error layout display correctly the first time through onUpdate, but not when the user enables, then disables, the background update setting?
I've tried wrapping this in a RelativeLayout and setting the visibility of the error message/the content, but that exhibited the same behaviour - I couldn't get the error message to show back up after initially hiding it.
I ended up duplicating the code in two places (the preferences activity and the widget provider) and it worked. The only variable appears to be the Context object.
It appears that for some reason the Context instance you get in the AppWidgetProvider (that is, in onUpdate) only works the first time - or, doesn't work when I send the broadcast myself. I'm not sure why.
I pulled my duplicated code out to a separate class and just pass in the Context instance I have available, whether it's the Service, an Activity, or the AppWidgetProvider (which is a BroadcastReceiver). This correctly updates the widget, and I can call it from anywhere I have a Context.
Source is available here.
I created an AppWidget for my App and setup the updatePeriodMillis to 0,
because this Widget is not doing anything, if the user does not interact.
Everything works fine, untill Android cleans the ram. Then the widget won't respond anymore until the App is started again or the device is rebooted (in both cases the onUpdate() will run again).
So my question: What do I need to do, to bring it back to work, after Android kicked out the Application?
This is part of the manifest:
<receiver android:name="WidgetProvider" >
<intent-filter>
<action android:name="android.appwidget.action.APPWIDGET_UPDATE" />
<action android:name="PATH.widgetBtnStartClicked" />
</intent-filter>
<meta-data android:name="android.appwidget.provider"
android:resource="#xml/appwidget_provider_info" />
</receiver>
This is part of my WidgetProvider:
public class WidgetProvider extends AppWidgetProvider {
private static final String BTN_START_CLICKED = "PATH.widgetBtnStartClicked";
private static Values values;
#Override
public void onUpdate(Context context, AppWidgetManager appWidgetManager,
int[] appWidgetIds) {
super.onUpdate(context, appWidgetManager, appWidgetIds);
// get RemoteView (widget):
for (int i = 0; i < appWidgetIds.length; i++) {
int appWidgetId = appWidgetIds[i];
RemoteViews views = new RemoteViews(context.getPackageName(),
R.layout.appwidget);
// Register onClick for App-start-button:
Intent intentLaunch = new Intent(BTN_APP_LAUNCH_CLICKED);
intentLaunch.setFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
PendingIntent pendingIntentLaunch = PendingIntent.getBroadcast(
context, appWidgetId, intentLaunch,
PendingIntent.FLAG_UPDATE_CURRENT);
views.setOnClickPendingIntent(R.id.appwidget_btn_launch,
pendingIntentLaunch);
appWidgetManager.updateAppWidget(appWidgetId, views);
}
}
#Override
public void onReceive(Context context, Intent intent) {
RemoteViews views = new RemoteViews(context.getPackageName(),
R.layout.appwidget);
super.onReceive(context, intent);
AppWidgetManager appWidgetManager = AppWidgetManager
.getInstance(context);
ComponentName componentName = new ComponentName(context,
WidgetProvider.class);
if (intent.getAction().equals(BTN_APP_LAUNCH_CLICKED)) {
//do some stuff..
}
// update views
appWidgetManager.updateAppWidget(componentName, views);
}
I hope there is everything you need to understand the problem. Just tell me, if not!
I think your app relies only on onUpdate() to refresh the widget. There are other events that cause the pending intents to 'drop off' the widget.
Such as the RAM clearing you mention.
I recommend you:
+ put your widget update code in a separate service class
+ have that class triggered when different events happen. onUpdate() and other events, example, the one that causes your RAM to be cleared.
+ ensure you update everything each time with remoteviews, because no old pending intents etc are preserved.
You can take total control over the events that trigger the widget to update.
If it suits your situation, you can also set an arbitrary alarm, using the alarmmanager and a receiver class. in this way, you can set the alarm to only be received when the phone wakes, and use that to call your update service class. in your update service class, then clear any alarm (if the update is called from another event) and set another alarm.
There are lots of questions on SO about who to use a service with widgets. It shouldnt take long to work it out. To put that info here is outside of the scope of this question.
When I'm running in debugging mode I can't seem to reach any breakpoints that are inside of the service, why is that?
#Override
public void onUpdate(Context context, AppWidgetManager appWidgetManager,
int[] appWidgetIds) {
context.startService(new Intent(context, UpdateService.class));
}
public static class UpdateService extends Service {
#Override
public void onStart(Intent intent, int startId) {
// Build the widget update for today
RemoteViews updateViews = buildUpdate(this);
// Push update for this widget to the home screen
ComponentName thisWidget = new ComponentName(this, WidgetProvider.class);
AppWidgetManager manager = AppWidgetManager.getInstance(this);
manager.updateAppWidget(thisWidget, updateViews);
}
public RemoteViews buildUpdate(Context context) {
return new RemoteViews(context.getPackageName(), R.id.widget_main_layout);
}
#Override
public IBinder onBind(Intent intent) {
return null;
}
}
The "onUpdate"-method is only executed if the widget is initalized (e.g. put on the homescreen) or the updatePeriodMillis are expired. If you want to execute the service e.g. by a click on the widget, you have to "attach" a pending intent like this:
#Override
public void onUpdate(Context context, AppWidgetManager appWidgetManager, int[] appWidgetIds) {
final Intent intent = new Intent(context, UpdateService.class);
PendingIntent pendingIntent = PendingIntent.getService(context, 0, intent, 0);
// Get the layout for the App Widget and attach an on-click listener to
// the button
RemoteViews views = new RemoteViews(context.getPackageName(), R.layout....);
views.setOnClickPendingIntent(R.id.button, pendingIntent);
for(int i=0,n=appWidgetIds.length;i<n;i++){
int appWidgetId = appWidgetIds[i];
appWidgetManager.updateAppWidget(appWidgetId , views);
}
(cleaned up version of a working widget).
The point is, that the onUpdate() method is really very seldom executed. The real interaction with a widget is specified through pending intents.
Your Service might not be registered in the manifest. Or your AppWidgetProvider might not be registered in the manifest.
You might want to think of not using a service for what you're doing. If it's just running the updateViews() once a day then consider just setting android:updatePeriodMillis to 86400000 in the XML file that's linked to your appwidget. Your XML file would look something like this:
<appwidget-provider xmlns:android="http://schemas.android.com/apk/res/android"
android:minWidth="72dp"
android:maxWidth="72dp"
android:updatePeriodMillis="86400000" >
</appwidget-provider>
This will have android update your appwidget once a day without having a service run in the background that might get killed by a task killer that the user is running which then stops your widget from updating. Just a note, if you need it to update faster than every 30 minutes then android:updatePeriodMillis won't work (it's minimum value is 30 minutes) at that point I'd recommend using an AlarmManager since that'll use up less battery than a Service and also won't be killed by task killers.