phone app development notes.

[sistawendy]

1. When a Windows Mobile phone idles, none of the threads in your app will get any cycles even if they're waiting for timers unless you tell the OS you really want to run your thread in the background no matter what (System.Thread.IsBackground, for you .NET folks). I wouldn't be surprised if this behavior also applied to any Windows installation that's configured to save power that way, i.e. laptops, which I've never developed on.
2. I haven't found an obvious .NET way to grab the screen and the soft keys if the device is locked. Yeah, this may be a duh because such a feature would weaken the lock, but I figure if the telephony and alarm apps can grab the phone, why can't I?
3. Speaking of device locks, some kinds of input event handlers appear to intercept them. I don't think that's right.

Comments

[darkmane.livejournal.com]

You can grab the screen when the phone is locked but you have to get your code signed by MSFT. And I'm pretty sure the code has to be C++ not CLR.

Don't run in the background. It shortens battery life, can drive up data usage and slows the machine down when everyone is running in the background.

[sistawendy.livejournal.com]

The app in question is a timer. I don't think I have a choice. The good news here is that it isn't using the network, or even much CPU.

I believe you about the C++ native. Some juicy bits of the mobile SDK are native only, at least in v6.1. How did you find that out about the screen grab?

[darkmane.livejournal.com]

From when my old team was writing their own password app that was more secure than the default mobile password app.

[neuro42.livejournal.com]

what are you developering?

[sistawendy.livejournal.com]

An egg timer. With a repeat mode! Really. I needed one. See previous entry for the squee of when I thought it was working. :S

[neuro42.livejournal.com]

I'd really like to bend your ear sometime in great detail about languages, toolchains, emulators, and suchlike.