I am using UICollectionsView insertItemsAtIndexPath and it is very annoying such that when I am scrolling on the UICollectionView and then it calls insertItemsAtIndexPath it slides with the item. I want this inserting to be seamless and just append it to the top without user knowing that something has been appended on top. How can I do this?
I suppose you will have to subclass the UICollectionViewFlowLayout and then in the - (UICollectionViewLayoutAttributes *)initialLayoutAttributesForAppearingItemAtIndexPath:(NSIndexPath *)itemIndexPath just return nil. That way, it will directly place it to the final position and hence no animation should take place.
Related
I'm trying to expand a UITableViewCell to fill the entire screen using CoreAnimation.
How can I animate a TableViewCell so that it looks like the cell is expanding to fill the entire screen?
I will then push another ViewController in the completion block of the animation (without the user noticing).
I don't think it's possible to take the actual cell and expand it to fill the screen, because the TableView is managing the cell and could respond rather poorly to the cell's size going crazy all of a sudden.
What I would do is make a 'copy' of the cell using your own class extending UIView, display the copy directly above the cell of the table view (let me know if you need details on that step or if you can figure it out yourself), and then animate that to fill the screen.
For tips using CoreAnimation and layers, go try google - there's a lot out there already on the subject.
For a simple example lets say I have a UITextView with a Button underneath it. These two controls are siblings both embedded in a parent UIView.
I now change the text within the UITextView and resize it accordingly. Is there a way to make the button automatically move to have the same relative distance to the bottom of the UITextView? This may seem trivial for this case, but I will have a longer hierarchy with multiple UITextViews that change and it would be nice not to have to calculate the height of every object manually.
One way to approach this would be with a table view: if you place each of your text views within its own table view cell, the table view will automatically calculate its total height from individual calls to its delegate’s -tableView:heightForRowAtIndexPath: method and lay itself out accordingly. Whenever the height of one of your text views needs to change, you can call -reloadData on the table view to make it lay itself out again. A disadvantage of this approach is that it’s really difficult to animate the height changes; if that’s essential to the effect you’re going for, I’m afraid you’re stuck with doing the entire layout manually.
Try the autoresizingMask property of UIView.
I need a "PickerView", that behaves like a normal UIPickerView, but only shows one row of data and has a custom design.
Something like you see in the image, showing the transition from subview 1 to subview 2. After the user lifts his finger and after the scrolling stops, only one subview will be shown:
IMAGE
So basically a scrollview which:
is endless in both, positive and negative directions by showing the same entries over and over
uses paging across several subviews
only shows one subview when not scrolling, and no more than two subviews when scrolling.
I can get a endless scrollview to work, but not with paging enabled. Paging will always limit my scrolling to the next subview.
So I'm thinking about creating my own UIView subclass which custom scrolling behaviour to mimic a UIPickerView. But before doing so, I wanted to get some opinions about the idea in general. Is creating a custom UIView the right way to go? Anyone has some experience with the expected performace? (There will be timers to handle the scrolling algorithm, which has to be recreated of course... :)
Another approach would be to subclass UIScrolView and implement the paging myself. I know when the scrollView starts decelerating
, so maybe there is a way to overwrite the contentOffset to have it scroll into the right position...?!
Any help is appreciated! Thanks!
Here is a great custom component, which seems to be able to do everything you need:
http://dev.doukasd.com/2011/04/infinite-scrolling-dial-control-for-ios/
It's not endless, but rather a modified UITableView with a huge number of cells.
Would it be feasible to just use a UIPickerView, but clipped to the middle row? You could turn off showsSelectionIndicator to remove the overlay and have the delegate pass back custom row views.
I am having a hard time trying to make the very last UITableViewCell from my table to get to the UITableViewScrollPositionTop.
The behavior I would expect is:
On didSelectTableAtindexPath:lastindex, the table would bring the last cell all the way up to the top position... I would do whatever is needed, then, I could resume the positioning (pretty much like what happens when we use a textField inside the cell and the keyboard fires up)
Does anyone know how can we get that kind of behavior?
I got it by myself actually...
If anyone is having the same issue, here is what you should do:
right before using the scrollToRowAtIndexPath:atScrollPosition:animated:
use:
aTableView.contentInset = UIEdgeInsetsMake(aTableView.contentInset.top,
aTableView.contentInset.left,
aTableView.contentInset.bottom+300,
aTableView.contentInset.right);
do what you have to do and then:
aTableView.contentInset = UIEdgeInsetsMake(aTableView.contentInset.top,
aTableView.contentInset.left,
aTableView.contentInset.bottom-300,
aTableView.contentInset.right);
the only problem is that the comming back from the inset is not animated, but I guess you can set an animation to smooth the transition...
Use this delegate methods to scroll top or bottom
scrollToNearestSelectedRowAtScrollPosition:animated:
scrollToRowAtIndexPath:atScrollPosition:animated:
selectRowAtIndexPath:animated:scrollPosition:
I am trying to create a excel like view in my app. To do that I wanted to achieve both horizontal n vertical swipes at the same time .i.e., if the vertical scroll would fill with rows and the horizontal with columns.. have no clue hw to begin with.
This is an interesting question. For sure I would say start with UIScrollView, and set the content size bigger than the screen size, exactly how big is up to you.
Next you'll want to make some kind of implementation that efficiently figures out what cells are on screen. If I were you I would do something similar to how UITableView is done, i.e. make a custom object that keeps track of what indexes should be on screen based on the offset of the scroll view.
Next you'll need this custom object to either directly or indirectly get the visible cells to display themselves on screen when they are visible, and remove them from the superview when they aren't. I'd also recommend reusing the views that are offscreen.
This is a moderately challenging thing you are trying to make, so be sure you are very organized and don't be scared to make a few new custom object to perform specific tasks.
Sample interface file:
#protocol doubleTableViewDelegate
-(NSInteger)heightForRow:(NSInteger)row;
-(NSInteger)widthForCol:(NSInteger)col;
-(NSInteger)numberOfRows:(NSInteger)rows;
-(NSInteger)numberOfCols:(NSInteger)cols;
-(UIView *)cellForRow:(NSInteger)row col:(NSInteger)col; //get the custom table view to store and dequeue these, i.e. store them in an NSSet when they go offscreen, and give them back when a certain function is called.
//There's probably a few functions missing here still.
#end
#interface doubleTableView: UIScrollView {
id<doubleTableViewDelegate> infoDelegate;
}
//your functions to show and remove cells as needed
#end
You'll need to work out the rest, but keep updating this page and I'll try to help out.
Good luck with this, let me know how it goes.