Rather than implementing a clunky, potentially bug-ridden custom table, I went with the much simpler rotate table option. The problem comes in when I decide that, rather than initializing rotated contents, I want to rotate the cell itself and cut down on the amount of code in complex cells.
The following lines are immediately after cell configuration.
This causes every cell to rotate 90° on load, regardless of orientation:
cell.transform =
(CGAffineTransform)CGAffineTransformRotate(cell.transform, (M_PI / 2.0));
cellRotated = YES;
And this option only rotates the first cell once, but preserves the rotation:
if (!cellRotated) {
cell.transform =
(CGAffineTransform)CGAffineTransformRotate(cell.transform, (M_PI / 2.0));
cellRotated = YES;
}
Can cell orientation be tracked with an existing function (or set thereof)?
I can't find anything about this with Google. There are related questions, but mostly about tables and Portrait/Landscape UI orientations, so the counter-rotation implementation is quite a bit different.
EDIT
If I move cellRotated = YES to viewDidAppear: every cell except one gets rotated. (And then cell reuse makes it so that, in this case, every sixth cell is left alone.)
1-5 is good, 6 is bad, 7-11 is good, 12 is bad, etc (and then it changes in a perfectly logical but entirely unwanted pattern when I hit the end of the table)
Halfway there or a step back, I don't know, but that's what I have now.
If rotation is the only transform you do then why don't you just do this,
cell.transform = CGAffineTransformMakeRotation(M_PI/2.0);
and then,
if ( !CGAffineTransformIsIdentity (cell.transform) ) {
// Rotated.
}
Related
Say you have a UICollectionView with a normal custom UICollectionViewLayout.
So that is >>> NOT <<< a flow layout - it's a normal custom layout.
Custom layouts are trivial, in the prepare call you simply walk down the data and lay out each rectangle. So say it's a vertical scrolling collection...
override func prepare() {
cache = []
var y: CGFloat = 0
let k = collectionView?.numberOfItems(inSection: 0) ?? 0
// or indeed, just get that direct from your data
for i in 0 ..< k {
// say you have three cell types ...
let h = ... depending on the cell type, say 100, 200 or 300
let f = CGRect(
origin: CGPoint(x: 0, y: y ),
size: CGSize(width: screen width, height: h)
)
y += thatHeight
y += your gap between cells
cache.append( .. that one)
}
}
In the example the cell height is just fixed for each of the say three cell types - all no problem.
Handling dynamic cell heights if you are using a flow layout is well-explored and indeed relatively simple. (Example, also see many explanations on the www.)
However, what if you want dynamic cell heights with a (NON-flow) completely normal everyday UICollectionViewLayout?
Where's the estimatedItemSize ?
As far as I can tell, there is NO estimatedItemSize concept in UICollectionViewLayout?
So what the heck do you do?
You could naively just - in the code above - simply calculate the final heights of each cell one way or the other (so for example calculating the height of any text blocks, etc). But that seems perfectly inefficient: nothing at all of the collection view, can be drawn, until the entire 100s of cell sizes are calculated. You would not at all be using any of iOS's dynamic heights power and nothing would be just-in-time.
I guess, you could program an entire just-in-time system from scratch. (So, something like .. make the table size actually only 1, calculate manually that height, send it along to the collection view; calculate item 2 height, send that along, and so on.) But that's pretty lame.
Is there any way to achieve dynamic height cells with a custom UICollectionViewLayout - NOT a flow layout?
(Again, of course obviously you could just do it manually, so in the code above calculate all at once all 1000 heights, and you're done, but that would be pretty lame.)
Like I say above the first puzzle is, where the hell is the "estimated size" concept in (normal, non-flow) UICollectionViewLayout?
Just a warning: custom layouts are FAR from trivial, they may deserve a research paper on their own ;)
You can implement size estimation and dynamic sizing in your own layouts. Actually, estimated sizes are nothing special; rather, dynamic sizes are. Because custom layouts give you a total control of everything, however, this involves many steps. You will need to implement three methods in your layout subclass and one method in your cells.
First, you need to implement preferredLayoutAttributesFitting(_:) in your cells (or, more generally, reusable views subclass). Here you can use whatever calculations you want. Chances are that you will use auto layout with your cells: if so, you will need to add all cell's subviews to its contentView, constrain them to the edges and then call systemLayoutSizeFitting(_:withHorizontalFittingPriority:verticalFittingPriority:) within this "preferred attributes" method. For example, if you want your cell to resize vertically, while being constrained horizontally, you would write:
override func preferredLayoutAttributesFitting(_ layoutAttributes: UICollectionViewLayoutAttributes) -> UICollectionViewLayoutAttributes {
// Ensures that cell expands horizontally while adjusting itself vertically.
let preferredSize = systemLayoutSizeFitting(layoutAttributes.size, withHorizontalFittingPriority: .required, verticalFittingPriority: .fittingSizeLevel)
layoutAttributes.size = preferredSize
return layoutAttributes
}
After the cell is asked for its preferred attributes, the shouldInvalidateLayout(forPreferredLayoutAttributes:withOriginalAttributes:) on the layout object will be called. What's important, you can't just simply type return true, since the system will reask the cell indefinitely. This is actually very clever, since many cells may react to each other's changes, so it's the layout who ultimately decides if it's done satisfying the cells' wishes. Usually, for resizing, you would write something like this:
override func shouldInvalidateLayout(forPreferredLayoutAttributes preferredAttributes: UICollectionViewLayoutAttributes, withOriginalAttributes originalAttributes: UICollectionViewLayoutAttributes) -> Bool {
if preferredAttributes.size.height.rounded() != originalAttributes.size.height.rounded() {
return true
}
return false
}
Just after that, invalidationContext(forPreferredLayoutAttributes:withOriginalAttributes:) will be called. You usually would want to customize the context class to store the information specific to your layout. One important, rather unintuitive, caveat though is that you should not call context.invalidateItems(at:) because this will cause the layout to invalidate only those items among the provided index paths that are actually visible. Just skip this method, so the layout will requery the visible rectangle.
However! You need to thoroughly think if you need to set contentOffsetAdjustment and contentSizeAdjustment: if something resizes, your collection view as a whole probably will shrink or expand. If you do not account for those, you will have jump-reloads when scrolling.
Lastly, invalidateLayout(with:) will be called. This is the step that's intended for you to actually adjust your sections/rows heights, move something that's been affected by the resizing cell etc. If you override, you will need to call super.
PS: This is really a hard topic, I just scratched the surface. You can look here how complicated it gets (but this repo is also a very rich learning tool).
how to make objects appear from (one side only), when I rotate them in iOS ?
What I want to happen, (as you can see i can add another face to my UITableview cell)
What is happening, i can't even add another face since the previous one is showing up again
The Code I'm using
func animate()
{
var id = CATransform3DIdentity
id.m34 = -1.0 / 1000
var transformAnim = CAKeyframeAnimation(keyPath:"transform")
transformAnim.values = [
NSValue(CATransform3D: CATransform3DRotate(id, 0 * CGFloat(-M_PI_2), 0, 1.0, 0)),
NSValue(CATransform3D: CATransform3DRotate(id, 1 * CGFloat(-M_PI_2), 0, 1.0, 0)),
NSValue(CATransform3D: CATransform3DRotate(id, 0 * CGFloat(-M_PI_2), 0, 1.0, 0))
]
transformAnim.keyTimes = [0, 0.5, 1.0]
transformAnim.duration = 0.7
self.imageViewLogo.layoutIfNeeded()
self.imageViewLogo.layer.addAnimation(transformAnim, forKey: "transform")
}
If you know a feature called [force 2 sided] in 3ds max for example, I want it turned of here, but it seems that iOS has no feature like this.
This is an advanced question, I wish an expert answers me.
Thanks.
EDIT
if you are still not sure what I'm asking, I mean this :
how to make an object to show only from one side when i rotate it ?
That is a standard flip transition. Take a look at the UIView method +transitionFromView:toView:duration:options:completion:, specifically the UIViewAnimationOptionTransitionFlipFromLeft and UIViewAnimationOptionTransitionFlipFromRight settings.
There is also a view controller transition if you want to do a flip transition to a different view controller.
If you want to build this animation yourself it's much more work.
What you have to do is create 2 separate animations, one for the front face and one for the back face:
First, you animate the front face rotating to 90 degrees, at which point it disappears because you are viewing it edge-on. At that point you add your back half view/layer, but facing the other way. Then in the second animation you rotate the new view 90 degrees, which leaves it flat and face-up. It's possible to get a seamless animation that gives you exactly the effect you want, but it's difficult, fussy code to write.
the solution was a simple statement that I never heard of before
imageViewLogo.layer.doubleSided = false
from apple's website :-
A Boolean indicating whether the layer displays its content when
facing away from the viewer. Animatable.
I've overridden NSTableRowView, which so far is working a treat. The problem I'm facing is drawing the separator for the empty rows.
drawSeparatorInRect:dirtyRect
only seems to override the rows that have content, all the rest seems to be filled with system colours.
At the moment I have:
-(void)drawSeparatorInRect:(NSRect)dirtyRect
{
NSRect sepRect = self.bounds;
sepRect.origin.y = NSMaxY(sepRect) - 1;
sepRect.size.height = 1;
sepRect = NSIntersectionRect(sepRect, dirtyRect);
if (!NSIsEmptyRect(sepRect))
{
[[NSColor gridColor] set];
NSRectFill(sepRect);
}
}
Which, as I said works well. I originally picked this up from some apple sample.
When I change the separator color to "red", you can see what happens:
The bottom-half of the last populate row is filled, but none of the others there after are.
Has anyone got an idea what I'm missing?
Cheers,
A
There are only row views for rows which have content. Therefore, a custom row view can not affect the drawing of separators for rows past the end of your table's content.
To customize the drawing of those separators, you need to override -[NSTableView drawGridInClipRect:]. You compute the position of the separator for where rows past the end of the content would be and draw the same way as your custom row view does.
This is explained, with example code, in the video for WWDC 2011 Session 120 – View Based NSTableView Basic to Advanced. It's also demonstrated in Apple's HoverTableDemo sample project.
Note: for this I am using a program called spritebuilder, which allows me to create a game with less code than would normally be needed. If you know a solution that's just all code, then by all means feel free to share it :)
Also, for this question, I followed a tutorial at this link: Build Your Own Flappy Bird Clone. Just scroll down to the part that says: "Loop the Ground"
So here's my problem. Im currently working on a game, and I created a camera which scrolls vertically long with the character sprite i created, however i need a certain image to loop. When the image leaves the bottom part of the screen I would like it to loop around to the top of the screen, infinitely. For this i created two identical images (in this case its the bark of a tree). One will be on screen, while the other will be offscreen, so as the first image leaves the screen, the second will replace it (seamlessly). I created two objects for the images, and assigned them the name _ground1, and _ground2, and I also created an NSArray in which to store them in. (Please refer to the link above if it is somewhat confusing)
Here is the code that I have:
CCNode *_ground1;
CCNode *_ground2;
NSArray *_grounds;
for (CCNode *ground in _grounds) {
// get the world position of the ground
CGPoint groundWorldPosition = [_physicsNode convertToWorldSpace:ground.position];
// get the screen position of the ground
CGPoint groundScreenPosition = [self convertToNodeSpace:groundWorldPosition];
// if the left corner is one complete width off the screen, move it to the right
if (groundScreenPosition.y <(-1 * ground.contentSize.height)) {
ground.position = ccp(ground.position.x , ground.position.y + 2 * ground.contentSize.height);
}
For some reason when I try this, it doesnt seem to work. what happens is that, the camera will travel vertically as it is meant to do, but the images do not loop. Once the two images leave the bottom of the screen, no new images replace them.
i also done this project as above tutorials. it work fine but you have some mistake to set variable in spritebuilder. in your above code replce code as and try it. you only put less than may be it issue.
if (groundScreenPosition.y <=(-1 * ground.contentSize.height)) {
ground.position = ccp(ground.position.x , ground.position.y + 2 * ground.contentSize.height);
}
You are using CCNode objects as _ground1and _ground2.
CCNode objects usually do not have a contentSize, they will return 0 unless you explicitly set them inSpriteBuilder`.
Make sure that you are using CCSprite objects in SpriteBuilder and in your code.
Also, as a friendly hint you should also consider refactoring (renaming) your sprites with more meaningful names for your use case like _treeBark1 and treeBark2 for example.
I’m trying to put together what seems to be a simple case of two NSTextFields with dynamic width and fixed spacing in between. I cannot figure out an effective way to do so though.
I’m looking to get something like this:
The blue boxes are the NSTextFields. When more text is entered into one, it should grow and thus make the other one shrink, maintaining the lead space, trailing space and the spacing in between the fields. The first one should take the priority if both of the fields have too much text. Each field will also clearly have a maximum and a minimum possible width it can reach.
How would I go around handling this, preferably utilising IB autolayout as much as possible?
It seems to me that all of constraints you mentioned directly translate into interface builder --
First view has width >= something.
First view has width <= something
Same for Second view.
Space between views is fixed.
Second view wants to be as small as possible (have its width at 0) but this has lower lower priority than the previous constraints and lower priority than inner content size constraints.
The code I had to add to my view controller, after applying the constraints as per the ilya’s answer:
In controlTextDidChange (_controlWidthConstraint refers to the fixed width constraint of the input; it’s probably 0 by default for the second input):
// Get the new width that fits
float oldWidth = textControl.frame.size.width;
[input sizeToFit];
float controlWidth = textControl.frame.size.width;
// Don’t let the sizeToFit method modify the frame though
NSRect controlRect = textControl.frame;
controlRect.size.width = oldWidth;
textControl.frame = controlRect;
_controlWidthConstraint.constant = controlWidth;
The key lies in invalidating the intrinsicContentSize for the text field when text is input.
You can check a sample project here, to get you on the right track.