I have a subview that covers the full screen of the iphone 5, and whenever I build and run all of a sudden its frame is (0,-40,320,586) instead of (0,0,320,586). So it like moves up for some reason. Right now I unchecked 'use autolayout' in the file inspector. This gets rid of all those annoying constraint thingies which I don't understand what they do.
Whenever I check 'use autolayout' enabling the constraints I notice this fixes the problem, and the subview doesn't randomly move up 40 pixels.
However, I can't keep these constraints on because I do animations with the subview, which don't work whenever the constraints are enabled.
What can I do?
If you use autolayout at any point read and learn about the autolayout system and constraints. If you don't want to, turn it off and don't use it.
In your case, if you want to get rid of it for a single view, perhaps it is enough to remove all constraints from that view. That can be done like this:
[view removeConstraints:view.constraints].
Autolayout reference.
Related
I have a custom subclass of UIButton that I want to re-use in multiple projects, some of which use interface builder and storyboards, and some of which may not. It involves setting the button's frame in several places.
If I add
self.translatesAutoresizingMaskIntoConstraints = YES;
in the initialization, everything looks and works right, however, I get:
Unable to simultaneously satisfy constraints.
Probably at least one of the constraints in the following list is one you don't want. Try this: (1) look at each constraint and try to figure out which you don't expect; (2) find the code that added the unwanted constraint or constraints and fix it. (Note: If you're seeing NSAutoresizingMaskLayoutConstraints that you don't understand, refer to the documentation for the UIView property translatesAutoresizingMaskIntoConstraints)
Will attempt to recover by breaking constraint…etc
logged to the console. However, if I set
self.translatesAutoresizingMaskIntoConstraints = NO;
none of the button sizing works and the button is completely broken.
Is there a way I can suppress the error since it seems to degrade to the right thing or can I somehow manually remove the offending constraint?
I've tried dumping the constrains after the button is initialized, however, it does not seem to contain the constraint AutoLayout ends up breaking.
Edited: Below are links to a sample project and then my button code. It works great when auto layout is turned off in the storyboard, however, when auto layout is turned on, the buttons seem to position at the origin (seems to be because when initWithCoder is called, the buttons don't have superviews or any position information).
http://www.kudit.com/dump/KFB.zip
http://www.kudit.com/dump/KuditConfirmButton.zip
Your guess is correct, in that when the buttons are initialized from the storyboard (using initWithCoder:) the frame is zero - this is expected for views using autolayout - frames don't get assigned until later on.
I have your sample project mostly working under autolayout by creating a boolean ivar called hasSetup, which get set to YES inside the setup method. The setup method doesn't run if the frame is zero. I also call it again from layoutSubviews. This gets around the not-working-when-using-autolayout in storyboard problem.
The various layers still aren't the correct size though. You may want to look into resizing them from layoutSubviews.
You also can't use setFrame under autolayout - you need to make sure any constraints on your view (like the sizing constraints from the storyboard) are adjusted instead. It's going to get quite messy dealing with both possibilities.
They look really good though - hope to see them on GitHub when you've sorted these problems.
I'm using a UIScrollView to display a custom UIView. When the user drags a finger across the UIScrollView, there is a noticeable delay before the display begins updating. If the user keeps touching the screen, the UIScrollView becomes very responsive after a short time. Subsequent attempts to scroll result in the same initial delay, followed by high responsiveness. This delay seriously affects the usability of the view and I would like to get rid of it.
In a test project I have written to try to get to the bottom of this issue, I have only been able to partially replicate the behaviour. The first time that the user scrolls is exactly the same - however any subsequent attempts to scroll are responsive straight away.
I have tried both setting delaysContentTouches = NO and subclassing UIScrollView so that touchesShouldBegin returns NO as suggested in multiple places online, but neither has worked.
I'm using MonoTouch on iOS 4.3, but Objective-C answers are fine. I would post code to help illustrate the issue, but since I have been unable to narrow down the problem this would be well over 1000 lines. Hopefully this is enough info to get a solution.
Does anyone know what might be causing this delay, and how I can get rid of it?
Some general suggestions for improving scrolling performance.
Have your scrolling views rasterize offscreen:
myView.layer.shouldRasterize = YES;
Set that property for each sub-view on the scrollview - do not set it for the children of those sub-views or you just eat up memory that way.
If your scrolling views do not need compositing, make sure you turn that blending off:
myView.opaque = YES;
Test using the simulator by leveraging these two features that appear on the Debug menu of the iOS Simulator:
Color Off-screen Rendered
Color Blended Layers
If that doesn't address your problem, and you have implemented UIScrollViewDelegate, double-check to make sure you are not doing anything time consuming in those methods - for example, based on your description, you might be doing something in scrollViewDidScroll, scrollViewWillBeginDragging, or scrollViewWillBeginZooming and if you are, optimize that so it happens before scrolling even begins. Also, make sure you're not doing anything in touchesBegan.
I suspect what is happening is there is some kind of interaction enabled in the content of your scroll view.
The system does not know if the initial touch down is going to be a tap on one of the subviews or a drag on the scroll view, therefore is causing a delay while it waits to see if you are going to lift your finger.
What are the subviews of the UIScroll view?
As an experiment set all the subviews of the UIScrollView to have userInteractionEnabled = NO, this will not be what you want, but its just a test. Is should scroll fine after this, otherwise I am wrong.
Please lead me in the right direction.
I need to provide user with small text centered on the iPhone screen. User can make quick scroll left or right in order to get the next or previous text. There can be hundreds of such text pieces. The process itself is similar to Photo application sidescrolling but much simple, no zoom.
As far as I can understand I need to use UIScrollView class, then call hundreds of addSubviews?
Is it the optimal way or I should always keep 3 subviews and replace them on the fly?
What kind of tricks should be used to achieve the "scroll and center" effect?
Thanks
You could use a UIScrollView with pagingEnabled = YES for the "scroll and center" effect, I guess.
Then only add the subviews that you're actually displaying, otherwise you'll run out of memory very quickly.
In the UIScrollViewDelegate, in -scrollViewDidScroll: you can get the current contentOffset and determine which subviews you need to add and which ones can be removed.
I'm using a UISwitch-Component at the bottom of a view that sits within a UIScrollView.
Now the problem that appeared, is that the switch is nearly impossible to swipe because the UIScrollView seems to dominate the userinput.
Switching works very well by tapping the switch, but from my point of view, most users "switch" the UISwitch instead of tapping.
Did anyone of you face the same / or similar problems and managed to come up with a solution?
thx in advance
sam
You have a design decision to make: if your content is meant to scroll horizontally, then a user swipe over a switch is ambiguous -- does it mean they want to scroll, or toggle the switch?
The easiest solution is to modify your UI so that this ambiguity disappears. For example, if the scroll's contentSize is not wider than the bounds of the scroll view, then it can't scroll horizontally, and a horizontal swipe will always activate the switch.
If you do want to allow horizontal scrolling, then it makes sense to replace the UISwitch with a UIButton that toggles on touch, similar to a play/pause button.
On the other hand, if you don't want to modify your UI, you could always just do:
myScrollView.delaysContentTouches = NO;
This will cause your switch to "get" the touches immediately, rather than have them go to the UIScrollView first. More info here. (You can also set this boolean in Interface Builder, as pointed out by Squeegy.)
I'm trying to figure out if I can get what I want out of UIScrollView through some trickery or whether I need to roll my own scroll view:
I have a series of items in row that I want to scroll through. One item should always be centered in the view, but other items should be visible to either side. In other words, I want normal scrolling and edge bouncing, but I want the deceleration when the user ends a touch to naturally settle at some specified stop point. (Actually now that I think of it, this behavior is similar to coverflow in this respect.)
I know UIScrollView doesn't do this out of the box, but does anyone have suggestions for how it might be made to do this, or if anyone's spotted any code that accomplishes something similar (I'm loathe to reimplement all the math for deceleration and edge bounce)
Thanks!
There is not a whole lot of trickery to this. Just use an UIScrollView with paging enabled. Make it the size of one of your items, and locate it where you want that item to appear. Next, disable the "Clip Subviews" option on the scroll view (either in IB, or programmatically), and you are all set.