Re: Device won't idle time out when my app is running

Blackberry essentially requires you to use push e-mail. Unless you have
access to a push e-mail account or are willing to set up Exchange server,
etc., I'd guess that most people running Windows Mobile are not using it.
It's just not that valuable to have the device learn about an e-mail the
moment the server receives it. You can always set up to check for new
e-mail every five minutes, so your maximum delay is 5 minutes. That seems
adequate to me...

Paul T.

"Scott Gifford" <sgifford@xxxxxxxxxxxxxxxx> wrote in message
news:lysl3h5r11.fsf@xxxxxxxxxx
"Paul G. Tobey [eMVP]" <p space tobey no spam AT no instrument no spam DOT
com> writes:

No code is running while the device is suspended. None. No idle
code, no driver code, nothing. Device vendors may set their devices
up such that certain interrupts bring them out of suspend and
therefore allow network connections to be kept alive (or phone calls
answered), but you can't control their hardware design.

Right, my code is woken up from suspend mode by timer interrupts or
network interrupts. My GPRS radio appears to wake the device up when
a packet is received. I believe most GPRS radios will do this;
otherwise I don't see how push email could work. Keeping a TCP
connection open doesn't require any processing unless data is being
sent, in which case the device is awake by definition, or received, in
which case the GPRS radio just woke it up. So it seems plausible that
a network connection would stay open across a suspend, and my
application could work even if it were periodically suspended.

I wouldn't know what the characteristics of the AUTOD mail are, but
*I* don't use it and I doubt that 'most' people are using it.

Ah, OK, I don't use it either (I'm very old-fashioned about my email),
but I assumed most people buying a Windows Mobile phone used it for
push email, just like most people buying a Blackberry use it for push
email.

I'm sure that the mail code does *nothing* with the power state.
That's up to the power manager, as I mentioned before, and
applications should generally stay the heck out of the way, unless
they need to keep the device awake.

I would expect so too, and if you can't count on a network connection
being reliable across a suspend, than something must be keeping the
device out of suspend mode. Either the device does it, the network
driver does it, the application does it, or else network connections
are reliable across suspends. At any rate, my only point was that if
staying in idle mode instead of suspend mode was good enough for
Pocket Outlook, it's probably good enough for my app.

If the device is configured by the OEM to wake on serial I/O or
network I/O,

It actually doesn't wake up from Idle mode, but it won't go into idle
mode while these devices are active. Once I get it into idle mode it
will stay there succesfully until the user wakes the device.

there's nothing you can do but reduce your frequency of use or
reconsider the usage model.

Well, or hack something together to work around the behavior and
perform work similar to the power manager. There are definitely
downsides to this approach, but so far it looks to me like the best of
several very poor options.

If you're doing navigation with your GPS, it seems to me that the
user would expect the device to be on all the time. If the battery
life is too low, plug it in to some power supply.

Our usage model is publishing location data to the network, to enable
various applications like location-based social networking,
cooperative navigation, being notified of nearby people, places, or
events your are interested in, and so forth. So it relies on the data
being published frequently and unobtrusively while the device is in
your pocket.

That might not be the case for network, but I don't know enough
about what you're doing to make an educated case as to what makes
the most sense. It seems to me that constantly shifting power
states

Ideally, I would only be shifting power states at the same times the
power manager would shift states, so it's only the times when my
behavior differs from the power manager's that will be annoying.

is going to be more annoying than having the battery only last a
day, instead of two.

The problem is that without idling the device at all, it lasts about
12 hours, which is unreasonably low. It also leaves the screen on all
the time, which makes it prone to accidental button presses and I
think would be disconcerting to a user. Idling the device, it lasts
about 18 hours, which approaches reasonable. I was hoping suspending
the device could get it to 24 hours, which is probably just getting to
reasonable.

From what I've read, it sounds like the SmartPhone's "always on" power
model might work much better for our application, and I hope to have
my hands on one soon to see.

Thanks once more for your help and insight!

----Scott.


.