There are methods lock() and unlock() in UIATarget, but they were deprecated and don't seem to work any more (calling them gives undefined function error).
There is lockForDuration() method, but it does not return until screen is unlocked.
If I set a passcode for screen unlock, then after lockForDuration() is returned (of course without being able to unlock the screen), I can dump lock screen elements with logElementTree() function. But at the same time I can't interact with them.
Is there a way to overcome these obstacles?
Related
I've taken over a project that handles which screen to show first in the "applicationDidBecomeActive" function inside the AppDelegate. This has been causing problems because whenever the app asks for a permission sometimes, not all, it will trigger this block of code and send the user to the incorrect screen. I'm not sure what to do since I've never encountered this before. Any ideas why this is occurring or ways to circumvent this? I've tried adding a flag variable, however, that doesn't seem to work consistently because it looks like it gets un-set before the applicationDidBecomeActive is triggered.
When system notifications such as Permissions are presented, the application is sent to background, or becomes "inactive". When the Permission notification is dismissed, the application becomes "active" again. This would explain why didBecomeActive is triggered.
https://developer.apple.com/documentation/uikit/uiapplicationdelegate/1622956-applicationdidbecomeactive
I've taken over a project that handles which screen to show first in the "applicationDidBecomeActive" function inside the AppDelegate... Any ideas why this is occurring or ways to circumvent this?
The simple answer is: don't do that work in applicationDidBecomeActive(). As you've seen, the application can become inactive and then active again while the app remains in the foreground, so that's not the right state transition for what you're doing. Identify the app state transitions where you really do want to choose a screen. For example, you might want to do it when the app launches, and also when it transitions from background to foreground, so you could use application(_:didFinishLaunchingWithOptions:) and applicationWillEnterForeground(_:). (Obviously, you don't want to put the same code in both places, so put it in a separate method and just call it from those two methods.)
Apple has a document that covers this very topic: Managing Your App's Life Cycle. There's also a lot of information on application states on the UIApplicationDelegate reference page. Both documents include helpful state transition diagrams and descriptions of what the various states mean.
As a solution; you can use the applicationWillEnterForeground(). It's being called before the applicationDidBecomeActive() and not being triggered by permission request.
I am currently writing an app, and records some info (eg GPS), even if screen is off (ie its screen has timed out in sleep mode).
It performs a setState() every so often to update the Widgets.
However, if the screen is asleep/inactive, I'm not sure there is a need to call setState(), or certain other cpu intensive actions, and may be better to preserve battery by not calling it ?
So, I am wondering if there is any way to detect if the screen is off, and hence not call setState..
eg in pseudocode
if( checkScreenIsOn() ) { setState((){...})}
I'm unsure if some event is triggered when the screen goes off that flutter sees. Also if things like GPS, I'd like to record normally when the screen is off (I'm currently using a listener), but not update the display. Does GPS go into a different mode, and any way to stop that if so ?
StatefullWidget have a mounted flag mounted property
Instead of if (checkScreenIsOn()) just do if (mounted) setState((){...})
If you want to know screen state you must use a MethodChannel to communicate with native api, eg. https://pub.dartlang.org/packages/screen_state
I'm dealing with a strange situation I want to debug in my Windows Phone 8.1 app, and I'm not sure in which moments OnNavigatedTo is called.
Obviously, it gets called (and I've checked tracing it with the debugger) when you navigate to the view normally.
My doubt arises in other point I want to check, let's call it "You wake up your application and the screen was shut off".
My question is: When you turn on the screen, and you swype the screen protector away, is "OnNavigatedTo" function called or not?
According to some manuals I've read somewhere else, it should.
According to my Debug.Writeline traces, it seems it doesn't.
I need to check some condition and execute some code before/when the view appears, and I'm unable to do it properly.
PS: Does it exist some other alternative event I should use to deal with "This view is becoming visible/focused after you turn the screen on" situation instead of "OnNavigatedTo" ?
Thanks in advance.
In Windows Phone 8.1 Runtime (Store apps) OnNavigatedTo is called only during navigation. It's not called after resuming from suspension - you can read a reference here at MSDN:
before Suspending event, the OnNavigatedFrom event is being called, but when you Resume, the OnNavigatedTo is not called
In your case when you lock the screen, the app is suspended, after you resume OnNavigatedTo is not called. If you look for some events which may be called - take a look at Window.Activated and Window.VisibilityChanged events.
The other case is that when you debug your app, your app won't be suspended, you will need to test it via Lifecycle events tab.
I am building a word game and I want to hide the board when application is suspended?
the code looks fine however it givs a strange behaviour!!,
when I suspend the app nothing will happen but when i resume the application then the board will hide!!
local onSystem = function( event )
if event.type == "applicationSuspend" then
print("suspend")
board_group.alpha = 0
end
end
Runtime:addEventListener( "system", onSystem )
Note: you might wonder how do I know how the application looks when suspended?
the answer is: by pressing the home button twice.
example
SpellTower in normal state
https://dzwonsemrish7.cloudfront.net/items/430k0c0b0y0b413d0b42/Image%202012.11.12%208:08:24%20AM.png?v=4822f549
SpellTower after pressing the home button twice
https://dzwonsemrish7.cloudfront.net/items/280a1y0r2U3W321y1B2z/Image%202012.11.12%208:08:31%20AM.png?v=09c37567
you can see how they are hiding the letters, this is exactly what I want to do for my game, the only difference is i am using Corona SDK
When you do board_group.alpha = 0 you only has set a variable, the result will only take effect after a screen update.
But since the application is suspended... it won't update! So, changing any graphics on applicationSuspend don't work.
I believe the reason is because the application is not considered as suspended. In normal objective c programming it means that applicationWillResignActive is called when the user double clicks on the home button. So what you want to do is to add that code for this part.
Here is a flow of events:
http://www.cocoanetics.com/2010/07/understanding-ios-4-backgrounding-and-delegate-messaging/
Corona seems to have these events:
"applicationStart" occurs when the application is launched and all code
in main.lua is executed.
"applicationExit" occurs when the user quits the application.
"applicationSuspend" occurs when the device needs to suspend the application such as during a phone call or if the phone goes to sleep
from inactivity. In the simulator, this corresponds to the simulator
running in the background. During suspension, no events (not even
enterFrame events) are sent to the application while suspended, so if
you have code that depends on time, you should account for the time
lost to an application being suspended.
"applicationResume" occurs when the application resumes after a suspend. On the phone, this occurs if the application was suspended
because of a phone call. On the simulator, this occurs when the simulator was in the background and now is the foreground application.
So my guess is that you have to implement it outside of the corona API.
According to the corona documents you can implement them in the delegate:
You can intercept UIApplicationDelegate events via your implementation
of the CoronaDelegate protocol.
This protocol conforms to the UIApplicationDelegate protocol. Corona's
internal delegate will call your protocol's method if it is
implemented.
Please keep in mind the following:
Methods that Apple has deprecated will be ignored.
In most cases, your class' version will be invoked after Corona's corresponding version of the UIApplicationDelegate method. There is one situation in which your version will be called before.
In situations where the app is about to suspend or go to the background, your method will be called before Corona's version, e.g.
applicationWillResignActive: and applicationDidEnterBackground:.
http://docs.coronalabs.com/native/enterprise/ios/CoronaDelegate.html
But this is just a guess. Hope it helps!
Edit:
I was thinking, something really simple you could do is catch it outside and present a "pause" screen, then just hide it when the application enters foreground.
So if you can't do that (for now), one other option is to save application state when the application is about to terminate, and then set UIApplicationExitsOnSuspend = true in your plist file. This will cause the application to exit instead of suspending, which will avoid any screenshots, effectively "hiding" the board, etc. The downfall is, the app will have to read the session state when it launches again... this is only useful if your application can be designed to actually exit without losing your state, and is quite honestly, a little extreme. That said, it may be the only way to effectively do what you're trying to do.
Other ideas would be to see if you can add a large black layer to the screen, even though the application is suspending; perhaps this will somehow trigger an internal screen update by natively setting setNeedsDisplay. Also, instead of modifying the alpha, you might consider temporarily removing all of your layers and see if that has a similar effect.
I have an app which requires input when resuming from inactive state (a security view). When resuming from inactive after some time, the UI will freeze for 1-5 seconds before entry can take place on the security view. Following this with Instruments, I see some views have been dealloc'd when memory is needed for other apps. Works as it's supposed to.
The UI freeze appears to happen when lots has been dealloc'd, and the app is reconstituting the dealloc'd views. I'm seeing viewDidLoad's fire etc. Trouble is, the security view has already appeared, giving the user the expectation they can enter their passcode. The app is temporarily unresponsive, which is disconcerting to the user.
I would like to deal with this better, perhaps displaying the security view only when the app is ready for user input.
What's a good way to do that, or is there another suggestion?
Have you included a screenshot of this view as the launch image? It's possible that while the app is loading, it's just showing this screenshot, and giving the impression that the app is frozen, as it won't allow user input on the screenshot.