This is so weird. I have been working on a series of iterations of the same application for almost 2 months, have not touched the code related to the view management in weeks, and this bug just appeared.
Basically I am at the root level view, i go to the last view in the stack by way of a "skip" type button. This page is used for settings. I then change some things (not related to the view hierarchy) and save, which takes me back to root. Then i try going to the first view in the stack.
Initially all of the textfields for the view are visible, but their uilabels are not. The view then slowly drifts to the right, revealing the same view with labels intact directly under it. I have never seen a bug like this before in over 2 years of iOS dev, so here I am.
The only code I have changed in the last week is related to web services and threading, nothing having to do with the view hierarchy.
If anyone has seen this bug before please help! Probably important as well, I have not seen this happen on the simulator, only on the actual device (iPad running 4.3.3)
Thanks!
Threading is the most likely culprit: making UI calls anywhere other than the main thread can cause any number of strange problems. Make sure anything you do to the UI, even a -popViewControllerAnimated:, is wrapped in a -performSelectorOnMainThread:withObject:waitUntilDone: or an appropriate dispatch_async(dispatch_get_main_queue(), ^{...}) call.
Related
Since I am using Xcode 11 I am having problems with the Safe Area. My App is an ArKit- App that uses an ARSCNView. after upgrading to Xcode 11 the safe Are doesn't allow me to display it full screen anymore. Actually all the views in all ViewControllers can't be displayed in full screen. I really don't know where to start. Did anyone experience this kind of behavior?
Thanks!
Edit:
I unchecked all the necessary boxes I hope. The behavior I still get is this:
Storyboard Main
Inspector
Live View
There seems to be a view underneath. But I never added one and the inspector doesn't show. This changed with xcode11.
I just found out what happened to my ViewControllers. I am checking for internet connection with a LaunchViewController. The segue from this controller to the next one did not specify "full screen". I still don't know why I have to explicitly tell the segue to do so in Xcode 11. But in the end that solved my problem.
Thank you
The Safe Area is used as a reference for constraints for views and objects that you want the user to be able to interact with. It is used as a guide during the layout of objects on the screen. If you want to take advantage of the entire screen, constrain your views to the superview (basically the main view of the view controller). This is handy for displaying things like backgrounds on the entire view. Take a look at Apple's human interface guidelines for more info:
Apple's Human Interface Guidelines: Adaptivity and Layout
Similar Question:
iPhone X - Safe Area does not achieve full-screen experience?
I hope you can help me with my actual problems with designing an iPhone-App in the latest xCode version.
Here´s what I find a bit strange:
I designed a new project with a Storyboard and a Navigation Controller. Then I placed Objects like UILabels, ImageViews and so on. No when I run the Project in the simulator (as well on the iPhone) I noticed the following: When the App loads all the in the View placed objects fall down from the top to take their defined place. It takes maybe the quarter of a second, but its clearly to see. It also happens on all other views initiated from the root view controller
So, what do I have to change that everything is at it´s fixed place without to fall down from the top at the start of the app?
I hope I described it good enough. Actually I have no idea what´s going on there. I hope you can help me to fix this "problem". I´ve written some small Apps before, but I´ve never noticed a behavior like this.
Got the solution: I´ve had to remove the animations on the main view... now it works proper! :-)
I'm building an iPhone app (in iOS 5) with several different views, one of which contains a map (also has separate view controller). The first time I go over to this view, it takes a while for it to load, and things such as animating pin drops also don't work well as a result of it. Not to mention that it takes a bit for the location to stabilize.
What I want to know is if there's a way to load MKMapView before a user goes to that view, so by the time they get there, these issues aren't present anymore.
I've already seen this and this question but they haven't been very helpful. Keep in mind that I don't really need to interact with that view before I get there, I just want it to be fully loaded by the time I go there.
I have a view (a couple of them actually) with a standard search bar at the bottom. When the user touches the search bar, I need to move the search bar up so it's not hidden by the keyboard, then down again when the keyboard is dismissed.
I do this the same way as everybody else, by observing UIKeyboardWillShowNotification and UIKeyboardWillHideNotification. From these notifications, I get the height of the keyboard, and that tells me where to put the bottom edge of the search bar. It works perfectly, except for rare cases when the search bar doesn't animate, or doesn't animate far enough, and vanishes behind the keyboard. I have seen this a handful of times out of hundreds of tries with myself and my QA people testing on iPhones and iPods. Just once, I saw the search bar fly off the top of the screen as the keyboard came up. We've never seen any of this on the simulator, and we see it more often on the iPod than the iPhone. We are running iOS 4.x, mostly 4.3.3.
So I can think of two possibilities. One is that very occasionally UIKeyboardWillShowNotification is not sent and the other is that the data in the notification is wrong. The second one would explain the one case where the search bar flew off the top of the screen.
And then of course it is possible that my code is wrong in some very devious way; but the scenario is so simple -- enter the view and tap the search bar -- that I can't see how a bug in my code could cause these rare and intermittent failures.
If anyone can offer insight, I would be very grateful.
I finally discovered the answer to my question, and it's interesting. To cut to the chase, my search bar is animating into the wrong position; in some cases it's still behind the keyboard, and in others it's off the top of the screen. This is not caused by wrong data in the notification, but by a bug in accessing the height member of a CGSize or the y member of a CGPoint.
Specifically: in certain scenarios, when you write mySize.height, the generated code accesses mySize.width. If you are reading, you get the value of mySize.width; if you are writing, you clobber mySize.width. Similarly, myPoint.y actually accesses myPoint.x.
You may never see this problem. I only saw it on older iPod touch devices running iOS 4.2.1, and only in Release builds, and only when compiling with Apple LLVM Compiler 3.0, and then maybe only sometimes. But I reported it to Apple and they say it's a duplicate of a known bug (#10043857) that they are addressing. Connecting a few dots, I am guessing that it's somewhere in the compiler chain in Xcode 4.2.
The workaround is to take the address of the CGSize or CGPoint struct, then use pointer arithmetic to access the desired member. I wrote a set of little helper functions to do this, and I call them all over my app's code.
I'm trying to workaround a long-running bug in Apple's SDK here, but I can't see how to achieve it without huge amounts of code.
Here's the bug:
Create a view.
Put another view inside it, with an origin ANYTHING except (0,0).
Configure the subview to resize to fill
...then, at runtime:
4. Set the superview size to zero
5. Set the superview back to ANY non-zero size
BANG! Apple's SDK goes haywire, resets the origin of the subviews, loses all ability to tell up from down, etc. (seems like the programmer "Forgot" to include a variable to record what the spring/strut-size was before it went to 0).
I've heard this bug has existed in OS X for 5 years or so, and Apple still hasn't fixed it. What I would like is some way (any way!) of working around it, without re-writing Apple's entire springs/struts system and implementing it properly, without the bug. Unfortunately, I can't even find the original references to the OS X bug that someone showed me previously.
EDIT:
...I have a resizing "drawer" at the bottom of the screen that has to shrink to small height. The problem is subviews "collapsing" all down to origin 0 (amongst other things) at the drop of a hat (technically: they're reducing their origin.height, but not re-increasing it).
The best solution I have found is to limit your minimum window size so that none of your views can ever hit zero size.
EDIT: an hour later, the collapsing behaviour has returned, without me touching the source files. I'll use source-control to double-check, but I believe all that happened is I added other files to a different part of the view-hierarchy and re-built. Argh!
(what follows SEEMED to work, but is now failing again, in the same way)
Hmm. So, I had two UIVC's on one screen. Refactoring so that I only had one made the resizing bug vanish. It seems to be a bug in the UIVC layout code.
NB: I had the idea this might be a problem because I know Apple currently advises you to only have one UIVC on screen at once with iPhone, even though this means you have to ignore their MVC architecture for complex apps. So, technically, they warn you away from this. But, at the same time, I'm now unable to use the MVC stuff for this code.
The following worked (for my current example - may not be universal!).
HOW:
If you're adding any UITableViewController instances ... give up. You'll have to re-implement that class yourself
Find my subviews that were in UIVC instances, and change the extended class in the UIVC header from "UIViewController" to "NSObject"
Move all code from viewDidLoad to init (remembering that "init" has special rules about first few lines etc)
Replace the instantiation of that UIVC from "[[vc alloc] initWithNibName:nil bundle:nil]" with a plain "[[vc alloc] init]"
Another potential workaround (that works in my current situation):
The only View I have right now that MUST have a non-zero origin and MUST resize-to-fit is a UITableView.
Apple has a special feature of letting you put any view as a "table-header".
So ... I've taken all my other components, stuck them in a large view, and made that the table-header view.
The downside is that they now scroll off the top when you scroll the table, but it allows me to give the table a zero-origin, working around the SDK bug.