[android-developers] Re: updatePeriodMillis not working for widget on 1.6
Here is a related question. Are there other reasons to say the Alarm service is unreliable? My app uses repeating alarms. It was great with 1.5, very reliable. Since the upgrade to 1.6, the phone seems to be dropping some of my repeating broadcasts. I do not have any task killer programs, or at least I did not knowingly install any. Notice that I use unique requestCodes in the creation of my PendingIntent (children.getInt(0) in the code snippet below) to insure that the correct number of distinct alarms is created and to cancel any of those alarms at a later point in time, should that become necessary. Has the use of the requestCode parameter changed with the 1.6 SDK? almMgr.setRepeating (AlarmManager.RTC_WAKEUP, cal.getTimeInMillis(), SchedulerActivity.WEEKINMILLIS, PendingIntent.getBroadcast(ctxt, children.getInt(0), new Intent(ctxt, SoundOffTimer.class), PendingIntent.FLAG_UPDATE_CURRENT)); children.moveToNext(); The dropped broadcast behavior is intermittent. When the timer is a one shot, it seems to work correctly. I am wondering if others on the list have seen issues with the setRepeating method. I am also looking for suggestions for troubleshooting this problem. How can I determine if the problem is the broadcast, if it is the repeating alarm creation, or if there is some other issue like low memory coming in to play. Any ideas? Thanks and regards, Beth On Oct 23, 6:15 pm, Dianne Hackborn hack...@android.com wrote: On Fri, Oct 23, 2009 at 6:16 AM, String sterling.ud...@googlemail.comwrote: I'm already using alarms to drive my widget updates. Problem is, alarms are unreliable, especially with the proliferation of task killer apps which abuse the API (see http://groups.google.com/group/android-developers/browse_thread/threa... ). People have these running in the background, then I get complaints that my clock has stopped. Well the underlying problem there is these #$#$#!! apps abusing that API. I so regret having made that available. I should have realized it was a bad idea, because it violates a very basic tenant: one application should not be able to disrupt the behavior of another. Anyway, if possible it would be great if you chould tell your users that their task killer app is causing their problems. And it's not going to just cause problems with alarms: it will unpost any notifications you have, stop services you have running, etc. -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[android-developers] Re: updatePeriodMillis not working for widget on 1.6
On Oct 24, 12:58 am, Mark Murphy mmur...@commonsware.com wrote: Disretrospect wrote: Mark Murphy wrote: You cannot get TIME_TICK via a manifest-registered receiver. It has to be a receiver registered via Java code. Still possible though, register your receiver from your config activity or through a service started from onEnabled? Not from the config activity, since the activity will go away as soon as the configuration is done. And not from onEnabled either, because the app widget provider is a BroadcastReceiver, and that's not allowed: http://developer.android.com/reference/android/content/Context.html#registerReceiver(android.content.BroadcastReceiver, android.content.IntentFilter) And keeping a service around to receive a once-per-minute TIMER_TICK is bad for business. You want to not keep processes around any more than necessary. Also very true, but less applicable in my case because the widget in question is a clock, which the user wants to update once a minute. Frankly, IMHO, any user who installs a task killer app deserves whatever instabilities they get. I absolutely agree in principle, but unfortunately it's the widget devs who take the heat. The user sees the widget stop updating, and immediately trash-talks it in Market comments. Is there an issue inhttp://b.android.comabout the AlarmManager/task killer problem? There is now: http://code.google.com/p/android/issues/detail?id=4354 Please star if you agree that this is a problem, and add additional comments if you feel my description could use clarification - I'm not qualified to describe the issue at a platform level. String --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[android-developers] Re: updatePeriodMillis not working for widget on 1.6
What is the actual value of updatePeriodMillis in the XML file? It's worth noting that the updatePeriodMillis approach uses AlarmManager.setInexactRepeating(), which can cause variability in update frequencies if bins your update with other alarms. j On Thu, Oct 22, 2009 at 12:10 PM, String sterling.ud...@googlemail.com wrote: I'm aware that the minimum updatePeriodMillis was increased to 30 minutes for Donut, but in my testing, I'm not seeing the APPWIDGET_UPDATE intent come through at all, even after well over 30 minutes has passed. Has anyone else had an issue with this, or any light to shed on the matter? I should mention that all of my testing so far is on 1.6 emulator images; I don't yet have Donut hardware to test on, as my update here in the UK hasn't come through yet. So it's possible this is an emulator issue, but again, any information on that front would be helpful. For reference, my manifest code looks like this: receiver android:name=.MyWidgetProvider android:label=@string/widget_name android:enabled=true meta-data android:name=android.appwidget.provider android:resource=@xml/mywidget / intent-filter action android:name=android.appwidget.action.APPWIDGET_UPDATE / /intent-filter /receiver It's working fine on 1.5 (and has been for months), both on emulator and handset. Thanks, String -- Jeff Sharkey jshar...@android.com --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[android-developers] Re: updatePeriodMillis not working for widget on 1.6
Is it possible to set the width of a spinner dropdown list in code?
I have a spinner populated with integers, and it does not look good
with the list expanding to full width.
Can I set the width to wrap the content somehow?
I tried this..
Spinner hSpinner = (Spinner) timerView.findViewById(R.id.timer_hour_spinner);
ArrayListInteger hList = new ArrayListInteger(21);
for (int i = 0; i = 20; i++) { hList.add(i); }
ArrayAdapter hAdapter = new ArrayAdapter(RemindMe.this,
android.R.layout.simple_spinner_item, hList);
hAdapter.setDropDownViewResource(android.R.layout.simple_spinner_dropdown_item);
hSpinner.setAdapter(hAdapter);
But still showing the full width. What will be the solution?--
Regards,
Nisha
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
[android-developers] Re: updatePeriodMillis not working for widget on 1.6
Sterling Udell wrote: I have to say, this is likely to cause some unhappy users for various widgets. Especially with the minimum time being bumped up in Donut, there are probably widgets which used to update every 10 or 15 minutes, and which now may not get their first update for nearly an hour. I understand your reasons, but as so often happens, it's app developers who will get the brunt of the complaints. Set your own alarm using AlarmManager to supplement or replace updatePeriodMillis in the next edition of your app. You don't need to use it; it is there mostly as a convenience AFAICT. -- Mark Murphy (a Commons Guy) http://commonsware.com | http://twitter.com/commonsguy _Android Programming Tutorials_ Version 1.0 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 -~--~~~~--~~--~--~---
[android-developers] Re: updatePeriodMillis not working for widget on 1.6
whd? On Fri, Oct 23, 2009 at 6:19 PM, Sterling Udell sterling.ud...@googlemail.com wrote: Jeff, That's good to know, thanks. After running some much longer test sessions (like overnight), that does appear to be the situation, that it's behaving like setInexactRepeating and the first event might not happen for a while. I have to say, this is likely to cause some unhappy users for various widgets. Especially with the minimum time being bumped up in Donut, there are probably widgets which used to update every 10 or 15 minutes, and which now may not get their first update for nearly an hour. I understand your reasons, but as so often happens, it's app developers who will get the brunt of the complaints. 2009/10/23 nisha.devit nisha.de...@gmail.com Is it possible to set the width of a spinner dropdown list in code? Please don't hijack my thread. Thanks. String -- Regards, Nisha --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[android-developers] Re: updatePeriodMillis not working for widget on 1.6
On Oct 23, 1:54 pm, Mark Murphy mmur...@commonsware.com wrote: Set your own alarm using AlarmManager to supplement or replace updatePeriodMillis in the next edition of your app. You don't need to use it; it is there mostly as a convenience AFAICT. I'm already using alarms to drive my widget updates. Problem is, alarms are unreliable, especially with the proliferation of task killer apps which abuse the API (see http://groups.google.com/group/android-developers/browse_thread/thread/3f87972d1f99ee81). People have these running in the background, then I get complaints that my clock has stopped. So I've been using updatePeriodMillis as a backup, checking that my widget update alarm is still running every so often. My concern is also for other widget developers; this was not a well publicized change in Donut, and there's probably some head-scratching about a feature that used to work fine in Cupcake but doesn't now. Hopefully less after threads like this, though. String --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[android-developers] Re: updatePeriodMillis not working for widget on 1.6
String wrote: I'm already using alarms to drive my widget updates. Problem is, alarms are unreliable, especially with the proliferation of task killer apps which abuse the API (see http://groups.google.com/group/android-developers/browse_thread/thread/3f87972d1f99ee81). People have these running in the background, then I get complaints that my clock has stopped. So I've been using updatePeriodMillis as a backup, checking that my widget update alarm is still running every so often. It would appear that the app widget framework uses AlarmManager for updatePeriodMillis, based upon my interpretation of the AppWidgetService.java code. My concern is also for other widget developers; this was not a well publicized change in Donut, and there's probably some head-scratching about a feature that used to work fine in Cupcake but doesn't now. Hopefully less after threads like this, though. Indubitably! -- Mark Murphy (a Commons Guy) http://commonsware.com | http://twitter.com/commonsguy Android Development Wiki: http://wiki.andmob.org --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[android-developers] Re: updatePeriodMillis not working for widget on 1.6
But presumably the alarm for updatePeriodMillis will be owned by a system process and will therefore be immune to the task killers. Tom. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[android-developers] Re: updatePeriodMillis not working for widget on 1.6
2009/10/23 Tom Gibara m...@tomgibara.com wrote: But presumably the alarm for updatePeriodMillis will be owned by a system process and will therefore be immune to the task killers. In my experience, that's exactly right, hence its usefulness as a backup for my own alarm. String -- Sterling Udell Author: - Beginning Google Maps Mashups, http://apress.com/book/view/9781430216209 - Pro Web Gadgets, http://apress.com/book/view/1430225513 --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[android-developers] Re: updatePeriodMillis not working for widget on 1.6
Sterling Udell wrote: 2009/10/23 Tom Gibara m...@tomgibara.com wrote: But presumably the alarm for updatePeriodMillis will be owned by a system process and will therefore be immune to the task killers. In my experience, that's exactly right, hence its usefulness as a backup for my own alarm. Ah. Good point. Clearly, therefore, we need to create an app widget that is a task killer killer... ;-) -- Mark Murphy (a Commons Guy) http://commonsware.com | http://twitter.com/commonsguy Android Development Wiki: http://wiki.andmob.org --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[android-developers] Re: updatePeriodMillis not working for widget on 1.6
So how about getting your AppWidgetProvider or your BroadcastReciever
to pick up android.intent.action.TIME_TICK. This way widgets can
update as often as every minute if they so wish?
// Manifest file
intent-filter
action android:name=android.intent.action.TIME_TICK /
/intent-filter
// AppWidgetProvider/Broadcast reciever
@Override
public void onReceive(Context context, Intent intent) {
final String action = intent.getAction();
if(intent.getAction().equals(Intent.ACTION_TIME_TICK)) {
// Do something
}
}
Any thoughts?
On Oct 23, 2:44 pm, Mark Murphy mmur...@commonsware.com wrote:
Sterling Udell wrote:
2009/10/23 Tom Gibara m...@tomgibara.com wrote:
But presumably the alarm for updatePeriodMillis will be owned by a system
process and
will therefore be immune to the task killers.
In my experience, that's exactly right, hence its usefulness as a
backup for my own alarm.
Ah. Good point.
Clearly, therefore, we need to create an app widget that is a task
killer killer... ;-)
--
Mark Murphy (a Commons
Guy)http://commonsware.com|http://twitter.com/commonsguy
Android Development Wiki:http://wiki.andmob.org
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
[android-developers] Re: updatePeriodMillis not working for widget on 1.6
Disretrospect wrote: So how about getting your AppWidgetProvider or your BroadcastReciever to pick up android.intent.action.TIME_TICK. This way widgets can update as often as every minute if they so wish? You cannot get TIME_TICK via a manifest-registered receiver. It has to be a receiver registered via Java code. -- Mark Murphy (a Commons Guy) http://commonsware.com | http://twitter.com/commonsguy _Beginning Android_ from Apress Now 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 -~--~~~~--~~--~--~---
[android-developers] Re: updatePeriodMillis not working for widget on 1.6
Mark Murphy wrote: You cannot get TIME_TICK via a manifest-registered receiver. It has to be a receiver registered via Java code. Still possible though, register your receiver from your config activity or through a service started from onEnabled? On Oct 24, 12:35 am, Mark Murphy mmur...@commonsware.com wrote: Disretrospect wrote: So how about getting your AppWidgetProvider or your BroadcastReciever to pick up android.intent.action.TIME_TICK. This way widgets can update as often as every minute if they so wish? You cannot get TIME_TICK via a manifest-registered receiver. It has to be a receiver registered via Java code. -- Mark Murphy (a Commons Guy)http://commonsware.com|http://twitter.com/commonsguy _Beginning Android_ from Apress Now 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 -~--~~~~--~~--~--~---
[android-developers] Re: updatePeriodMillis not working for widget on 1.6
Disretrospect wrote: Mark Murphy wrote: You cannot get TIME_TICK via a manifest-registered receiver. It has to be a receiver registered via Java code. Still possible though, register your receiver from your config activity or through a service started from onEnabled? Not from the config activity, since the activity will go away as soon as the configuration is done. And keeping a service around to receive a once-per-minute TIMER_TICK is bad for business. You want to not keep processes around any more than necessary. On devices with limited RAM, each process chews up space that is really needed for more important stuff. Frankly, IMHO, any user who installs a task killer app deserves whatever instabilities they get. Rewriting your app to make Android perform worse (take up more RAM/CPU), simply to defend against task killers, is a race to the bottom. Is there an issue in http://b.android.com about the AlarmManager/task killer problem? I don't see one, but since I'm not being directly affected by the problem, I'm not in great position to open an issue. OTOH, if there is an issue already out there, I'd like to star it. -- Mark Murphy (a Commons Guy) http://commonsware.com | http://twitter.com/commonsguy _Beginning Android_ from Apress Now 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 -~--~~~~--~~--~--~---
[android-developers] Re: updatePeriodMillis not working for widget on 1.6
On Fri, Oct 23, 2009 at 6:16 AM, String sterling.ud...@googlemail.comwrote: I'm already using alarms to drive my widget updates. Problem is, alarms are unreliable, especially with the proliferation of task killer apps which abuse the API (see http://groups.google.com/group/android-developers/browse_thread/thread/3f87972d1f99ee81 ). People have these running in the background, then I get complaints that my clock has stopped. Well the underlying problem there is these #$#$#!! apps abusing that API. I so regret having made that available. I should have realized it was a bad idea, because it violates a very basic tenant: one application should not be able to disrupt the behavior of another. Anyway, if possible it would be great if you chould tell your users that their task killer app is causing their problems. And it's not going to just cause problems with alarms: it will unpost any notifications you have, stop services you have running, etc. -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
