Detect device Powered off

  • Thread starter Thread starter davebythesea
  • Start date Start date
D

davebythesea

Hi folks,

As you probably know you can configure a device settings to automatically
Turn off after a period of inactivity. Is there anyway we can monitor within
an application for this change in state? I've been having a look at the
SystemState property in WindowsMobile.Status, but cant see any SystemProperty
which monitors for changes in this state?

Any ideas?

Thanks again,
David
 
The answer is "it depends". The Smart Device Framework has a class for
hooking into the power notification OpenNETCF.WindowsCE.PowerManagement)
when this occurs, but you need to understand that when the device suspends
the processors stops running. This often means that your application won't
get the notification that it went to sleep until after it resumes. In many
cases this is fine, but there's no way to react and do anything before the
device is suspended, nor is there any way to intercept and prevent it.

-Chris
 
Hi,

Thankyou both for your answers. It seems it might not be the best approach
then. The reason I was hoping to monitor for the device turning off was - in
my app I have an autosync routine which periodically checks for new jobs
etc.. using a web service. I noticed that when the device turned off, if I
then turned the device back on, the app remains and all seems well but the
sync did not run. So I assume maybe the underlying GPRS connection is
temporarily turned off when the device turns off? I was just looking to maybe
programtically turn off autosync if the device was abouttop turn off, and
turn on autosync once the device turns back on. Still, its not giving me any
problems as is, but still, you like to think you have some control in a
situation such as this.

Cheers again,
David
 
davebythesea said:
Hi,

Thankyou both for your answers. It seems it might not be the best
approach then. The reason I was hoping to monitor for the device
turning off was - in my app I have an autosync routine which
periodically checks for new jobs etc.. using a web service. I
noticed that when the device turned off, if I then turned the device
back on, the app remains and all seems well but the sync did not
run. So I assume maybe the underlying GPRS connection is temporarily
turned off when the device turns off?
Click to expand...

We have a similar application, and have not had a problem with GPRS
being unavailable if the device goes to sleep. We did find that the
standard timers didn't fire when the device was asleep, so we used the
LargeIntervalTimer from the OpenNetCF Smart Development Framework, and
it has worked well.

We do have to use the ConnectionManager to make sure GPRS is available
if it hasn't been used in awhile.

To figure out exactly what's failing, consider adding a little logging
to your app. For example, if you log an event when your timer fires,
and also log the status of bringing up the network connection, you
should be able to quickly tell where the problem is. Newer versions
of .NET CF have support for logging built in, but we started before
that and use log4net, which we have had good luck with.
I was just looking to maybe programtically turn off autosync if the
device was abouttop turn off, and turn on autosync once the device
turns back on. Still, its not giving me any problems as is, but
still, you like to think you have some control in a situation such
as this.
Click to expand...

If the problem is that when the device wakes back up the autosync
doesn't work well, maybe it would be enough to detect when the device
wakes up and try to fix it from there.

Hope this helps,

----Scott.
 
HI Scott,

Thanks for your reply. Yes I think something similar is happening here with
regards to the timer! On some occasions I think it is being disabled when the
device turns off, and not going back to a status of enabled on device turning
on. I'll definelty be looking towards bolting in some event logging as that
will really help in scenarios such as this where its difficult to actually
know whats going on in the app. Thanks a lot for your tips and shared
experience!

Cheers,
Dav
 
Back
Top