I have a UIScrollView with paging enabled, and a corresponding UIPageControl to indicate the current page. This works well, but I'd like to introduce inertial scrolling to navigate multiple pages with one swipe.
One example I've seen of this is the StickTennis app for iOS. How can I do something similar?
You'd set the pagingEnabled property of the scroll view to NO, then you'd calculate the speed of the scrolling at the moment the user's finger leaves the screen using numerical derivation. From now on, you could use the s = v0 * t + a / 2 * t ^ 2 formula to calculate the new position of the scroll view (when a is a constant deceleration rate and v0 is the speed you just calculated), and then you'd repeatedly call scrollRectToVisible:animated: with an appropriately updated rect argument.
Related
I have 3 buttons which I would like to center at the top of my ViewController, so that they remain centered regardless of the screen size of the iPhone or iPad. I have tried to:
Use leading space and trailing space on the buttons either side of the view controller to center them.
Put the buttons in a View and then center the view relative to the ViewController.
Add the constraints as ratios.
Use constraints on buttons.
None of these methods seem to work for me and I cannot figure out how to solve this. I have looked around for solutions but I cannot find anything that allows me to do this.
None of these methods seem to work for me and I cannot figure out how to solve this. I have looked around for solutions but I cannot find anything that allows me to do this.
It's easy to "center" the group of buttons using nothing but constraints. Here's an example:
To achieve this, I first constrained Button 2 to the horizontal center of the safe area, and I constrained it's top to the safe area's top plus 128px. Then I constrained the top of Button 1 and Button 3 to be equal to the top of Button 2. Finally, I constrained the trailing of Button 1 to the leading of Button 2 plus 100px, and the leading of Button 3 to the trailing of Button 2 plus 100px. Here's how the constraints are listed:
I'm not sure why this isn't working for you -- you didn't give us any information about how your attempt failed. The other methods you listed should also work. For example, you can certainly put the buttons inside a view and center the view in the safe area or main view.
If you want the spacing to be proportional to the width of the screen, you can use the multiplier field of the constraints. For example, delete the horizontal spacing constraint between Button 1 and Button 2, and then create a new one that constrains the centerX of Button 1 to centerX of Button 2. Next, select the constraint that you just created and set it's multiplier field to, say, 0.5. You can do the same for Button 3, but set the multiplier to 1.5. Now you'll have Button 2 centered in the safe area, and the other two buttons placed half way between the edge and center of the safe area, regardless of the screen dimensions. You can change the values to get different spacing, of course.
I want to find out the scroll view position of a list view, if we change the scrolling position little bit also. I have browse the net many solutions suggested that using 'ItemAppearing' event in list view but that event is not satisfying my requirement because that event fire only when item will be changed at the time of scrolling but In my list each item height is nearly equal to the my screen height that's for changing the item it takes large position of scrolling. Because of that after scrolling large position only that event will fired but what my requirement is just changing the little position of scrolling also need to detect that one. Please suggest any idea. Thanks in advance.
I have read in numerous places that constraints in Cocoa AutoLayout act on the visual bounds of the control/view in question so the below is perplexing (2me):
In Xcode IB, I add/drag two (push button) buttons to a view (one underneath the other) and constrain them such that they have zero distance between themselves vertically. I expect two buttons that are flush against one another in the vertical direction.
The result is two buttons that DO have a small difference/space between them which can be verified visually or by looking at the alignment rectangle values in Xcode. In this instance the additional distance between them appears to be 1 point.
Below is a screenshot of the constraints amongst the simple view hierarchy:
Further, confirming the above, when you change the constant in the constraint to -1, the two buttons appear flush with one another.
The above is on OS X 10.10 (Yosemite).
Stranger still, in my actual application (the above is just a test case for the SO question) when I stack many NSButton vertically (programmatically and not via IB) I need to provid a constraint of -4.0 between them (as opposed to the -1.0 above) to make them flush. The bezelStyle for this button is as follows (Swift):
self.bezelStyle = NSBezelStyle.RoundedBezelStyle
[Although it doesn't make sense, I would be much more comfortable if it were uniformly -1.0 needed to make them flush!]
UPDATE I:
I think I have found why my application is behaving differently to the test example. I have used a NSBezelStyle.RoundedBezelStyle in code and set its height to be 24.0; various things point to this button style/type needing to have a fixed height (see IB where the height parameter is greyed out and fixed at 21.0 and cannot be changed!) The difference between 24 and 21 is 3.0 which is exactly what we are seeing is the difference in main application constraints -4.0 relative to rest example required -1.0
The moral of the story: don't use RoundedBezelStyle outside certain usage scenarios where variable height is needed! PostScript: RoundedRectBezelStyle seems to suffer the same malady!
That still leaves the question of why certain buttons in the test example are not flush with a constraint of -1.0 being required...
UPDATE II:
Further testing shows that I get different results depending on which "type" of button I choose. In code this would be linked to the bezelStyle property of the button.
The gradient button sits flush with a constraint of zero between buttons
The textured button seems to need to need a +1.0 constraint between buttons to avoid overlap
Most of the other buttons (especially those with rounded bezel styles) seem to need constraint of -1.0 between themselves to be flush
REVISED QUESTION (based on my findings):
Are the above intentional from Apple (is there some logical/rational explanation) OR are they bugs?
If the above is true, is it bad practise to code my user-interface (a spreadsheet-like grid) with these fudges for "flushness" built-in to how I layout my view?
How a view lays out in regards of it's bounds is up to the view itself.
What you have seen is the style of the button not covering then entire frame set up by autolayout. That is correct behaviour.
I have a window I'm setting up with auto layout. There is a view in the middle of the window that contains three controls, and I would like the window to refuse to resize horizontally smaller than the intrinsic size of those three controls.
The outer buttons both have horizontal space constraints to "stick" them to the outside of their superview, and the checkbox in the middle has a horizontal space constraint sticking it to the left side of the "Sync text" button. There is also a >= constraint between the "Sync outline" button and the checkbox, to make sure they don't overlap, but the checkbox prefers to hang to the right. All these constraints have a priority of 1000. The window itself has no minimum size specified.
When I use the "Simulate Document" command in Xcode, everything works as I'd expect, and the window won't let you size it smaller than in the screenshot above. However, when I run my application, the window does allow resizing smaller than that width, so that the buttons start to shrink and eventually the controls overlap each other. I'm not implementing any of the size related window delegate methods, so I don't see any place in the app's code where it might be influencing the resizing.
Any ideas on what could be causing this difference in behavior?
OK, I finally figured out what the heck was going on here. It turns out the problem was that I was implementing the -splitView:constraintMinCoordinate:ofSubviewAt: delegate method (as well as the maxCoordinate one) to restrict the size of the split subviews in the vertical direction. Yes, restricting the vertical resizing of the split view affected the horizontal layout of the buttons.
It appears that what happens is that, if you implement those delegate methods, NSSplitView reverts back to using autoresizing masks to layout the subviews rather than auto layout constraints. Since the view containing those buttons is no longer participating in auto layout, the buttons smush together when you resize the window small. In the simulator, the split view doesn't have a delegate set, so all the auto layout stuff works fine in that environment. Note that merely having the methods implemented is enough to trigger this, even if they just return the proposed coordinates unchanged.
The solution ended up being quite easy, which was to delete the delegate methods and replace it with a vertical constraint on the subview to restrict its size instead.
I have a drag n drop kind of app. Where you can select images and drag them anywhere on the screen!
The problem I'm running into is, when you move to another view, all the images reset to the center, when I return back.
For example if I press a button to take me to screen 2, all the "dragged" images I just did, will move back to the center.
This only happens when I have AUTOLAYOUT enabled :(
I have all my images start out in the center, so I'm guessing its something with autolayout...
Any ideas ?!
Here's an example of my drag image code.
- (IBAction)handlePan:(UIPanGestureRecognizer *)recognizer {
CGPoint translation = [recognizer translationInView:self.view];
recognizer.view.center = CGPointMake(recognizer.view.center.x + translation.x,
recognizer.view.center.y + translation.y);
[recognizer setTranslation:CGPointMake(0, 0) inView:self.view];
}
Your drag and drop code is manually configuring the layout by mutating the view.center property.
Once auto layout is enabled, auto layout takes responsibility for setting up the layout, so it takes exclusive responsibility for setting view.center, view.bounds, and view.frame (which is actually just calculated from center and bounds).
So once auto layout is enabled, although you can still set view.center manually, auto layout will clobber whatever you do the next time it calculates the layout that satisfies the constraints you have in place.
So how do you update your code to work with auto layout? If you want to use auto layout, what you need to do is modify your handlePan: method so that instead of modifying view.center it modifies whichever auto layout constraint is being used to calculate view.center. The details of this will depend on your constraint configuration. But if we assume, for example, that there is an NSLayoutContraint topSpaceConstraint that sets the view's top space to the superview, and another NSLayoutConstraint leftSpaceConstraint that sets the view's left space to the superview, then you could produce the same effect as
view.center = CGPointMake(view.center.x + translation.x,
view.center.y+ translation.y);
by instead doing something like
topSpaceConstraint.constant = topSpaceConstraint.constant + translation.y;
leftSpaceConstraint.constant = leftSpaceConstraint.consant + translation.x;
[view setNeedsLayout];
[view layoutIfNeeded];
The first two lines update the constraints. The last two lines cause the auto layout system to recalculate the resulting frame and apply it right away, rather than waiting until the next turn of the run loop.
Alternatively, you might be able to get away with updating the frame manually when you get UIGestureRecognizerChanged events, and then making the result "permanent" by updating the constraints as shown above only once you get UIGestureRecognizerEnded event. That would be more performant, since during the many UIGestureRecognizerChanged events you'd be updating the frame directly rather than relying on the auto layout system to do it.