I have a timer with a countdown. In recent testing, I've noticed that if I hit the home button and return to the app, the timer is off (fewer seconds have ticked off than should).
I've noticed in testing that ViewDid and ViewWill Appear do not fire when re-opening the app. I know that:
- (void)applicationWillEnterForeground:(UIApplication *)application
Fires, but how do I make it specific to certain part of a viewController that was active?
You probably want applicationDidBecomeActive: and applicationWillResignActive:, which are sent to your app delegate. There are also notifications posted (e.g. UIApplicationDidBecomeActiveNotification) you could listen for.
Those are also posted when, e.g., a system alert comes in. If you just want to be told when you're going to the background, try applicationDidEnterBackground: and applicationWillEnterForeground:
See the Apple Docs on lifecycle for details.
Just for the sake of follow up, as the question was answered above.
I had the exact same problem as Eric and then I implemented Jesse's suggestion about using applicationDidBecomeActive: on the delegate. I just wanted to make sure how all the different methods were being called, and I found this:
application:didFinishLaunchingWithOptions: is called at the very start, as expected.
Then, is the main view controller's viewDidLoad turn.
Then viewWillAppear: is called.
Back in the application delegate, applicationDidBecomeActive: is triggered (here I call my reactivateTimer method which I implemented in the main view controller).
The reactivateTimer method is executed.
The last step is the call to the main view controller's viewDidAppear:
Related
My app delegate method applicationDidBecomeActive: is getting called twice for the first time launch of the application. I have some portion of code which I want to execute only once & that I have put into applicationDidBecomeActive:
What should I do?
I got the issue. I am using Location Services. When launching for the first time after I tap on "OK" on the location services alert, my applicationDidBecomeActive gets called one more time which is the normal iOS behavior.
If you want to call your code only once when app becomes active, try calling it from two methods.
didFinishLaunchingWithOptions
applicationWillEnterForeground
instead of calling it only from applicationDidBecomeActive.
This is because of location or push notification alert.
After the native location/push notification has been dismissed, applicationDidBecomeActive will be called.
I don't know if this will help, but I just had the same issue with a totally simple app that doesn't use Location Services, and I found out it's an illusion. Look at the logging messages I got:
2012-12-22 10:47:45.329 Bizarro[10416:907] start applicationDidBecomeActive:
2012-12-22 10:47:45.333 Bizarro[10416:907] end applicationDidBecomeActive:
2012-12-22 10:47:45.329 Bizarro[10416:907] start applicationDidBecomeActive:
2012-12-22 10:47:45.333 Bizarro[10416:907] end applicationDidBecomeActive:
Look closely. Look at the times. The first and third messages have the same time. The second and fourth messages have the same time. They are the same messages! It's an Xcode bug; it has nothing to do with my code. Xcode is reporting the same log messages twice.
In my case, I was able to prevent this by turning off all Behaviors for Running -> Generates Output.
What about:
Increment on applicationDidBecomeActive
Decrement on callback events of permissions requests or other alerts that trigger another applicationDidBecomeActive when closed.
With Xcode 6 there's a new reason this can happen: when you launch an app in a resizable simulator, applicationDidBecomeActive: will get called twice.
It launches the app with the default size class, and then applies the size you were last using—even if you were using the defaults. Any time a change in size class is applied, applicationDidBecomeActive: gets called.
When app launches first time
it calls sequentially,
didFinishLaunchingWithOptions
applicationDidBecomeActive (Twice)
When we open the Control Center it calls only,
applicationDidBecomeActive
When app come from background to foreground it calls sequentially
applicationWillEnterForeground
applicationDidBecomeActive
I'm currently seeing double notifications.
It's happening because my AppDelegate's init code is being called twice.
It's being called once when the main() does [[NSBundle mainBundle] loadNibNamed:#"MainMenu" owner:application topLevelObjects:&tl] (ie, when the .XIB file is loaded), becaues the .XIB file is setting up FirstResponder to my custom AppDelegate, and then it's being called again when main() calls [[myAppDelegate alloc] init].
The init code is what does the addObserver calls, so two observers are being set up for each notification I care about, which is why my notifications get called twice.
I'm a newbie OS X programmer, so I'm not yet sure of the best way to resolve these two, but wanted to post it here in case it's of help to others, another place to look.
Have you possibly created an instance of your class in Interface Builder AND in your AppDelegate code, perhaps?
If you have code you want called only once when the app starts up, then use
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
instead.
Otherwise, applicationDidBecomeActive will be called whenever your app becomes active again, so that doesn't just mean twice as in your case, but every time the user switches back to your app after switching to another.
If you use RxSwift, then you can just throttle the application event, so it doesn't call twice in the same second:
NotificationCenter.default.rx.notification(Notification.Name.UIApplicationDidBecomeActive)
.throttle(1, scheduler: MainScheduler.instance)
.subscribe { (event) in
self.appEnteredFromBackground()
}.disposed(by: disposeBag)
private func appEnteredFromBackground() {
Analytics.trackPageView(withScreen: .home)
dataStore.checkIfAllowingRides()
}
I put this code in my actual view controller where the logic is supposed to happen on ApplicationDidBecomeActive.
I just check at top of applicationDidBecomeActive: if the request was really sent (I made a function for this, checking status), if so I return already.
The second time in applicationDidBecomeActive:, the function reads the status as Deny or Allowed, because this is after the User answered the Alert.
In my project I show an Alert to the user to indicate an 'empty list'.
Right now, I show it in AppDelegate>applicationDidBecomeActive.
I'm doing this because I want the alert to show if the list is empty
at app startup and when coming out of the background (iOS 4.2 through 5.x).
EDIT:
I use a method in the AppDelegate, and call it with a slight delay, and I still get this notice.
[self performSelector:#selector(checkForNoMessages) withObject:nil afterDelay:1.0];
However, this causes a "wait_fences" notice in the debugger and I'd prefer not to submit to Apple with this notice.
Where is the proper place to put a popup Alert so that it appears:
1) At App startup
AND
2) When the App is coming out of the background?
Do I need the Alert in more than one place?
I recommend writing a method in your AppDelegate or better in your root view controller which shows the message. Maybe with some arguments, so you can reuse it but that's up to you.
If you are following the MVC architecture ask your model about existing entries and trigger the Alert message if necessary. But encapsulate this behavior in a controller as well.
application:didFinishLaunchingWithOptions: and applicationDidBecomeActive: are the places where you want to delegate this task to your controller.
More about iOS Multitasking: https://developer.apple.com/library/ios/#documentation/iphone/conceptual/iphoneosprogrammingguide/ManagingYourApplicationsFlow/ManagingYourApplicationsFlow.html
Edit:
Don't forget that you have to call the methods from the main thread.
And do all startup stuff first.
OK - the problem wasn't where I called the alert, it was because it was in a method. Once I moved the code from a method into applicationDidBecomeActive, all is well.
I'm running into a problem where 9 times out of ten, when I call UIAlertView's dismissWithClickedButtonIndex:animated:, the delegate method alertView:willDismissWithButtonIndex: is not called. Is anyone else running into this problem? I'm about to file a bug with Apple but I'm curious to see if anyone else has run into this issue and figured out any workarounds.
To ensure a consistent behavior across iOS4 and 5, you could just remove the UIAlertView's delegate just prior to calling its dismissWithClickedButtonIndex:animated: method, then manually invoke the delegate method. e.g.
- (void)somethingDidHappen {
id<UIAlertViewDelegate> delegate = myAlertView.delegate;
myAlertView.delegate = nil;
// now, we know the delegate won't be called...
[myAlertView dismissWithClickedButtonIndex:0 animated:NO];
// ...so we call it ourselves below
[delegate alertView:myAlertView clickedButtonAtIndex:0];
}
(That code isn't tested, but you get the point.)
Delegates of UI objects are only called when the user performs an action. Apple assumes that when you do something from code, you already know what you're doing and you don't need to be informed. That applies to all delegates (scrolling delegate methods of UIScrollView vs. code-scrolling, Table View manipulation, ...)
Anyway, what button index should the delegate be called with?.. there is no one when you dismiss programmatically
According to Why doesn't dismissWithClickedButtonIndex ever call clickedButtonAtIndex? the problem is that a different method is being called. However, that doesn't explain why you get erratic calls. On the devices I tested the dismiss method gets called correctly, so I only redirect it to the click version.
Maybe you should file a bug with Apple if you continue seeing the erratic behaviour.
There are alertView:clickedButtonAtIndex:, alertView:didDismissWithButtonIndex: and alertView:willDismissWithButtonIndex:. The method that you're referring to (clickedButtonAtIndex:) is only called when the user explicitly taps on a button on your alert view (hence 'clicked').
Programmatic calls via dismissWithClickedButtonIndex:animated: to dismiss the alert does not seem to call alertView:clickedButtonAtIndex:.
So, if you need some behavior to be always triggered upon the dismissal of the alert view—whether it was triggered by the user tapping on a button or triggered programmatically—then using the didDismissWithButtonIndex: and willDismissWithButtonIndex: makes more sense.
I have traced a problem in my iPhone app code to the viewDidAppear method not always firing. When you start the app the event fires as expected. However if I close the app using a phone capable of multitasking and reopen in. My viewDidAppear events no longer fire.
My views are loaded from Nibs and I use viewDidUnload to clean up (release and nil all outlets). My views are nested in side and tab bar then navigation controllers. I looks like the events aren't wired up properly when the nibs reload. Any idea on what I'm doing wrong/missing and how I can fix this?
Thanks in advance.
UPDATE I do not mean the event is not fired when the app first comes into the foreground. I mean the event never fires again. Even when changing between tabs or moving though the navigation views.
Example:
- (void)viewDidAppear:(BOOL)animated {
[super viewDidAppear:animated];
NSLog(#"viewDidAppear called");
}
This code is placed in two views, each on different tabs. Each time I swap between tabs "viewDidAppear called" is written to the log. When I close and reopen the app and swap between tabs this no longer happens. Other button events fire normally.
Btw, the viewDidUnload method is really badly named btw -- it's not an 'opposite' to viewDidLoad, it's only called if there was a low memory situation and the view for that controller was unloaded due to not being visible at that time.
(ORIGINAL, NOT SO RELEVANT ANSWER:)
Please see my answer to this similar question:
Why does viewWillAppear not get called when an app comes back from the background?
Basically, viewDidAppear gets called after your UIViewController's view was added to the application's UIWindow heirarchy. Backgrounding then restoring the app doesn't change your view in that respect, so viewDidAppear doesn't get called -- it's correct behaviour, and not a bug. Check out the API docs for UIViewController.
Found it.
While not new to programming I am new to iPhone development. On researching this problem I found it was not recommended to call the viewWillAppear and viewWillDisappear methods manually.
My viewWillDisappear methods resign any keyboards if shown, when my app enters the background it loads a splash screen ready for when the app re-enters the foreground (there is some logic I need to do to work out what the user is shown on restarting the app and I can do this under the splash screen).
As viewWillDisappear is not called when the app goes into the background to make sure no keyboards appeared over my splash screen I was calling viewWillDisapper in the applicationDidEnterBackground method. I guess this also un-registers my events.
By adding viewWillAppear to my applicationDidEnterForeground method my events started firing again. Lesson learned, I will refactor this so I don't call these events manually.
Thanks for the help.
I definitely need some clarification on when exactly viewDidAppear/viewDidDisappear methods are supposed to be called...
If the application enters background while showing some view, in this case I would expect viewDidDisappear to be called on the UIViewController linked to that view. On the other hand, if the application enters foreground after being background, I would expect viewDidAppear to be called. But it doesn't work this way.
If an UINavigationController displays an UIViewController we call 'A', and that UIViewController is linked to a view that has a subview linked to another UIViewController we call 'B', the viewDidAppear method is NOT called on the controller 'B'. Do I have to propagate viewDidAppear myself? I'm confused...
Thank you in advance!
They are not called because they don't disappear and reappear unless you tell them to disappear. Your whole application is suspended. You need to listen to the app delegates applicationDidBecomeActive: and applicationWillResignActive: messages if you want to know if your app got suspended or gets reactivated. You can also register for the notifications UIApplicationDidBecomeActiveNotification and UIApplicationWillResignActiveNotification.
Yes, you have to propagate the viewDidAppear: messages to your subviews manually. This is working as designed.
There is also:
(also an app delegate method):
- (void)applicationDidEnterBackground:(UIApplication *)application