My App is a view-based application. At the beginning I show my logo and after a delay of a few seconds it changes into another view. from then on the user can switch to a lot of different views.
Sooooo.. My Problem: The thing is, when I restart my App. [..well closing and reopen by touching the icon..] the app itself doesnt restart in the sence of jumping to the very first view. to the contrary: at restart the user just returns to the last view that was open.
So I dont know why this is.
Is it normal to somehow manually tell the app to return to the very first view after restart? And if so, how do I have to do that?
PS.
I have so no idea what to do.. Maybe my problem has to do with the timer i used in the first view to change after a delay of time?
Please, is there anyone, who can help me?
Your problem is that, as of iPhone 4, returning to the home screen does not terminate your app. It's just made inactive, so opening it again reactivates it. In most cases, this is a good thing. If it doesn't work for your app, you can add the UIApplicationExitsOnSuspend key to your Info.plist with a value of YES.
(As I said, you should only do this if it really helps usability. If it's just about getting your splash screen shown again, most users and possibly Apple will frown upon it.)
iOS 4.0 and greater have a fast-start thing that allows apps to restart back from where they were upon restarting. There are several ways to deal with this:
1.) your App Delegate receives info about being but into the background and resumed. - (void)applicationDidBecomeActive:(UIApplication *)application and - (void)applicationDidEnterBackground:(UIApplication *)application are the relevant functions here. Check the docs.
2.) You can also disable the background, inactive state completely by including UIApplicationExitsOnSuspend in you Info.plist as Chuck already pointed out.
Overall, you should check the application state docs on Apple's Side.
Related
iOS 13 seems to have changed the way system access requests call back to your app. In iOS 12 and earlier, my ViewController would refresh upon a choice by the user. Now it sits idle after the user choice. The VC is presented only one time, modally, fullscreen, so it's not seemingly related to these sheet/page form changes in iOS13, but curious if anyone else has seen this alert behavior change, has a solution?
I ended up checking for iOS 13 and PHAuthorizationStatusNotDetermined and could somewhat replicate the legacy behavior of the system call back.
Does anyone have any insights into when/under what conditions applicationWillTerminate is called in iOS 5/6?
I've got some logic i'd like to execute whenever the application terminates (not moves to the background), for example if the user navigates to the application bar at the bottom of the screen by double tapping the home button and force quits the app.
when i try to do this on a test device, applicationWillTerminate does not seem to get called. Is there a reason for this?
My plan B is to tie that logic to some persistent object like a singleton or a static that is automatically destroyed when the app quits.
Any suggestions?
thanks
Have you read the documentation for applicationWillTerminate:,
It says,
For applications that do not support background execution or are linked against iOS 3.x or earlier, this method is always called when the user quits the application. For applications that support background execution, this method is generally not called when the user quits the application because the application simply moves to the background in that case. However, this method may be called in situations where the application is running in the background (not suspended) and the system needs to terminate it for some reason.
There is a "maybe" mentioned there. Probably that answers your question. So it is not necessary that this will get called when you quit the app. Probably you might have to use UIApplicationExitsOnSuspend to disable multitasking and then it might get called while putting in background. But that again depends on your app requirement. If you cannot disable multitasking, you might have consider doing that in applicationDidEnterBackground method or so. I am not sure if there are any other delegate methods which will help in identifying the force quit.
Is there a quick and easy way to have the app go back to the same screen after I put it in background mode?
I know there are frameworks just for this stuff, but has anyone done it without much sweat?
Thanks
In your app delegate, add a line to the applicationDidenterBackground: method that stores the current page via NSUserDefaults.
Then in the applicationWillEnterForeground: method, load up that saved value and restore the page.
Multitasking should enable this, while a device has enough memory to keep your app open. Otherwise how about using NSUserDefaults to store a string reference to your view?
As of iOS 5.1, there is no quick and easy way.
I've got an app that changes the screen brightness with [UIScreen mainScreen].brightness = newBrightness, and I want to restore the brightness to it's previous state when the user finishes using it.
I've tried these two delegate methods:
- (void)applicationDidEnterBackground:(UIApplication *)application
- (void)applicationWillResignActive:(UIApplication *)application
But without much success. I suspect my app must be in the foreground to change the brightness? When I change the brightness in didEnterBackgroundMethod, it has no effect at all. When I use willResignActive it does restore the brightness if I switch to another app, but it has no effect when I press the home button.
Are there any notifications or delegate methods that are executed before the app leaves the foreground?
It seems this happens to others as well: see this S.O. post.
Only way around it seems to be forgetting about setBrightness and simulating it by overlaying a black-semi-transparent on your view...
OLD ANSWER:
willResignActive should also be called when you press the home button before the application enters the background state.
This method is called to let your application know that it is about to move from the active to inactive state. This can occur for certain types of temporary interruptions (such as an incoming phone call or SMS message) or when the user quits the application and it begins the transition to the background state. An application in the inactive state continues to run but does not dispatch incoming events to responders.
This is also the behavior I witness. So, my guess (but it's just a guess) is that your app is not set to support background, so that when pressing the home button it is terminated. In this case applicationDidEnterBackground is not called.
I would suggest to check the info.plist file in your project for the UIApplicationExitsOnSuspend or "Select Application does not run in background" key.
Furthermore, you could try and put some breakpoints (or NSLog traces) in those functions and check whether they are effectively called as expected.
According to Apple´s DevForum it seems to be a bug that Apple don´t want to fix soon.
It may sound as a dumb question. In fact, I am still thinking if that might be the cause but working with XCode and having set iOS 4.3 as my Deployment Target and iPad as my Device I am getting an unexpected error.
While running my app through the Simulator I can get it working. But when I run it through my iPad a single IBAction, fired when user taps an UIButton, that takes almost 4 minutes is not completing. In fact it's getting stopped at the same point, in a for loop.
I searched for memory leaks using XCode and it didn't find any, therefore I'm asking if there's a time limit for IBActions. I read there are 10 minutes limit for methods in background but I didn't find anything related to IBActions in foreground yet.
I think the user gets tired of waiting for a response long before the system. Normally, a button press or similar should finish after one second at most (well, maybe 1.5s), or the user thinks that the system is "slow".
I would make sure that you have your button outlets properly hooked up. It is possible that it just isn't throwing the exception so you get a slow system. Put NSLog displays in your IBAction method and make sure it is executing it properly. You should be able to track it back to figure out what is going on.