So I'm debugging some code I didn't write. It's quite complex, and I'm trying to get a handle on the bug I'm tracking down. But, for some reason, on our login page, none of the lifecycle methods are firing.
I've placed breakpoints on them, put console logs there, and no matter what, everything points to them not firing.
Why would methods such as viewDidLoad: and viewWillAppear: etc. not fire? Are there any times that could happen? Or any times it could skip a breakpoint or console line in those methods?
Sorry if these are dumb questions, I'm just super perplexed as to how a VC on screen doesn't call these methods but still is on screen? I've used chisel to confirm that the code I'm looking at is indeed for the VC on screen, and it is. So I'm at a complete loss. I would be VERY grateful for any help.
Thanks in advance!
I have faced similar issues before and it was due to duplicate copy of container in the simulator.You can try resetting your simulator, clean the build and check once again.
Related
Throughout all the betas of Watchkit I was able to run my watch app seamlessly, but with the recent release this past week (8.2) my willActivate method is hardly ever called. What happens is awakeWithContext gets called and the watch stalls with the spinner spinning forever. Has this issue happened to anyone?
I've found that locking and unlocking the device (simulator) by typing Command-L will cause the willActivate method to be called. I hope you don't have to do that on a real Apple Watch.
Just came into the same problem yesterday.
In my case, I'm using the page navigation, and the initial view controller's awakeWithContext gets called, but willActivate is never called.
After some digging I found out that when using page navigation, ALL of the pages awakeWithContext will be called at launch time and before the initial page's willActivate. If one of the pages awakeWithContext method get stuck, the initial page's willActivate method will never be called.
You may need to check your other view controller's awakeWithContext methods to see if they are stuck.
So, I still don't think I know exactly what is going on or what's causing it, but I'm having the exact same issue, and I have done some investigating and have some results, so I hope this helps us narrow this down. I have identified that it has something to do with the complexity of the layout that is going into my initial controller. If I change to a simpler layout for my initial controller, or if I delete "enough things" from my initial controller, then I no longer get the spinning wheel of death. (Of course that also breaks the logic of my app). My layout is a bit complex, but not that complex; there are groups nested 4 layers deep, and about 20 total UI elements (including the groups themselves), with four buttons and 4 labels. It seemed to work fine in the beta. And there's not a clear rhyme or reason to it; some combinations of layouts seem to cause it, some don't. It is deterministic; if a given layout spins on load it will always spin on load, and if it doesn't, it doesn't. When it spins, I never get willActivate. When it doesn't, I do. It does not seem to have anything to do with the contents of awakeFromContext:. I can delete everything from that method and it does not help. It also has nothing to do with assets, compiler settings, etc., etc. Other than that, I haven't figured it out yet. If anyone has any insight into this, I would love to hear it.
I am following the Udacity tutorial on Swift, and for some reason when I added the second view, I usually get a black screen (as in the screen print) right when I open the app. Occasionally I get it working but usually not.
What could be the problem?
Noticed that "Did appear" is printed before "Will appear", is that a bug or did I do something wrong?
I have read this and this but it didn't help much. I also have tried several times to clean the project and rebuild it (nothing changed).
One time I just commented out some code (from the second view that should be loaded) and it worked suddenly. When I uncommented the same code it still worked.
Another time it worked when I disconnected the second view on the story board (it was still there, just no way to reach it).
Both have worked at least one time, and not worked many times.
Sorry this seems like I throw in random pieces of information, but I have no idea what could be the reason.
Occasionally, my app will simply not render any frame-relayed animations triggered by +[UIView animateWithDuration:animations:] and friends.
The completion block, when provided, still gets called as I'd expect, but the views simply "snap" into the destination frame, as if I'd simply called -setFrame:.
It is across the whole app, and is completely independent of which view controller is displaying, and whether or not the VC is modally presented. Restarting the app solves the problem temporarily.
Note: This is obviously not enough information to solve the problem, but I'm not even sure where to begin. Comments on where to start debugging are greatly appreciated.
Update: It seems to be reproducible by running a series of animations in succession. If I trigger several animations to run overtop of each other, it would seem animations just turn off, app-wide.
For posterity:
The issues that, direct frame-setting was occurring on a background thread.
To fix the issue, I needed to ensure that that code was getting run on the main thread.
That being said, since I could not post enough code to really substantiate this issue, I'm going to vote to close it as off-topic. Thanks for all your help!
Does any body know what I have to check if my app freezes? I mean, I can see the app in the iPad screen but no buttons respond. I have tried debugging the code when I click on the button, but I haven't seen anything yet. I was reading about the Instruments tools; specifically how do I use them?
Can anybody help me? I just need an explanation about how use the tools.
It sounds like you've blocked the main thread somehow. To debug, run the app in the debugger and when the app freezes, hit the pause button above the log area at the bottom of Xcode. Then on the left side, you'll be able to see exactly what each thread is doing, and you can see where it's getting stuck.
Probably either a long loop on the main thread or a sync deadlock.
Top answer is correct. You can debug this with "Pause" option. Most common way to block main thread is to call dispatch_sync on the same thread you dispatching. Sometimes you call same code from dispatch_once.
Besides pausing and following the stacktrace I think as an additional thing to do, is to check in the code if there's any loop causing the app freezes.
I recently ran into a similar problem, but stack trace didn't help much, I figured out that I was having an eternal loop when calling a reloadData() inside layoutsubviews method and that was causing a freeze with no errors and no help from instruments.
I have similar case in my project and the reason was another developer who added setNeedsLayout() inside method layoutSubviews() and this make infinite loop and freeze the app.
I suggest checking your sizes especially in collection views if they are not fitted they will freeze your app and also check your constraints
The same Issue Happened to me with ios 13.4 and then I tried the above solution but it doesn't solve it. so I had one element with break constraint on the storyboard. So after resolving the constraint it solve the problem.
I have an iOS app that, in one view, makes a toolbar in code. Nothing fancy here; just a bunch of standard UIBarButtonItems (initialized with initWithImage, and each one invoking a different selector), added (along with spacers) to the toolbar using UIToolbar setItems:animated (with no animation).
This works fine most of the time... but sometimes, after going to another view and back to this one many times, the toolbar's touch-handling appears to be off. It highlights and invokes the wrong button. It's not always the same wrong button, either; sometimes it's one right next to the one I actually tapped, but other times it is further away, even clear over on the other side of the toolbar.
There is no pattern to it, but if you try long enough (switching to another view and then back to this one), it always happens. It seems to happen more often when the other view is at a different screen orientation (forced by its shouldAutorotateToInterfaceOrientation implementation), but even when all views have the same orientation, it still happens now and then. When it happens, my selector gets invoked with a sender that matches the button that was actually highlighted, rather than the one I touched. So it really seems to be a matter of something in iOS not processing the touch correctly.
My google-fu has utterly failed to turn up any other reports of this issue... seems like it must be an Apple bug, since none of my code is involved in the toolbar touch handling. This happens both in the simulator and on the device, under iOS 4.3 (haven't tried other versions yet).
Has anyone else run into this issue? Any suggestions on how to avoid it?
OK, I found the problem. It wasn't the code that creates the toolbar itself; it was where (and how often!) it was being called.
This was legacy code, and we hadn't noticed that the create-the-toolbar code was being called from the view's didRotateFromInterfaceOrientation method (for reasons we can't imagine). That method gets invoked quite frequently, and the old toolbar wasn't being torn down, so it was creating toolbars on top of toolbars. Not too surprising that the touch handling went wonky in that situation.
Deleting the call there (and putting it in viewDidLoad like one would expect) solved the problem. Sorry for wasting everybody's time... but maybe the next person to stumble across screwy toolbar behavior will find this helpful.