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.
Related
Upvoters: can you let me know if you've seen this problem as well?
The issue I'm seeing occurs roughly every 1 in 15 times when I try to modally launch a view controller from a button on a certain scene.
This is done with iOS 9.2.1 and XCode 7.2, though it is not clear which versions it happens on. It's not easy to change the iOS version down.
The symptoms are as follows:
The destination view controller is not visible on the phone. Instead, the top bar (the one with the carrier) goes black, and sometimes it flickers so the whole screen is completely black. The launching view controller is visible, but not responsive.
When this happens, I go to the XCode screen and do view debugging. Remarkably, this shows the destination screen, almost as it's supposed to look. The only difference is that one of the views has not done its drawRect, and one of the other views looks all speckled. But of course it does not at all correspond to what the phone is showing.
The cancel button on the destination screen seems to still work, because when I press where it's supposed to be, the app continues to function. If I try to relaunch the screen with the button, it again doesn't work though. So once this has happened, the screen has stopped working for that session and the app needs to be killed and restarted.
There are not many hints, but this information may help:
There's 3 scrollviews containing views on the destination screen. All three child views have their own drawRect. It turns out one of the drawRects is not called when the error occurs, resulting in the grey background being shown. The speckled view does run, but I have no clue why it looks like that in view debugging.
No warnings in XCode. Nothing about NSLayout constraints or presentations overlapping.
Two fields are set on the destination view controller on the prepareForSegue function.
The segue is launched from the times button by way of the storyboard. There's no missing or extra outlet, and it is named correctly for the prepare function to catch it.
The issue is sporadic, but will reliably occur if you launch/cancel many times in a row.
Here are the screen grabs. I won't show you the black screen. It's just black with the carrier and the time.
I've solved it. Checking the memory usage turned out to be quite useful.
The grey area was supposed to be filled by a large background with lines drawn. It turns out the naive implementation of drawBackground causes the memory size to balloon to over 200MB. I replaced it with a CSTiledLayer, and now it takes a few MB instead.
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.
I am not really sure how to phrase this question but to keep it simple;
I originally started my app for iPhone but now made it universal. Being that did that, I started making iPad.xib files as well... Everything is complete now and everything is working how it should except ONE thing...
On the Controllers, I have an instructions button, (button that when touched, a uiview gets added to the center of the screen and says the instructions).
That all works great but for some reason when I touch it on one of the new iPad Controller (from the iPad xib) all the buttons that were moved around the view prior to touching the button, start to revert back to the initial position...
I do have a function that makes them do that, but to my knowledge, it is not being activated when this instructions button gets touched. If it were, I'm sure this "error" would also happen in the iPhone simulator...
Anyone have any idea? I keep looking at different solutions but can't really figure this out.
Thanks!!
This is most likely due to auto layout. If you change the frame of a view by setting frames, when the view updates (for any reason), the views will revert to the frames that are determined by their constraints. To fix the problem, you should move your buttons around using constraints, or turn off auto layout. While turning off auto layout is the easy way to fix this, you really should learn how to use that system.
I've been asked to help fix a bug for a client, who is an inexperienced developer. However, I'm absolutely stumped by this one.
The problem is that after a string of opening and closing a view controller, which is being pushed onto a navigation controller, all of the subviews will disappear (including the navigation bar items) and show straight through to the window. After this happens, I can still press the buttons on the navigation bar, but they will immediately disappear on touch-up, and restoring a stable UI state is impossible without a quit & relaunch. Another obscure side effect is that after closing the app, Springboard will flash as I swipe between screens. My initial thoughts were that this was a memory issue (e.g. subviews getting released on memory warning), but I have since cleaned all the leaks & checked all the viewDidLoad/viewDidUnload handling of outlets and the problem is still happening. So now I think that with the Springboard effect, that the code is somehow messing up the state of core animation entirely.
Has anyone seen anything like this before? Or have any idea how it would be possible to make this much of a mess? I would attach some screenshots, but trying to take a screenshot with the phone when the app is in this state causes a system crash.
I've not experienced this, but maybe a memory warning is eating some of your views?
I know that iOS is free to unload view controllers that aren't visible.
I'd stick a breakpoint in viewdidunload or similar and see if that triggers.
As it turned out, this bug was caused by a UIView being deallocated while it had a superview.