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.
Related
Long story here, so bear with me...
I have a view controller which, when presented more than three times throughout the life of an application session, will hang and lock and freeze my entire application. Even the Springboard locks up until my app's fully backgrounded! In Xcode's inspector, I noticed rather alarmingly that the memory footprint would jump a good 5-8 MB every time I presented that view, and it wouldn't go down again after dismissal. By the time the fourth invocation rolls around, the app's already using 40 MB of memory.
My first thought was, "OMG, itz a memry leek!" The second one told me to hop into Instruments and track it down.
While the Leaks tool did help some, it only told me that the app was leaking like crazy. All it would tell me was that, somewhere in these four second intervals, I had gained between "4 new leaks" and "17 new leaks." They did correspond to my opening that view, though, and once I started commenting random stuff (and following the sometimes helpful guidance of the Allocations tool), I tracked most of them down to three extra lines of code. "Oh well, I don't need those views anyway!" Those three lines no longer exist, and Instruments no longer complains.
My only complaint here is that my UI still behaves the same! On the fourth presentation, the entire app slows down. Upon further inspection of Xcode's instruments, I see that not only is the memory still going up (only to 30 rather than 40 MB this time), but the CPU activity has tanked!
Ok, granted I should have looked there in the first place, but I ain't perfect!
I ran the app again, and found that the overall CPU activity rose consistently the more I presented that view controller. By the third one, it was up to 40-60%. The main thread seemed pretty clear, and most of the activity was spread between eight other background threads (who knows what all those do).
The fourth time I opened that view, I had expected everything to block like crazy. It didn't. The CPU just... stopped. It was running at around 50-ish% when, by the time my finger had left the screen, it was down at 1%. All of the thread graphs shrunk from spiked stalagmites to tiny waves in a puddle. According to the pie chart, the vast majority of the processor was free to do as it liked. It doesn't like me.
I literally have no clue why it does this. I've been stuck in a room for days now trying to figure this out. Any help or advice would be much appreciated.
Does anyone have any idea why this happens, how this happens, or what I can do to make this not happen?? I'm drawing a blank here...
Thank you so much!
It should be noted that I got these by running the app on my iPhone 5s. Yes, I did try on the simulator, but my little MacBook Air took it like a champ, and was no help in figuring this out, except to tell me that the problem happened on iPhones.
I've run into this before, and the following is my general approach that usually allows me to fix these types of memory leaks.
First I would put a print statement into you viewController to see if your VC is being deallocated when it is being popped.
deinit {
print(self.description)
}
The next step, in the case that the ViewController is not being deallocated, I would start by removing core pieces, bottom up, commenting them out chunks one step at a time, yet leaving the back control that hides the view controller visible. Usually you can isolate the memory leak once you see the deInit get called after removing some code, you may have hit the part that made a strong cycle reference.
One more thing, ensure that all your delegates are declared weak, and search through your code for closures, and check that the closures aren't holding hard references within, especially to self.
Also, checkout this article to see the about using unowned or weak, when passing in instances into a closure, could be helpful.
http://krakendev.io/blog/weak-and-unowned-references-in-swift
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.
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!
I`ve searched a lot about this problem but I didn´t find anything, hoping someone does it, here is my question:
Ive tested the app in the simulator a lot of times. I have ARC and all the outlets released in the viewDidUnload (Ive quite a lot of images). When I run it on the simulator, the memory continues rising again and again, when changing between views.
For example, I have a button in a view. And right clicking it, I drag it to another view, connecting them. Do I need to release anything relating in this way the views? If so, where I put the code? (I have a .h and .m for each view).I have read a lot of questions like this, but all off them referred to views related by code, not using the drag option
(Style - modal)
Please I would thank a lot any clue or help, as I have to solve this problem in a short period of time,
Thanks in advance :)
viewDidUnload is not called anymore starting with iOS6. That might explain what is happening.
Called when the controller’s view is released from memory. (Deprecated in iOS 6.0. Views are no longer purged under low-memory conditions and so this method is never called.)
Furthermore, viewDidUnload was usually called when the view was unloaded due to memory pressure, so you were anyway expected to call it from your dealloc method.
Try doing your niling in dealloc or viewDidDisappear.
You should also be aware, if you use UIImage's imageNamed to load your images, that this method will cache the images. So even when you remove them from your views they remain in the system's cache.
Without seeing your code it is not possible to say more than this.
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.