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:.
Related
I have a vertical UIScrollView just wide enough for a single column of buttons. The buttons can be dragged by the user, but when one is being moved I want the other buttons to move up or down out of the way. The only way that I can think of to do this is in the UIPanGestureRecognizer responsible for moving the button, every time its method gets called running a for loop in the subviews, checking the y values. That seems incredibly inefficient, and would require keeping track of which buttons have already moved to prevent moving them more than once. There has to be a better way. Any ideas?
the same functionality has been implemented in this project and in this project also . I hope project code will help you to solve your problem.
Your could use a UITableView with a custom UITableViewCell. Just implement canMoveRowAtIndexPath, moveRowAtIndexPath and targetIndexPathForMoveFromRowAtIndexPath on UITableViewDelegate
I Know this question has been asked a lot in a hundred different ways (and thats just on this site). But I'm struggling to put all the pieces together.
I would like each UITableViewCell to look like this:
It has multple legends and several fields. The legends are static and wont change but the corressponding labels will vary in width and height. Therefore so will the cells. I need the legends to always align with their labels.
I have tried to do this using the Interface Builder but don't really understand the autoresizing. Though I'm happy to do this in code.
Does anybody know how to do this or at least have some good links to tutorials, source code etc?
Putting a full table view inside a cell is crazytalk. Maybe somebody got it to actually run - that doesn't mean it's best practice or good practice.
I will answer your question after making one very down to earth suggestion. Please consider following Apple's guidelines by putting just a summary of each event in your cells for this table, and allow the user to push down to another view controller to see the details of a particular event. This will probably help you develop your app faster and get to market, then you can think about advanced stuff like customizing individual cell heights at runtime.
That being said, if you insist on putting all your eggs in this basket, then I think you will need to implement your table view cell in IB, note the details for all of your content label frame dimensions, then, at run time, use one of NSString's sizeWithFont:constrainedToSize: methods to determine how big your labels will be. Make them that big. Then from that data compute the height of your cell, and return that value from your table view's tableView:heightForRowAtIndexPath:. This is how I implemented this functionality in an app a few years back. (Frankly I'm not sure that it's still working.) There may be some better methods for figuring out the label size in CoreText, I haven't looked.
A better bet will be to constrain yourself to a limit on the length of text you can put in each label. Then you can just define the labels statically and use a constant-sized cell. Putting it together in IB isn't tough. Just lay everything out, and make sure that you create an IBOutlet and XCode/IB connection for each object you want to manipulate in code.
Good luck!
Add a tableview to each UITableViewCell. The outer tableView will be responsible for holding all your cells and each cell will be a Event with cells for each parameter.
This tutorial will give you insight on how to set that up.
http://iosstuff.wordpress.com/2011/06/29/adding-a-uitableview-inside-a-uitableviewcell/
I have an iPhone application which is, in essence, a list. There is a UINavigationBar at the top, and then there is a UITableView which holds the list. I'd like to have an option in some way or another of allowing the user to sort the list in different ways. So, in my mind, I picture having a NavigationItem on the UINavigationBar that, when touched, a little pop up dialogue comes up. You select the "sort" you want, a check mark appears next to it, and the dialogue goes away.
I'm not really sure how to do this. I tried creating a UIView, adding a UIViewController onto it (which held this list of different "sort" parameters (ex. sort alphabetically, sort by date, etc) in a UITableView. But the UITableView isn't responding to any touches, and I'm not sure why.
Does anyone have an idea for using Apples wonderful interface for having an option like this? I can't use a UISegmentedControl below the UINavigationBar, because there are 5 possible options, and I can't fit all that in a single UISegmentedControl.
This sounds like a job for the UIPickerView. You could just slide one up from the bottom of the view whenever that button is pressed. I've done this in the past and it works well.
You won't get a checkmark, but if you want a pop-up I suggest using a UIAlertView.
Have you looked into UIActionSheet at all? https://developer.apple.com/documentation/uikit/uiactionsheet
It seems like it might be a good fit for this approach. The action sheet will be a bit tall since you will have 5-6 buttons in it, but it should get the job done and they are really easy to implement.
The way you are approaching it with displaying another view with its own UITableView in it would work also, but it doesn't seem like the best approach to me. Granted, if you are set on going with that approach, provide us with some code so we can try to figure out why the UITableView isn't responding to touches.
So I have a UITableViewController. The cells in this tableview have the following UIControls:
2 UILabels, one of which has a shadow and a clearColor background color.
1 Custom Progress view resized to be larger and with a different color
3 UIButtons
Functionally, they do exactly what they are supposed to do. However, I've noticed when looking at it on device that scrolling performance quickly tanks and has dropped frames all over the place, even with other interactions like pushing one of the buttons.
So I was reading around today and found http://blog.atebits.com/2008/12/fast-scrolling-in-tweetie-with-uitableview/ this article by the Tweetie guy about how to achieve fast scrolling performance by subclassing UITableViewCell and doing the drawing yourself.
The example works extremely well, but when I tried to adapt it to work with my desired configuration I realized that he isn't using any predefined UI Controls, he's mapping out everything by hand.
While I can see how this would be an extremely efficient way to do things, it strikes me as problematic for things like the progress view and the buttons, and even one of my labels to a certain extent.
So my question is this: Do I need to completely write my controls from scratch if I want my scrolling performance to be good, or is there a way to use the standard UI Controls and get good scrolling performance?
If you're adding custom controls to your cell, you should still be subclassing UITableViewCell, adding your controls in the init function, laying them out in layoutSubviews, etc. - just like any other view. As VdesmedT says, make sure you're re-using cells via the dequeue mechanism, so that you aren't allocating new cells with each scrolling operation.
OK, I will propose something obvious but to achieve UIScrollView performance, you need to be sure that the dequeue mechanism works well. I often see developers not properly set the identifier in IB and therefore missing the UITableViewCell cache benefit
I'm trying to avoid putting a button in my UITableViewCell subclass so that I don't unnecessarily lag up the scrolling speed.
The button would push another view onto the navigation stack.
I figured since UITableView already has built-in and optimized methods for managing this, that simply limiting the touchable area of my cells would be the easiest and most effective way of achieving my goal.
I really have no idea how I would implement something like this. I have a feeling I would have to override pointInside:withEvent: or hitTest:withEvent:, but I'm not sure how. Managing touchEvents and the UIResponder stuff still escapes me.
So my question is ultimately, in my rootViewController, how would I implement that selecting a row will only work at lets say 220,10,40,40 ?
Thanks!
A UITableViewCell should have a normal selection style(i.e. not UITableViewCellSelectionStyleNone), generally speaking. You shouldn't have buttons on cells that you are reusing an arbitrary number of times.
If you're using a lot of UIButtons in your UITableView, you may want to rethink how your UI is designed.
You can't easily (to my knowledge) change "selectable" parts of a cell - the whole cell must be selectable no matter what(you can set the style to no selection, but you'll still recieve touch updates).
The behavior you're describing sounds like a job for UITableViewCellAccessoryDetailDisclosureButton, actually. If you're going to be pushing another view onto the stack but don't want to do that when the user selects the cell proper, use a detail disclosure button to maximize your consistency with existing UI convention. It's hard to say without more information.
As for doing the work necessary to detect touches in a sub-region, that may be more trouble than it's worth. True, adding subviews to a cell incurs a compositing cost but if you're only talking about one button, and a button whose background you can set to opaque, you'll probably be just fine. The alternative is reinventing the wheel to recreate button behavior in a subregion of the cell and that doesn't sound like functionality that will be much fun to maintain as the SDK matures.
That said, adding views to a cell doesn't incur a compositing cost per se, it's drawing those views that's the trouble. So if you really wanted to go nuts on the optimization, you could create a pre-rendered cell background image that includes the appearance of a button you want and then place a custom, image-free, see-through UIButton instance right over top of it. Nothing to draw, so no additional compositing cost. Worth a shot.
You didn't come here for a premature optimization speech, so I won't bother with one, but I say just do the cell with a normal button for now, make sure you like how the functionality feels to use then optimize toward the end if you're looking at performance that you're not happy with.