-Yes, I can add the option to launch touch lock immediately when call starts. Not all users would want this depending if they would see it as unnecessary when placing calls. Simple scenario, dialing voice mail, user would have to dismiss the lock then launch keypad and dial password. The logic is the lock goes on when the screen goes off, so the best way to force it on is shut your screen off with the power key before you put it up to face.
Yeah, I definitely agree making it an option would be the way to go for this feature. Nice to know about the power button workaround in the mean time
-It might be possible but we haven't yet figured out how to cause reject call. We're using example code from the auto answer app which just send the system the same response a wired headset button would to accept the call. It makes sense, there just doesn't seem to be an equivalent for ignoring the call that I've found yet. I searched pretty extensively earlier when requests were first rolling in for this functionality and turned up very little.
Ah, makes sense. It's not something that really bothers me since I pretty much never decline calls, but it's the sort of petty thing that I could see being complained about on the Market...
-To officially "get" incidental button presses, we have to put some kind of window on the screen. There is a way of requesting to get key events even without the window but I can't figure out how to make it work. We're still subject to timing requirements as the call launches until I can bullet-proof a non-window button event setup.
Interesting. I won't hold my breath on this feature then, but I'll be pleasantly surprised if you figure it out. Like I said, my main concern is pocket answering without even realizing the phone was ringing. I wonder if in the mean time you give the user the option of answering with a single or double tap on the Answer button? I'm thinking a double tap would be much more unlikely to happen on accident.
-Lastly, on timing --- the system will notify myLock that a call is ringing/starting/stopping pretty much immediately, as soon as it knows. We have to wait a second or two or else our prompt gets on screen first since it is very lightweight, it gets cancelled out as the phone finishes coming up.
I could provide the option to reduce the delay, however that would cause you to see more cases where you have no prompt due to phone taking too long to come up. With this aspect it was easy to settle on the idea of longer is ok, since in real situations how fast are you to draw the phone and fire?
The solution to this might be to go ahead and launch a dummy prompt immediately, that would notify us when the phone cancels it. Then we fire the real one. I'll start chipping away at that possibility and let you know.
Sounds like an idea that could work. Of course, my suggestion for a temporary fix would be for the user to set the time until pop up, with a very clear warning message that making it too short might cause the pop up to never show up.
