How do I create a combobox type control on the iphone? - iphone

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.

Related

Automatically reposition views after UITextview resizes - iOS

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.

iPhone - Make loadView entries fill up parent view?

I have a loadView call that basically places one view at the top (like a header) and one at the bottom (like a footer). It's possible via a passed in parameter to not have a header or a footer, to hide them later, or to resize the view. I have all this working, but it's very susceptible to breaking because the views can go in various places of various sizes and all must be manually set to the correct size or they will not use up all the space. I want one in between the two of them that automatically resizes to fill whatever space is not taken by the others.
loadView doesn't seem to be able to obtain the size of its parent's frame (or where it's being fit in, exactly), nor do I see an obvious way to just put the center view at a certain position and have its width and height automatically adapted.
Any ideas?
If I'm not explaining myself well enough and you know Java Swing, think BorderLayout with a BorderLayout.NORTH, BorderLayout.SOUTH, and BorderLayout.CENTER component.
loadView isn't a good place for this. You really want to use viewWillAppear instead. Setting autoresizeMask to have fixed borders should do what you want without having to worry about calculating layout, and it's best to do this all in IB rather than doing manual layout all the time.

iPhone/Obj-C: Accessing a UIScrollView from a View displayed within it

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).

iPhone: scroll view with arbitrary page/"settling" boundaries?

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.

Nested UIScrollView does not paint

I am building an application which allows the user to view and edit data on a daily basis. To accomplish this i have created a view in Interface builder which contains all of the daily data, and i "tile" this view within an appropriately sized UIScrollView to allow the user to swipe between the days. The view contains two UITextFields, a couple UILabels, and a UITextView. At any given time i have five instances of this view which i re-position around and update the data for the appropriate position.
Everything works great with the exception of the UITextView. The UITextView does not display its Text property until the user has interacted with it (I'm guessing this triggers a redraw).
Is there an easy way to get the UITextView to "paint" its content when its not on screen (but still added as a subview to another view)?
One thing you can try, which is what I just did to fix the same problem, is hook into the parent scrollview's scrollViewDidScroll delegate function. Then in that function, send a message to the UITextView that would force a redraw, my method was setting its frame to the same frame. It's pretty brute force but it's better than nothing.