Is there a reliable way to determine wether the screen is unlocked (stock(!) lockscreen) and home screen shown?
Is there a reliable way to determine wether the screen is unlocked (stock(!) lockscreen) and home screen shown?
I have an issue with LL and ZW (not other widgets). I trigger animation of panels with ZWs inside on ScreenOn. But ZWs disappear until LL is restarted or animation done with screen visible or long tap on ZW. I tried delaying, but that is not a sufficiently reliable solution.
]]>« [EDIT: template link. See at bottom of this post] (Previous Post)
(Next Post) Maybe stupid idea… »
D5 Creation
< ![CDATA[
Did you tried !LL.isPaused()
?
]]>
< ![CDATA[
KeyguardManager is the solution (if TrianguloYs doesn’t work)
http://developer.android.com/reference/android/app/KeyguardManager.html#inKeyguardRestrictedInputMode%28%29
]]>
< ![CDATA[
Thanks, guys!! Pointed me to the right direction. isPaused works. But Current Screen Resume event is the one I had to use, not Screen On. Works like a charm now.
]]>
< ![CDATA[
12h later: at least in most cases. Have to figure out cause when it still fails.
]]>
< ![CDATA[
Still issues. When I do not unlock to desktop but launch Camera or Google Now from lock, the issue is still there. ScreenResumed is fired, despite LL is not shown.
Pierre Hébert, any idea?
Lukas Morawietz That’s Android Java API, right? How could I use that from script?
]]>
< ![CDATA[
Use bindClass to import that class, then you can use it.
]]>
< ![CDATA[
In this special case, you can just do
LL.getContext().getSystemService(KEYGUARD_SERVICE).inKeyguardRestrictedImputMode();
This will give you a boolean whether the device is locked or not
]]>
< ![CDATA[
Lukas Morawietz Thanks. ScreenResume seems to be sufficient to determine locked-state.
But ScreenResume is also fired in case LL is not visible, i.e. when unlocked to Camera or Google Now or via notification.
In this case the widgets (ZW mainly) still disappear and don’t even reappear i.e. when time changes or other update should redraw then. Only moving container (panel) which contains widget or long tapping them or restarting LL brings them back.
Pierre Hébert Do you think this is an LL or ZW issue? Haven’t found clues this happens with other launchers.
]]>
< ![CDATA[
What about the resumed event of the desktop? (Or the resumed event of the widgets)
It shouldn’t trigger when unlocking to another app…but didn’t try
]]>
< ![CDATA[
TrianguloY That’s what I meant, I attached to the desktop’s Resume event. It’s triggered even when unlocking to other app, not LL.
]]>
< ![CDATA[
Oh, ok sorry.
No idea why.
]]>