I'm noticing something strange in my NSApplication delegate callbacks. When I start the app with debugger attached, I see what I expect: applicationDidFinishLaunching: is called first, then applicationDidBecomeActive:
When I run the app without the debugger, I get the calls in the order reversed: applicationDidBecomeActive: is called before applicationDidFinishLaunching:
Is there a reason for this? It makes it very confusing to account for different scenarios based on debugger vs. non-debugger.
[note: testing this is in Mavericks]
The relative order of those delegate methods during launch is not documented, so you should not rely on any particular order.
If you're concerned about some initialization not having been done when -applicationDidBecomeActive: is called, then you should do that initialization in -applicationWillFinishLaunching: rather than in -applicationDidFinishLaunching:. Alternatively, you should do the initialization on demand, such as initializing a property when its value is first requested.
Related
I am wondering does the CLLocationManager delegates like didEnterRegion and didExitRegion work when stopUpdatingLocation is called or the the method startUpdatingLocation must called all the time to make them called ?
Another thing is where the best place to start regions monitoring
If your app enters the background you are expected to call stopUpdatingLocation to preserve energy. If you use startMonitoringForRegion:desiredAccuracy: your delegate methods didEnterRegion and didExitRegion will be called accordingly, even if your app is in background/suspended. Another option is to use startMonitoringSignificantLocationChanges. Then your app will be woken up from suspended or terminated status.
I want to make sure that all my initializations for my views and stuff are handled every time my application starts, even when it is called back after being sent to the background, such as with multitasking.
What's the best way to do this? should i use applicationDidBecomeActive to call viewDidLoad on my viewcontroller directly? I'm guessing this is not wise. I just want to make sure that stuff gets done on load every time the user calls up the app, no matter what state it is in at the time.
I have several apps published that do just that - call viewDidLoad on one or several UIViewControllers from applicationDidBecomeActive.
It works just fine. Apple doesn't object to it either.
However, be aware that if you have allocations in your viewDidLoad you need to either check for already allocated instances or release the instances you allocate in viewDidLoad when your app suspends. The same goes for DB connections that need to be closed, notification listeners, and so on.
As long as you watch for these elements and handle them correctly, the approach is valid and very usable.
Why are some delegate methods not called automatically? I thought that if you used a delegate method that it would be called automatically. But That's not the case as I've found out. For an example see this post
In the case you mentioned, the method didUpdateHeading isn't called because the manager itself hasn't started yet. Basically, your controller is already listening for notifications, but the notifications don't even exist yet because the location manager hasn't been started. As soon as the manager is instructed to begin tracking user location, then the delegate methods will be called.
So in your example, you placed the startUpdatingHeading call inside the method that would be called once your manager is started. So, it never gets called.
To have a delegate method called, you need a delegate. And as the answer to that post said, the code was setting up the delegate inside a delegate method. So, if the delegate is set up inside a method that only runs after the delegate exist, nothing will happen.
i'm seeing a weird issue trying to add custom URL support to my Mac app. i've defined the URL(s) in Info.plist, and when i navigate to them my app gets launched (or, if running, activated), but then, regardless of whether my app delegate implements handleGetURLEvent:withReplyEvent: or not, i see a couple of the following messages in the debug output:
+[NSKVONotifying_MyAppDelegate handleGetURLEvent:withReplyEvent:]: unrecognized selector sent to class 0x1d096e0
Apparently, NSKVONotifying_MyAppDelegate is a wrapper created by KVO for my real delegate (called MyAppDelegate), and that seems to obscure my implementation of handleGetURLEvent:withReplyEvent:, which never gets called. AFAICT, nothing in my app uses KVO on the delegate, and i'm running out of ideas as to what could be causing this.
any suggestions?
turns out the KVO thing was a red herring. the method needs to be static, as careful reading of the error message (or docs) would have made clear, while i had an instance method (as one would expect, for delegate methods? weird API design choice).
I'm working on a simple proof-of-concept for an iPhone app (and important bit of info, I'm pretty new to Mac OSX development all around). I created a view based app with a timer. I declared my NSTimer in the interface of my app's controller, used #property and #synthesize, and I initialize it in the controller's viewDidLoad method with scheduledTimerWithTimeInterval method. My selector is a method with the signature -(void)someMethod:(NSTimer *)timer which is declared in the interface and defined in the implementation file of the controller as well. I can step past the line where I assign the timer and see that it points to a valid object, but my program goes no further than the end of the viewDidLoad method and never reaches the breakpoint at the first line of my method that is called by the timer. Also, I see GDB: Program received bad signal: "EXC_BAD_ACCESS" in the status bar of xcode at this point (viewDidLoad end is reached). I didn't do anything in IB but add a view and a picker just so I'd see if the UI actually loads...it never does.
So, am I doing something wrong with the NSTimer, or are my troubles elsewhere? How can I use the debugging tools in xcode to get more information?
EXC_BAD_ACCESS usually indicates a memory management error, without seeing the code probably from somewhere else in your app. It's a very common error for beginners, but an important subject to fully understand, so I'd suggest looking through some of the questions on memory management here and find a few guides or tutorials to look through. It's actually pretty easy to learn.
Also, it shouldn't hurt but unless you need to access the timer in between fire events, you don't actually need to store it as an instance variable. Once you create and start a timer it's added to and retained by the application's run loop.
Have you got NSZombieEnabled?
Might be useful if this is failing on an over released object.