First of all I'd like to say sorry in case my question is dummy, I'm really new to iOS and what to understand how thing are going on. Imagine such a situation - user taps on home button and the app starts to collapse, but immediately after taping on home button user taped on some UI element. So, I'm wondering how the iOS will handle this? I tried to do some tests using breakpoints, but since it just test I can't be 100% sure. It seems that if the UI interaction event will happen before the system will call willResignActive then the event will be fully processed and if the system will call willResignActive first, then the even will be discarded and won't be handled at all. Is this correct, or I missed something? Thanks
First, why do you want to use this in your app? If a user presses a button exactly in this time, it's okay that the action is not handled.
The only thing you have to keep track of is that whenever the button gets pressed and let's say you store a file without a completion handler it could be that you present an alert which is saying that everything went well but you actually not saved the file because the user left the app in this time.
But since you're never doing critical actions without completion handlers, in my opinion, there's no need to make sure that this doesn't happen.
If I got you wrong, just comment!
Related
is it possible to prevent the app from closing when my app asks for a fingerprint and the user presses the home button instead of only let the finger rest? I know and understand that it shouldn't be possible everywhere else, but it would be nice if the app wouldn't close when asking for the fingerprint.
It is not ever possible to change regular system behaviour, even though some users might press too hard and go back home that is the behaviour that everyone expects, want to go home, press the home button and it always works
This is not possible, what you are trying to do is getting out of the scope of your application and change the behavior of the device. Apple won't allow it, ever.
They might change the behavior if they think it's better to handle it like that, you can send them a message. But they'll probably never do that as they are killing Touch ID for the sake of Face ID.
I'm not used to working on native iOS code. So excuse me for missing something obvious here.
The issue I'm having right now, is when a user is holding down a touch, and then before releasing, a native popup appears (low battery, timer, ...), this does not fire a call to touchesCancelled.
Instead, it fires a touchesEnded when the user stops touching the screen.
However, this touchedEnded was a user reaction to the popup, not an active decision for using the app, and this might lead to incorrect and frustrating behaviour.
As far as I can tell, the touchesCancelled should be fired when focus is lost, but it seems focus is not completely lost in this case.
I am wondering if there is any other way to detect that a native popup was opened, and have my app act like touchesCancelled was fired, and avoid unintentional behaviour.
I've tested some apps from Apple and they have the same (in my opinion) wrong behaviour. So maybe it's something I have to live with, but I want to reach out to more experienced native iOS devs, and be sure of it.
Thanks,
Sascha
I returned back to this issue today. I found out that when a native popup appears, there is a call into the app to applicationWillResignActive and applicationDidBecomeActive respectively.
In my solution, at the moment applicationWillResignActive is called, I basically make the app act as if there was a touchesCancelled for each touch that had a began without an end or cancel. When the actual touchesEnded gets called, it gets ignored as it no longer matches a touchesBegan in my app.
It feels a bit like jumping hoops, but this does the trick quit nicely for me.
This is my first post here on stackoverflow so forgive me for anything I'm doing wrong.
I'm making a kind of guide to the users without any computer knowledge of my application where I show him how to use it by signalizing what he should do, more specifically where to click. I want to that by moving a "fake" cursor to the button and simulate a click, and here is where I got my problem, I have to simulate just the animation of the click, and not the event itself but I couldn't find a way to do that, can anyone help me?
What you're describing is exactly what WH_JOURNALPLAYBACK is for. It populates the message queue with the mouse and keyboard messages you want to occur, and the OS interprets them. In your case, activate the playback hook and perform the mouse events necessary for performing a click.
In preparation, you'll probably want to use WH_JOURNALRECORD to discover what messages you need. Once you have them, you can probably winnow them down to a reasonably sized list prior to shipping your product to customers. (In particualr, you'll probably record many more mouse-move messages than you really need.)
In your button's click handler, check whether playback is active. Only perform the rest of the event handler when playback isn't active. That way, your program will behave just as though the button were clicked (including any animation), but it won't execute the real event code.
Im implementing touch ID to "unlock" my app, and im not sure if ive run into an apple bug or something i need to handle myself. If i tap the Home button and minimize my app before evaluatePolicy can load the Touch ID prompt, it appears over the home screen.
![not enough reputation to display screenshot, so heres a link]https://www.dropbox.com/s/zrhc60lx87ze7mt/IMG_0016.PNG
Successful/failure/cancel evaluation of this policy does nothing, but when i re-enter the app and cancel it again, touchID seems to be disabled forever until i restart the phone.
Anyone else running into this issue or have an ideas?
P.S. Theres an open radar where errSecUserCanceled is never returned from a cancel button tap, so right now i fall into my errSecAuthFailed case, which could also be the cause.
Answer is no. It should not be be displayed, when minimized.
The problem is IMHO that the code segment is being called again from your app when it goes to the background. For example loadView , didLoad and so on.
Try moving the code, that calls the authentication somewhere else in the program (different method).
For example, if your code uses a textView to enter password, you can implement the authentication within keyboardWillShow or similar.
Hope it helps.
I have a state-transition problem with NSTimer, of which I find difficult to keep track of during applicationWillResignActive / applicationDidEnterBackground, according to the context of my app.
I was wondering if it might not be a better idea to utilise UILocalNotification, especially given it's background/inactive firing. However, I wanted to know whether we have the ability to provide a custom method to UILocalNotification, of which does not present a dialog box (would damage the whole point of my app). In effect, i'd like to only make use of the timer-fire capabilities of UILocalNotification, and handle the fire event with my own method which does something very "undialog-friendly"
Have checked the ADC docs and it alludes to the dialog being presented every time.
Any advice you can give on this would be appreciated.
thanks
sc.
The dialog box is presented when your app is in the background. But it is not presented when your app is running - instead your app is free to deal with the notification however it sees fit. So it would be perfectly possible to hook it up to a custom method of your own making.
The main reason for this behaviour is a user may not want to go into your app if it's in the background. Of course, with iOS 5 the notification may not be a dialog box - it could be one of the new notification styles.