I'm trying to make an app where the user has a "hand" of cards, and they can select one (it does more than that, as just that would be entertaining for about 3 seconds). Currently, the "hand" is represented by a horizontal, paging UIScrollView. Each card is a UIImageView. Things scroll nicely, but where I'm stuck at is trying to bubble up the selected card to the controller. What's the best way to do this?
You can directly use the contentOffset to judge the current page.
int cardIndex = (int)(scrollView.contentOffset.x / scrollView.frame.size.width);
You might've to round it though. You should be able to get the card index using the snippet above. However it doesn't hurt to maintain an instance variable which you would update in the delegate method scrollViewDidScroll:.
Or you can look at UIPageControl too which kinda does something similar but a bit more overhead for your case.
I would go for the extra instance variable or property.
Related
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:.
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.
All I see is a list (which looks like a rolodex), how do I make this like the combo box option?
I haven't tried this, so I can't say that it will 100% work, but ths is what I would attempt to do:
Extend UIPickerView and initially give it only enough height for one row
In the new class, intercept touchesBegan: so that if the control is in the 1 row mode it will first expand to the full height (using an animation of course). I would probably NOT pass touches on to the super class in this mode
If the control is already in the full height mode, let the touch pass on through to the super class.
Add some other communication with other components on the screen so that when the user touches them, the extended UIPickerView shrinks back to it's 1 line height form, with more animation.
To make all of that work you probably need all your controls in a scroll view that does proper auto layout so that as you change the frame size of the UIPickerView thingie the other controls move around appropriately.
I agree with Henrik that this is very non-Apple however. It seems the prescribed Apple implementation would involve a tableview cell with a disclosure button that takes you to another screen containing the picker. I know the Apple HUI guidelines don't cover all cases, but it seems they probably cover this one.
I'm writing a simple iPhone app which lets a user access a series of calculators. It consists of the following:
UITableViewController (RootViewController), with the list of calculators.
UIViewController + UIScrollView (UniversalScroller), which represents an empty scroll view - and has a 'displayedViewController' property.
UIViewController (Calculators 1-9), each of which contains a view with controls that represents a particular calculator. Each calculator takes 3-5 values via UITextFields and UISliders, and has a 'calculate' button. They can potentially be taller than 460px(iPhone screen height).
The idea is:
User taps on a particular menu item in the RootViewController. This loads and inits UniversalScroller, ALSO loads and inits the UIViewcontroller for the particular calculator that was selected, sets the displayedViewController property of UniversalScroller to the newly loaded calculator UIViewcontroller, and pushes the UniversalScroller to the front.
When the UniversalScroller hits its 'viewDidLoad' event, it sets its contentSize to the view frame size of its 'displayedViewController' object. It then adds the displayedViewController's view as a subview to itself, and sets its own title to equal that of the displayedViewController. It now displays the calculator, along with the correct title, in a scrollable form.
Conceptually (and currently; this stuff has all been implemented already), this works great - I can design the calculators how I see fit, as tall as they end up being, and they will automatically be accommodated and displayed in an appropriately configured UIScrollView. However, there is one problem:
The main reason I wanted to display things in a UIScrollView was so that, when the on-screen-keyboard appeared, I could shift the view up to focus on the control that is currently being edited. To do this, I need access to the UniversalScroller object that is holding the current calculator's view. On the beganEditing: event of each control, I intended to use the [UniversalScroller.view scrollRectToVisible: animated:] method to move focus to the correct control. However, I am having trouble accessing the UniversalScroller. I tried assigning a reference to it as a property of each calculator UIViewController, but did't seem to have much luck. I've read about using Delegates but have had trouble working out exactly how they work.
I'm looking for one of three things:
Some explanation of how I can access the methods of a UIScrollView from a UIViewController whose view is contained within it.
or
Confirmation of my suspicions that making users scroll on a data entry form is bad, and I should just abandon scrollviews altogether and move the view up and down to the relevant position when the keyboard appears, then back when it disappears.
or
Some pointers on how I could go about redesigning the calculators (which are basically simple data entry forms using labels, sliders and textfields) to be contained within UITableViewCells (presumably in a UITableView, which I understand is a scrollview deep down) - I read a post on SO saying that that's a more pleasing way to make a data entry form, but I couldn't find any examples of that online. Screenshots would be nice. Anything to make my app more usable and naturally 'iPhone-like', since shuffling labels and textboxes around makes me feel like I am building a winforms app!
I've only recently started with this platform and language, and despite being largely an Apple skeptic I definitely see the beauty in the way that it works. Help me solve this problem and I might fall in love completely.
Dan
If you have the particular calculator view, you should be able to get to the scroll view via the superview property (though there might be more than one intermediate view, so you might need the superview of the superview).
I'm trying to figure out if I can get what I want out of UIScrollView through some trickery or whether I need to roll my own scroll view:
I have a series of items in row that I want to scroll through. One item should always be centered in the view, but other items should be visible to either side. In other words, I want normal scrolling and edge bouncing, but I want the deceleration when the user ends a touch to naturally settle at some specified stop point. (Actually now that I think of it, this behavior is similar to coverflow in this respect.)
I know UIScrollView doesn't do this out of the box, but does anyone have suggestions for how it might be made to do this, or if anyone's spotted any code that accomplishes something similar (I'm loathe to reimplement all the math for deceleration and edge bounce)
Thanks!
There is not a whole lot of trickery to this. Just use an UIScrollView with paging enabled. Make it the size of one of your items, and locate it where you want that item to appear. Next, disable the "Clip Subviews" option on the scroll view (either in IB, or programmatically), and you are all set.