on clicking red circular button When delete button appears , It pushes cell content view to left. I want content view to keep on its place.
Suggest me ways to achieve this task.
This is how UITableViewCells are designed in iOS7. They push the content view aside. I'm not sure if there is a built-in way to avoid this. I would bet not, it's how apple acts sometimes :(
One possible solution would be to reproduce the iOS7 tableViewCell. You would need to build an subclass of UITableViewCell and implement the slide to delete functionallity manually. You can create a custom protocol or call the UITableViewDelegate protocol. But you would have to set you tableViewDelegate as the delegate of the single cell.
The guys of teehan+lax did that as iOS7 was still under NDA. They build the complete look and feel for iOS6 or less: teehan+lax blog post
I hope this is a possible solution and the post will help you!
Sorry if you ran into complicated reproduction process. The tableViewDelegate does actually give you a method for this:
- (BOOL)tableView:(UITableView *)tableView shouldIndentWhileRowAtIndexPath:(NSIndexPath *)indexPath {
return NO;
}
[cell setShouldIndentWhileEditing:NO]; could also work.
Related
so I am exploring the new tvOS. As I wanted to kind of replicate the horizontal feature section of the app store (e.g. "Best New Apps")
My plan was to use a UITableView to lay out the base structure (rows) and use an UICollectionView for all the individual horizontally scrollable items.
Unfortunately the tvOS always focuses the UITableViewCell, not the UICollectionViewCell inside. I've already read about the
override var preferredFocusedView: UIView? {
return aView
}
So using this inside my controller is kind of hard regarding getting the correct subview.
Is there anything I could look into or could someone please point me in the right direction? Iterating through all subviews until I get the correct one seems like a bad idea.
Thanks a lot!
I tried out a similar situation where I had a CollectionView within a CollectionView to get the setup you described. Let's call them innerCV and outerCV. To get innerCV to be focused and not outerCV's cells, I set this delegate method to return false for outerCV.
- (BOOL)collectionView:(UICollectionView *)collectionView canFocusItemAtIndexPath:(NSIndexPath *)indexPath {
return NO;
}
In turn, innerCV's cells are now focusable as opposed to outerCV's cells.
Credit for this goes to Apple. I used their sample project as a guide to start. Check out the Focus samples within their project.
Sample Project: Apple tvOS UIKitCatalog
I used a different approach..
Setting the tableview selection property to No Selection in storyboard makes the focus engine to focus on UICollectionViewCell cell rather than UITableViewCell.
Hope it helps :)
Image
I have a class as "myUIImage" extended from UIScrollView. it has a UIImageView variable.
ViewController delegates "UITableViewDataSource , UITableViewDelegate".
when I add a myUIImage object into all cells in cellforRowAtIndexPath function,(With a cellview that fills whole cell(frame size are same)), the problem occurs.
When i touch one of the rows didSelectRowAtIndexpath returns wrong row index on iOS7. it works well older versions.
I put the example xCode Project here ;
https://www.dropbox.com/s/ps7cc8l51v0grxb/repeatboxDeneme.zip
Thanks For Your Help...
Edit1:
Here is a sample video. Please watch carefully the Logs on down-right side.
http://www.youtube.com/watch?v=5f8-nrlWCIY&feature=youtu.be
This is working perfect on both iOS 6 and iOS7 because i've seen your code. And your code is also perfect. But there is a problem that is you are not using reusable cell. So might be it create problem releated to memory and its not a good practice.
This is no normal behaviour of UITableView. But it looks to me like it just happens if you clicked while scrolling and if it stops it remembers your last click position.
I would recommend you, to insert an UITableView into to your view inside the Storyboard. Connect the Delegate and Datasource of your UITableView with the Filesowner and than just use the methods
numberOfSectionsInTableView
numberOfRowsInSection
cellForRowAtIndexPath
didSelectRowAtIndexPath
Maybe the way you generate your tableview programmatically, there are any attributes missing. The other way you just can look at the InterfaceBuilder settings on the right and can change the settings much easier.
I am implementing a UIScrollView which behaves mostly like a UITableView, a bit more advanced with that.. but most of the API used are the same signature.. cellForRowAtIndexPath.. etc. First before people start storming why not just use a UITableView, let me just say that I can't. The reasons are fairly complex, but that is a decision been made.
The issue is now I am implementing infinite scrolling, basically when I scroll down and I am at 65% of the full contentHeight I am doing an async request to the backend to fetch more data and adding it to the data source and then calling reloadData. The issue is that if I am calling reloadData while the user is scrolling, it doesn't provide a very smooth scrolling experience. So what is the best way to tackle this? Also I noticed that reloadData basically refreshes the entire table view (in this case my scroll view). In my table view cell I am animating a UIImage to fade in. So when reloadData is called, the image that is already presented is being faded in again, which is kind of annoying.
How do I avoid such things?
Any tips and tricks?
In case you're still working on this, check out PSTCollectionView. It works exactly like UICollection view but supports backwards of iOS 4.3.
Its difficult to answer without knowing why you need to create a custom view similar to the tableview. If you have a developer account you might want to check the new iOS 6 view based on tableview. Not sure if I can talk more about it as it is under NDA.
For the UIImage fading, how about flagging each UIImage as displayed and then do a check when reloading the data or recalling the fade statement. Only fade the images that are not flagged as already presented?
In new iOS 6.0 there is new controllers call UIContainer view,its similar to UITableview but we can also set more then one column with that.
delegate methods for that controllers are almost same as in UITableview.you can use that controller if you have similar requirements.
I know there is stuff on GithHub which lets you implement a sleek 'pull down to sync' if you are in an UITableView.
However, all I would need to do is to know if the UITableView has been pulled down. I know there is a - (void)scrollViewDidScroll:(UIScrollView *)scrollView function, but that does not appear to fire if I scroll in an UITableView.
All I would need to know is, I suppose, if the UITableView scrolled beyond the upper bonds (which would give a minus figure, I suppose).
I'd be very grateful if anyone has any suggestions / solutions to this problem. Thanks in advance!
You don't say if your UITableView is being managed by a UITableViewController or you are managing it yourself. UITableView will send scrollViewDidScroll: messages, but only to the delegate of the table view instance.
Since you're saying scrollViewDidScroll: is not firing, I assume you are not subclassing UITableViewController and doing something else. Add the method to your table view's delegate and you will be notified of the scroll position changes.
I'd recommend EGORefreshTableHeaderView. Available on GitHub and works great.
do anyone have experience with UITableView inside a custom UITableViewCell ?
I had a try and the UITableView in the UITableViewCell looks like that can't respond to user inputs (i.e scrolling).
Before going any further I would like to know if I am wasting my time !
Does anyone have seen something like that around ? Any reference would be helpful.
Thanks
I haven't done this, but I discourage this. This could cause odd things to happen.
In a similar vein, Apple says not to use UIWebView inside of a UIScrollView. The reason is because a web view is a subclass of the scroll view. Nesting them can cause unexpected behaviors. Note that the table view is also a subclass of the scroll view. While Apple doesn't explicitly mention your case, I assume that it is the same idea.
If yo must, subclass UITableViewCell and see what happens. It's not that difficult. Make the cell implement the UITableViewDelegate protocol.
Since the parent TableView responds to the vertical swipe gesture, your child TableView is not going to ever see it. Where should the swipe gesture "go"? It has to go one place or the other, so one of the TableViews will always not behave "correctly". I do think that trying to put a TableView inside a TableViewCell and getting it to work just like a root TableView is probably a waste of time.