I have a simple iOS app that I am developing that needs to be "restarted" or "reset" after a user performs a certain touch action and a "reset" button appears. The workflow of the app goes something like this:
User holds a certain area of the screen
User lets go of the screen and quickly touches another area
The time it took for them to let go and touch the next area is displayed in a UILabel.
A reset button appears in which the user presses to try again.
Steps 1-3 work perfectly, but currently the only way I have to "reset" the app is to exit with the home button, open the multi-tasking menu and manually close it and re-open it.
I know this has to be able to be done as I 've seen it in many apps. I just can't find much help with the developer docs on it.
Thanks!
You can kill the app with a call to abort(). There's no way to start it after you killed it, though.
Perhaps you can schedule a local notification before killing the app that prompts the user to open it again.
You should probably just create a method that resets all of your variables and then calls the methods that begin steps 1-3. To have the button appear, make a UIButton IBOutlet to attach to the reset button, and then hide it in viewWillAppear like this:
[myButton setHidden:true];
To then show the button later, use the same button but set the value to false instead of true.
You could try removing your view controller from the application window and releasing it then instantiating a new instance of that view controller and adding the new instance to the window as the root view controller.
Since I'm assuming your view controller is where most of your "setup" code for your app is occurring this should effectively reset the app without having to write a lot of extra code. In addition, having the ability to instantiate a new instance of your view controller class is kinda the point of having it to begin with.
You can sleep your application for specified time interval.
+ (void)sleepForTimeInterval:(NSTimeInterval)ti
or
+ (void)sleepUntilDate:(NSDate *)aDate
Methods is works for you
Please refer NSThread class Documentation
Related
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!
An iOS app I'm creating shows a setup screen upon first launch which requires data to be written to the database.
Upon launch, I need to access this value form the database.
If it is set, launch main view controller
Else show setup view controller.
As far as I'm aware theres two ways I can do this, programmatically setting it from the AppDelegate or using an initial View Controller as a splash screen and performing the look up and segue there.
What would be the best way to approach this? Is it wrong to do a database lookup in didFinishLaunchingWithOptions?
Using a splash screen is probably the better option as it provides better scope for modification in the future and allows you to update the user on progress. It is fine for the app delegate to run logic to determine how the app starts but you should endeavour to keep the app delegate minimal and focussed.
I very much doubt that you would get this approved (if your goal is the App Store). Your app delegate needs to create a window, and set a rootViewController to that window before it returns YES in appFinishLaunching:
You simply do not have enough time to check with a server before creating the first viewController and you'll be creating poor interface if you try. I suggest the first ViewController will need to be informing the user that it is checking with the server with an activityIndicator or something. The best :)
I want to do some action in my app when the user presses the power button two times while my app is already in background/closed. How can I trigger the action of power button for it inside my app? or if I can add any observer in my app for such action? Is it possible to get this functionality in iOS?
Thanks for help
It is not possible to observe exactly on touching any button on the device. It is the same with volume buttons, you can observe the effect (volume went up or down) but not the pushing button in fact (the volume changed could be triggered in other way).
Sum up:
This is not possible, do not go for it.
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.
My app must sometimes show an UIAlertView when the Home button or the locking button is pushed or when the notification center is shown.
I show the Alert from the applicationWillResignActive delegate's method and everything is ok when home button is pushed or when notificacion center is shown. But there is a problem if the button which is pushed is the locking button (on/off button).
In that case, the Alert is not shown when I return to the app (if I used the Home button it is there). I don't do anything else in other AppDelegate methods which are executed. Also, then, when I show a new Alert (any Alert in the app) the Alert which hasn't been shown when I returned is shown after I dismiss the new one.
Please, could anybody help me?
Thanks in advance.
THE EASY, GIVE ME REP ANSWER:
When the app is put into the background, the app is suspended. Part of this process is closing open alert views.
THE I ACTUALLY KNOW WHAT I'M TALKING ABOUT ANSWER:
The logic behind this is that when the user hits the home button when an alert is displayed, they might be going to look for information on how to answer the alert. However, when the sleep button is pressed, the user has stopped using the device altogether. Apple knows that if they unlock thier device again 3 hours later and see something like Confirm Deletion, they will have absolutely no idea what they were just doing and what to do now.
This is known to cause a serious condition known as what-in-the-world-am-I-supposed-to-do-now-itis. Symptoms of this condition include hitting the round button at the bottom of the screen and subsequently holding on your app icon until it jiggles. They then hit the little 'x' button. This is not good for developer's pockets.