myLock in Market! Skip the Lock Screen!

[rjax]

-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.

By the way, there are couple threads outside the Apps section where this sort of feature has been asked for. Would you mind if I directed people to this thread, or would you want me to wait until it's been tested more and put on the Market?

 

[petjakob]

Yeah, get me some testers. I just uploaded the revision, we need to try this workaround on device. i dont have my 2nd phone on hand to do some calls. lol

 

[rjax]

So I tried the new version, and it's got a problem. Regardless of whether or not I have the box checked to enable the lock screen, the lock screen comes up while my phone is ringing, meaning I have to press the camera button before I can do anything.

 

[petjakob]

this seems to be one of the only cases where i get differences in device behavior and emulator behavior, when i'm trying to track the state of various screens i get random differences in the order and sometimes some of the states dont occur in the emulator.

working on tightening it up.

i don't think it's the call guard unless some kind of error left the screen mediator running after the end of a call (it's supposed to close that). try unin/rein and see if that still happens

 

[petjakob]

I've worked the workaround as absolutely and completely far around as it can work. and the end result, is that it still takes almost exactly 2 full seconds, every time, in the emulator at least. defeats the benefit of the speed of the workaround. but, it might have bolstered the overall reliability of getting the prompt onto the screen even with that slight delay.

I'll have my incredible in hand by monday-ish so i can get some more consistent realtime debugging going.. can't make any more progress till then.


For now if you still want to run any additional test for me, download the revision

http://mylockforandroid.googlecode.com/files/myLock_phone_tools_r1a.apk

 

[rjax]

So I did a little more testing (Google Voice is very useful for this, by the way... From the mobile web page, I can have Google call my phone). The lockscreen issue I mentioned above looks to be fixed in the r1a revision.

Thanks for the effort on the delay workaround. At least as of right now it seems to be causing more trouble than it's worth, especially since like you said it's not really resulting in a faster appearance of the button. For most of my test attempts, this revision worked perfectly. However, I saw a couple things I didn't see in the original release, both of which I'm pretty sure are the result of the attempted workaround.

One bug I experienced a couple times was the accept call button appearing on the screen first. The good news is that I can hit the accept call button, and the phone is answered. The bad news is that even if I wait, the normal Caller ID screen never pops up -- instead a gray background with the accept button just stays up until the call is missed or I hit the accept button, or the back button. (Hitting the back button does take me to the Caller ID screen.)

I only had one instance where the accept button never showed up, so that's a nominal improvement, at least, though it's not clear if that trend would continue.

Also, I had one Force Close, which I never had had on any of the first two revisions. The FC was for the dummy process (I know because the dialog box had the word "dummy" in it.)

So yeah, so far the first version has been the most stable so far for me.

 

[petjakob]

Usually the best fixes are forged in the hours of determining an elaborate one that does no good, incubates the finding a 5 second fix that would have worked in the first place before spending hours on the elaborate one.

the fix wasn't to utilize the dummy prompt... it was to make the real prompt smarter.

i did a few tests with it today and it looks like the last bugs we have are just some checks to ensure the prompt doesn't ever remain in such a way as to A) cause media to start playing if you are pressing camera to dismiss touch lock or B) remain on screen incorrectly after missed calls

 

[petjakob]

I think this beta is about ready to have the market-fork stuck in it. :icon_ banana:

I'm for now tuning the options so you can have the camera accept only enabled. If you do this, the prompt will appear but without onscreen accept button. It will hide the button so you have no risk of accidental touchscreen answer. Sort of locking action from there to camera.

With that I think I'll model the prompt a bit more after the one we see on the incredible, with buttons that sit about where the sliders would have been.

I also fixed the missed call case.

 

[petjakob]

reserved for update details