On Oct 24, 12:58 am, Mark Murphy 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 thro
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
On Fri, Oct 23, 2009 at 6:16 AM, 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/3f8
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 c
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 wrote:
> Di
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
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
// AppWidgetProvider/Broadcast reciever
@Override
public void onReceive(Context context,
Sterling Udell wrote:
> 2009/10/23 Tom Gibara 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.
2009/10/23 Tom Gibara 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:
-
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 p
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
On Oct 23, 1:54 pm, Mark Murphy 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,
whd?
On Fri, Oct 23, 2009 at 6:19 PM, Sterling Udell
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
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
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.t
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
16 matches
Mail list logo
