DroidForums.net | Android Forum & News
This is a sample guest message. Register a free account today to become a member! Once signed in, you'll be able to participate on this site by adding your own topics and posts, as well as connect with other members through your own private inbox!
myLock in Market! Skip the Lock Screen!
- Thread starter Martin030908
- Start date
Greetings all. the myLock WIDGET lockscreen has hit functional beta. It's completely awesome. It might not be perfect, but why not just enjoy your free incredible lockscreen instead of complaining.. lol
If you're too lazy to get it from the market, or can't, be my guest: http://mylockforandroid.googlecode.com/files/myLock_widgetLockscreen_r2a.apk
PS: I need some positive reviews to get people's buy in to check it out.
If you're too lazy to get it from the market, or can't, be my guest: http://mylockforandroid.googlecode.com/files/myLock_widgetLockscreen_r2a.apk
PS: I need some positive reviews to get people's buy in to check it out.
Last edited:
Bump for myLock auto unlock v1.3/r3b updated to market.
The much preferred wallpaper mode hiding the lockscreen visuals is available again as an option. No other major changes, You just might notice faster or more stable performance overall due to some improvements to the overall lockscreen exit lifecycle.
The much preferred wallpaper mode hiding the lockscreen visuals is available again as an option. No other major changes, You just might notice faster or more stable performance overall due to some improvements to the overall lockscreen exit lifecycle.
Thanks for providing (and announcing) that option. I was starting to think I'd have to hold on to my old version and never update myLock again.
I also have a question for you -- is it possible to make a "helper" app that toggles the myLock Basic app without going to any sort of application screen, and does nothing else?
The way I'd want to use it (and perhaps others would, too) would be in conjunction with Setting Profiles. For instance, I'd tell this "helper" app to run when my Home Profile is activated (thereby toggling myLock basic on), then run again when my Home Profile is deactivated (thereby toggling myLock basic off). If you think that's a worthwhile goal and can think of another way to do it, that of course would also be awesome.
By the way, I've also tried the myLock complete version that lets you put widgets on a lock screen and it's definitely pretty cool. I would like the option to lose the clock widget, since the notification bar already tells me the time. And I'm sure you're aware that the bottom couple rows of widgets are lost when in landscape. If it weren't for myLock basic, I'd probably use Complete a lot more, though there are situations where Complete comes in handy.
Yes, I am actually coding a toggling app right at the moment. The issue with profiler is that it ends the myLock process and then we're stuck in the same state we were when it was closed.. all the flags that tell settings the process was active are still left like that.
the toggler APP would simply flip the switch so that instead of killing it, the app sees that the flag shows active, and throws a stop service out to the process. it closes itself cleanly so that you can run the same app to restart it. All I have to do is copy the code the widget runs and make it an App icon. you also need a way to restore security in that situation, so there is an idle_timeout command I can also send which actually treats it like security existed before myLock started, then closes out while restoring security.
My plan is to release this in an addon download. This addon is built for the profile thing and also has a locale plugin for both of these functions
the toggler APP would simply flip the switch so that instead of killing it, the app sees that the flag shows active, and throws a stop service out to the process. it closes itself cleanly so that you can run the same app to restart it. All I have to do is copy the code the widget runs and make it an App icon. you also need a way to restore security in that situation, so there is an idle_timeout command I can also send which actually treats it like security existed before myLock started, then closes out while restoring security.
My plan is to release this in an addon download. This addon is built for the profile thing and also has a locale plugin for both of these functions
I'm not sure I could allow people to pay a buck for it as the only way to get it. I need to have a starting point that's lower. Since the whole app is already free, why not have a few price levels for people to pitch in as they see fit. $0.50 base, if you really like it you could pay $2 for exact same. I have been thinking those who want locale integration would be the most supportive as locale is already an app they have to invest in.
Locale/profile integration has probably been the number 1 request I get, then closely followed by the request to make alternate ways to answer the call since the lockscreen style prompt is a pain (which I am also working on, I now have code that will let me put a button on screen or let any side key accept the call)
As it turns out the market forces 99 cents as the minimum. So I will make it 99 cents, and offer a plus one for 5 bucks that's the same.
I need someone who has locale to help me test if the plug in actually works... please email me to mylockandroid at gmail and i will email you the apk
Locale/profile integration has probably been the number 1 request I get, then closely followed by the request to make alternate ways to answer the call since the lockscreen style prompt is a pain (which I am also working on, I now have code that will let me put a button on screen or let any side key accept the call)
As it turns out the market forces 99 cents as the minimum. So I will make it 99 cents, and offer a plus one for 5 bucks that's the same.
I need someone who has locale to help me test if the plug in actually works... please email me to mylockandroid at gmail and i will email you the apk
Last edited:
Martin030908
Super Moderator
Hey Petjakob.... I've been mia but I'm back around now.
You interested in doing a lil interview type deal for Droidblog?
I'll do a nice write up for ya!
You interested in doing a lil interview type deal for Droidblog?
I'll do a nice write up for ya!
Thanks for the bump. Want to email me about that?
And if anyone wants to go legit on donation you can now make an official donation via market for the myLock plus addon. What it is - just a lightweight easy package, no need to uninstall or redo anything--- comes with access to all addons forever with VIP status. Right now there is locale toggling and the idle lockdown timer function. call customization features and a lot more is planned for separate addons, all will be integrated into the plus package. there might be a point where some feature or mode will only be in plus but we aren't that far along yet. want to keep all basic functionality as always free and give really cool bonuses to those who go plus. so what are you waiting for? myLock has been there for you, now you should be there for it.
And if anyone wants to go legit on donation you can now make an official donation via market for the myLock plus addon. What it is - just a lightweight easy package, no need to uninstall or redo anything--- comes with access to all addons forever with VIP status. Right now there is locale toggling and the idle lockdown timer function. call customization features and a lot more is planned for separate addons, all will be integrated into the plus package. there might be a point where some feature or mode will only be in plus but we aren't that far along yet. want to keep all basic functionality as always free and give really cool bonuses to those who go plus. so what are you waiting for? myLock has been there for you, now you should be there for it.
Last edited:
Not that anyone here should care a whole lot but if you have any sad sad friends who haven't jumped on board droid and are stuck on 1.5/1.6, I've developed a port. I have published the beta 1.0 in the market today so they can enjoy auto unlock instead of having to push menu
I dont know if it works on sense or motoblur.. Gonna try to get my coworkers that have devour/eris to help me test and I'll report back.
I dont know if it works on sense or motoblur.. Gonna try to get my coworkers that have devour/eris to help me test and I'll report back.
I just paid for and DLed the $5 option.
I am still loving this app. The best thing about it for me...it just works. It does exactly what I want it to everytime.
-Mike
Last edited:
The often requested options for working around Slide to answer and protection from face dialing when prox sensor is being stupid is about ready.
myLock phone tools coming soon, features call prompt (onscreen accept call button), option to let camera button accept the call when prompt is enabled, and the option to turn on the touchscreen lock during calls.
myLock phone tools coming soon, features call prompt (onscreen accept call button), option to let camera button accept the call when prompt is enabled, and the option to turn on the touchscreen lock during calls.
Last edited:
Pretty sweet. What kind of testing are you looking for? My first impressions, which are probably no surprise to you:
It takes a couple rings for the button to pop up, and I guess the camera button doesn't really work until the button pops up. Obviously it would be better if one or both were instant (or nearly-so), though I can imagine the difficulties with that. It seems like half the time it takes a few rings to answer with the slider, so I can totally live with the delay if necessary.
However, there were a couple times when the Accept button never did pop up. Which isn't a showstopper since I can always just slide-to-answer instead.
Do you think you'll eventually be able to add a button to decline? The back, then slide-to-decline is perfectly workable if that's not possible. You might also think about adding some camera button customization to allow a decline. Maybe a long-press of the first stage of the camera button? That would seem to be different enough from the short-press of the second stage that currently answers.
I was quite pleased that the camera button stuff worked for me. I have Button Shortcuts set up to toggle the brightness on my Droid, and I was worried that when I hit camera button to answer or to cancel the touchscreen lock, I'd be toggling brightness instead. Don't know how much of that is Android event handling versus your programming... but very nice to know I can still use Button Shortcuts at all other times.
One note about that though -- the way you have the menu set up currently, I thought I'd be able to use the camera button without the Accept button showing up (which would be nice to avoid pocket answering), but that didn't seem to work. So ideally I'd be able to answer using the camera button even without the Accept button showing up. But until/unless you're able to make that work, I guess you should make it so you can't check the camera button box if the Accept button box is unchecked.
I'm also wondering about the touchscreen lock. Any way to provide an additional option to make it come on as soon as the phone is answered? The way it is now, it seems like there's still potential for accidental hangup if the proximity sensor never activates.
It takes a couple rings for the button to pop up, and I guess the camera button doesn't really work until the button pops up. Obviously it would be better if one or both were instant (or nearly-so), though I can imagine the difficulties with that. It seems like half the time it takes a few rings to answer with the slider, so I can totally live with the delay if necessary.
However, there were a couple times when the Accept button never did pop up. Which isn't a showstopper since I can always just slide-to-answer instead.
Do you think you'll eventually be able to add a button to decline? The back, then slide-to-decline is perfectly workable if that's not possible. You might also think about adding some camera button customization to allow a decline. Maybe a long-press of the first stage of the camera button? That would seem to be different enough from the short-press of the second stage that currently answers.
I was quite pleased that the camera button stuff worked for me. I have Button Shortcuts set up to toggle the brightness on my Droid, and I was worried that when I hit camera button to answer or to cancel the touchscreen lock, I'd be toggling brightness instead. Don't know how much of that is Android event handling versus your programming... but very nice to know I can still use Button Shortcuts at all other times.
One note about that though -- the way you have the menu set up currently, I thought I'd be able to use the camera button without the Accept button showing up (which would be nice to avoid pocket answering), but that didn't seem to work. So ideally I'd be able to answer using the camera button even without the Accept button showing up. But until/unless you're able to make that work, I guess you should make it so you can't check the camera button box if the Accept button box is unchecked.
I'm also wondering about the touchscreen lock. Any way to provide an additional option to make it come on as soon as the phone is answered? The way it is now, it seems like there's still potential for accidental hangup if the proximity sensor never activates.
Last edited:
-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.
-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.
What I've found is that the back button is creating reject in the call screen. But I'm not sure if this is unique to emulator. never tried it on the droid.
"04-28 17:43:39.985: DEBUG/InCallScreen(200): onBackPressed()...
04-28 17:43:39.995: DEBUG/InCallScreen(200): BACK key while ringing: reject the call"
-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.
-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.
UPDATE: This workaround works perfectly. Seems to launch it immediately after the phone screen finishes drawing
-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.
What I've found is that the back button is creating reject in the call screen. But I'm not sure if this is unique to emulator. never tried it on the droid.
"04-28 17:43:39.985: DEBUG/InCallScreen(200): onBackPressed()...
04-28 17:43:39.995: DEBUG/InCallScreen(200): BACK key while ringing: reject the call"
-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.
-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.
UPDATE: This workaround works perfectly. Seems to launch it immediately after the phone screen finishes drawing
Last edited: