I'm trying to make a custom table view. I have a UIScrollView loaded up with UIViews. I would like to recreate the reusable cell functionality that a tableview has. And I'm wondering what might be a good way to do this.
I was thinking that when the UIViews are scrolled off screen I'll remove them from the Subview, and when I need another I'll just add it. However I'm not sure what method might be the best to do this in.
I could check to see the views location in scrollViewDidScroll: but I'm not sure if this would be the best thing to check over and over again. If anyone has any suggestions or helpful tips that would be really awesome.
Thanks!
One reason why scrollViewDidScroll is less than ideal choice is that your scroll view subclass will then need to be its own delegate. That will deny the users of that class the chance to be the delegate (easily, at least).
The better place to check this is in overriding layoutSubviews. And yes, like scrollViewDidScroll, it gets called a lot! But if you think about it, the only way to detect with certainty if any subview has been scrolled off, is to check when any scrolling occurs.
So the key is to be as efficient as you can checking. The first thing I'd try is fast enumeration of the subviews, asking if each frame transformed by contentOffset falls within the parent's bounds (using CGRectIntersectsRect). If not, add it to your reuse pool and remove it from superview.
Subclass UIScrollView and override setContentOffset. That's where the scrollViewDidScroll message comes from in the original UITableView, and that's where you can implement your own logic.
Edit: you might want to study the source code for PSTCollectionView, which is not a custom UITableView but a custom UICollectionView.
Related
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 do understand how to go about making the UIKeyboard push up the UIView if the active UITextView is blocked by the UIKeyboard as per this question: How to make a UITextField move up when keyboard is present?.
What I'm wondering is, from a design perspective, how do you go about implementing the keyboardDidShow and keyboardDidHide methods so that all of the views in your app, whether they be a UIView, UITableView, or UIScrollView all have this functionality and so you need to implement these methods only once?
The only way I could think of would be to have the view property of the UIViewController always set to a UIView, and if you have a UIViewController that needs a UIScrollView or UITableView, just attach it as a subview to this. Then if the UITextView is being blocked, just move the parent UIView up so it will move all of the views that are attached to it.
Does this sound like a good plan, or is it even worth it? Anyone else have any other ideas?
This is a little old, but it's a great article about using firstResponder methods to tell views to slide up. I, personally, like to put my UITextField in a parent container and move it all up. However, I do NOT suggest putting everything in there and moving it all up, because the UITextField "feels" better just above the keyboard. But I do like the background or certain items to move up with the UITextField.
See below: http://cocoawithlove.com/2008/10/sliding-uitextfields-around-to-avoid.html
This is a nice implementation that moves the field up based on the section of the screen it's in (upper, middle, lower). Works very well. May need to be updated for newest SDK, but should be pretty easy.
In experimenting with this, I noticed that if you want to make a BaseViewController that implements this functionality to work for everything that inherits from it, you have to attach another view on top of the UIViewController's view property in order to get it to work. Reason is, if you push the UIViewController's view property up when the keyboard appears, then it resets itself if the app comes back from being active and it's messy.
The problem with this however, is now in all of your child classes you have to attach your subviews to this new view property instead of the regular view property. Also, you probably have to make a custom UITableViewController which will inherit from your BaseViewController class so it can inherit the keyboard notification methods.
Ultimately, I've found it's not the worst idea to have another view on top of the UIViewController's property for a bunch of different scenarios. Making a custom UITableViewController isn't that big of a deal either. So if you have a lot of text fields in your app, this might not be the worst way to go.
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.
I've decided that I don't want to ever use UIPickerView again... it's completely inflexible in terms of functionality, design, and size (height). It also occasionally gets stuck between rows, and the delay that occurs between letting go of a wheel and when the delegate method is fired indicating that a new row has been selected (because of the "settling in" animation) has caused lots of problems in the context of the apps I've been working on.
That being said, the user-friendly aspects of UIPickerView are good, and I'd like to try to replicate it. I've tried to research different ways that this might be done, but without much success. Does anyone have any ideas as to what would be involved to make something similar from scratch?
I was trying to get a UITableView subclass to behave in such a way that whatever cell was currently in the middle of the table (it would change while dragging, etc.) would change its background colour to something different implying that it was "selected". As soon as the table was dragged such that the "selected" cell was no longer in the middle, the cell would go back to normal and the new middle cell would change colour. So this would be like UIPickerView in a sense that you don't have to tap on a cell; instead you just drag to have one selected by default.
I figured it should have been easy enough to intercept the "touchesMoved" method of UITableView and add some code that looped through all currently viewable cells in the table, checking to see if their frames overlapped the center point of the table, and changing their appearance accordingly (plus sending a notification to other classes as needed to indicate the "selection" change). Unfortunately, I can't get this to work, as the "touchesMoved" method doesn't get called when I drag the table. Am I missing something obvious?
Any ideas or suggestions would be very much appreciated at this point... I made an app that relied heavily on UIPickerView objects, and because of the problems I've run into with them, I'll have to abandon it unless I can figure out a way to make this work.
Thanks very much,
Chris
Remember that a UITableView is a subclass of a UIScrollView, and the UITableViewDelegate gets all the UIScrollViewDelegate method calls too. scrollViewDidScroll: sounds like it would easily fit the bill for knowing when the table view was scrolled.
As for finding which row is in the middle of the view, just use indexPathForRowAtPoint:.
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.