I have designed my app for 4inch devices using xcode 5 and storyboard builder. Since the 3.5inch screen is a little bit smaller, I want to make my view scrollable.
This is what I have done: I added a ScrollView using interface builder and added my View (that contains all elements) as a subview of it.
I start the app using the 4inch simulator and it does not scroll - exactly what I want. But when I open it with the 3.5inch simulator my content gets cut and scrolling is not possible. Why? And how can I activate it?
have you implement the UIScrollViewDelegate Protocol
Do you use Autolayout?
You also want to make sure your scrollview's contentSize is set to your view's size.
Related
I have a ViewController with a hierarchy as follows:
UIViewController
UIView
UIScrollView
UIView
UIImageView
UILabel
The layout is such that the UIScrollView fills the screen. There is no extra logic executed on this ViewController, such as programatic scrolling, listening to scrolling, etc.
When I run this on an iOS 9.0 simulator, the layout is correctly inflated, with the UIImageView drawn flush against the top margin.
But when I run this on an iOS 9.1 simulator, there is initially a large whitespace between the top margin and the image. Upon touching the UIScrollView it corrects itself, scrolling that the UIImageView is flush against the margin.
Setting automaticallyAdjustsScrollViewInsets does not have an effect (presumably because the scrollview isn't at my root).
My question is: What is different about iOS 9.1 scrollviews that it would be causing this, and what is the work around? Its bothering me since this isn't exactly a complex layout I'm trying to use.
Edit
Screen shot of my hierarchy and the constraints applied to them, maybe it helps.
I think the issue might be the hight constraints. try getting rid of them and add them back in, one at a time as needed.
I have a UIView with a UIImageView at the very top, a UILabel below it, a UIButton below that, and a UISegmentedControl that determines what determines what embedded UIview to display at the bottom (which also a choice to not show any at all).
I've run into the problem where I've set up all of my constraints in the interface builder, and everything seems to be fine when I switch between screen sizes in the storyboard. However when I actually run the project on a device or emulated, the UIimage at the top is briefly stretched before "snapping" into a size the fits the constraints. Also, it seems as if the label disappears for a brief second and reappears after the image has snapped into a size. After the "snap" has occurred, everything is in place and there are no problems.
This snapping occurs both when testing on a 4 and 3.5 inch display. I find this odd because I've designed the UI for the 4inch screen perfectly.
Does anyone know why this is happening?
Edit
Here's whats the constraints look like in IB.
This is potentially due to adjustments that you might be making to your UI elements (or constraints) from the view controller in code. For example, if you are programmatically setting a different UIImage into your UIImageView, and this code is happening too late in the view lifecycle (for example, in viewDidAppear) after a layout pass has already calculated view positions and sizes, then you will see a visible snap as views take on new positions based on the new intrinsic content size of the image view.
This could be caused by other adjustments such as injecting a localized string into a UILabel in code, which causes the label to have a smaller or larger intrinsic content size, which in turn affects the layout based on your constraints.
If you are making adjustments to your UI in code, make sure they are happening in viewDidLoad or viewWillAppear: so that they occur before the view's initial layout pass (and the view's animation onscreen).
If you're still seeing issues, you can try explicitly forcing an immediate layout pass to occur on the view controller's view at the end of viewWillAppear: by doing the following:
- (void)viewWillAppear:(BOOL)animated {
[super viewWillAppear:animated];
[self.view setNeedsLayout];
[self.view layoutIfNeeded]; // forces an immediate layout pass
}
Spacing between the UIElements might be the problem . Specially when using Pickers
Got it, You have applied constraint for Picker to adjust along with segmented control. So when app runs on 4 inch screen , picker automatically fits properly, but for 3.5 Inch picker always starts from bottom of the screen and picker will push segmented control upwards and hence segmented control will push rest control automatically.
Remove picker and segmented control constraint.
I have a UITableView in a UIViewController which is inside a UINavigationController which is inside a UITabBarController.
When Developing using a 3.5" Simulator and having my storyboard set to 3.5" and everything works fine.
However if I use a 4" simulator, the UITableView ends too short up the screen. And if I do it the other way around the table view ends off the bottom of the screen.
How do I go about correctly sizing my UITableView?
(P.S. I'm not sure it matters, but I'm loading an AdBannerView which goes at the bottom of the screen, so I'm adjusting the contentInset of the UITableView after it is loaded to make space for the AdBannerView, but I don't think that makes a difference to this situation).
You need to add auto layout constraints so that the components are resized according to the desired logic.
Read Apple's Auto Layout Guide and you'll know everything you need in order to accomplish this.
In my app I have a UIScrollView with not many subviews that doesn't use Auto Layout but rather plain old Autosizing to fill itself to the size of the view controller. The only line of code that interacts with it is this:
settingScrollView.contentSize = CGSizeMake(320, 600);
The problem is that only on the iPhone 4/4S, it does this skip sort of thing when you reach the bottom of the scroll view. Here is a video of what happens.
Is this a UIKit bug or am I doing something wrong?
The problem seems to be a bug with iOS 7. This was a scrollview in a scrollview which, while I know is not best practice, worked just fine on the iPhone 5/5S form factor it had the strange behavior mentioned above on the iPhone 4/4S. Moving the daughter scrollview out of the parent scrollview and having it move as though it were in the parent scrollview.
I have a problem adapting my apps to the new iphone5 layout, I've made the following passes:
Added a retina 4" splash image
Modified the interface in my storyboard with "Size inspector" to change the anchoring of the widgets
Tested the app with iOS6 "retina 4" simulator.
The app works as expected except when the user pop up the keyboard to edit a text, I use the "stretching scrollview" method for this particular situation and this seems not compatibile with the "autosizing" properties of my widgets, here is an example, from iOS6 simulator, without and with keyboard:
And here is what happens:
I'm quite sure this is a coherent behaviour since my main view is stretched so the other items inside it are stretched following their anchoring, the fact is that I'd like to have the same behaviour of my previous fixed position (all widgets anchored to the top left corner) with the iphone5 gui expansion, is this possibile?
How do you solve the problem of showing a keyboard and scroll hidden content in an iphone 5 compatible way?
I have been having similar problems. From what I have found thus far, we may need to remove all constraints on the view within the scrollable view, because it appears that it's contents are being resized along with the frame of the scrollView. I know that setting the internal view's frame manually in viewWillAppear will work, but then you are stuck having a view that is the same size for both iPhone4 and iPhone5 (albeit it will scroll). Or you could "pin height and pin width" of the internalView right there in storyboard.
Two potential approaches that may work. Sorry I can't confirm these as I'm giving up and redesigning around this problem.
1. Programmatically add constraints to your internal view's subviews. The programmatic constraints will allow you to "spring" the distance between your elements proportionally. When adding constraints programmatically, you are given access to a factor called "multiplier" (not to be confused with priority), which I saw someone else on stackoverflow posting about.
2. You can design the internalView in Interface Builder as a separate viewController with it's .xib file, and then use storyboard to load it as an embedded viewController to a "containerView" object, which you would put in place as the new "internal view" of the scrollView. Perhaps then the .xib would first resize to the correct iOS device, and then you could use its frame to resize the containerView.
My advice is create a small test-case of these before implementing, else you end up like me, having spent hours down the wrong path and facing a dead-end.
UPDATE 12/4/12
Make your life easier by NOT setting the ScrollView as the main view of the ViewController.
--Instead, make ViewController.view a dummy/blank view, and embed a scrollView inside that view. Then, embed another view (my CustomView) in the ScrollView. CustomView contains all the visible controls and text boxes and buttons. There is NO HEIGHT CONSTRAINT on CustomView.