I have a view with a toolbar - each button on the toolbar represents a new message the user is composing. It took me several work days to figure out how to handle the view switching, etc.. but now that I have that all figured out, I have run into a bit of a UI-snafu.
When I have over 11 buttons (I know, a user should really SEND the first 10 before creating an 11th, but I am trying to be thorough) the buttons run off the end of the screen. There is no indicator (aside from the half-button you can see), that there are additional button(s) that can be pressed.
Has anyone run into a situation like this before, and how have you handled it?
My initial thought is when there are more than (lets say) 8 buttons, I programmatically make the first and last buttons "<" and ">" buttons that will slide the buttons down, by removing and adding buttons to my [toolbar items].
Any thoughts?
Instead of creating a new type of UI for the iPhone (which Apple may or may not accept) it would probably be best if you just told the user that he/she has reached the limit and will have to send a message before they can create a new one. Like Safari does when you try to open a 10th webpage.
I think Kane is probably correct, but what you're trying to do sounds a lot like a scrollable tab bar. Three20 offers a class that handles this, or you could implement it yourself. There's no provision for this in the OS (I think the UI guys would probably strongly object if you said you were trying to put 10 buttons down there, let alone MORE than 10.)
Related
Good Afternoon/Evening/Morning Folks,
I recently encountered a discussion with another developer on dismissing a UIPickerView. We work on a legacy enterprise application that had a lot of issues and was written very poorly (among other things). Since then, we revamped and fixed a lot of bugs with this program, strictly adhering to Apple's Human Interface Guidelines as much as possible while keeping to original requirements.
We seem to have a difference in opinion as Human Interface Guidelines do not really go into any detail about picker views. We implemented our new UIPickerView with a "Done," Button to confirm a selected value to be placed in a UITextField. Screen's input would be locked until they selected a value or clicked done.
Legacy application prior to our changes allowed users to utilize a done button but also by way of tapping a value selected in a picker. In addition, legacy application would also show selected UIPickerView value in UITextField prior to selection, wiping out original contents , if any was selected prior to opening a UIPickerView.
So, What is correct way to implement a UIPickerView per common practice or Strict Apple Documentation (if any exists). What is common practice?
Sorry, I cannot post any screen shots or code snippets due to business process reasons. I will do my best to explain if any questions arise.
Thanks,
We can figure this out through apps designed by Apple. Here are two examples
1. Contacts
Find a contact person in the Contacts app and set birthday. The picker shows up. While you are dragging the pickers, it does not set value to the text field. It happens only when you release the wheel. There is no Done button to hide the picker it self. To dismiss it, you can either click on the done button on navigation bar to end editing for the whole page, or click on another text field which pops a different keyboard.
2.Setting - Date&Time
Basically the same as Contacts app. Here you cannot even dismiss the picker.
New to iOS development with a simple technical design question. The project I'm working has walks a user through a set of questions, upwards of 20. I want to use the UINavigationController to give a workflow feel in terms of usability with the back button and Next button in the navigation bar - that is a requirement. However, the design of each of the 20 views will be identical, except of course for the content which will be data driven.
From a design standpoint, would I...
Replicate the View Controller 20 times with 20 separate h and m classes, and use push segue's between each to give a workflow feel.
Replicate the View Controller 20 times but connect to same h and m class.
Redraw the View each time the user clicks Back or Next, thus keeping 1 viewcontroller
I've looked at several samples with xib files, but I'm looking to pull this off with the latest version of xcode and storyboards.
The simplest approach will be to reuse what has already been created. The View (From Modal-View-Controller) part of your application needs to be implemented only once.
All you need is a simple action to allow user to navigate between provide options (20 in this case).
The preferred option in this case will be
3)Redraw the View each time the user clicks Back or Next, thus keeping 1 viewcontroller
All you need is to update the content (equivalent to redraw the view)using proper selectors such as
- (IBAction)navigateToNextOption:(int)index;
- (IBAction)navigateToPreviousOption:(int)index;
You might also like to handle validation based on indices and prompt user to select proper navigation buttons.
A simple case say what if the options are 1000 , might also help you decide the best approach.
Cheers!!
I would suggest that use a single viewcontroller and show the animation behavior like UINavigationController on next and back button click. use this source code a Git
kASlidshow git repositry
how it looks
replace the arrow buttons and place it a top of the UIViewController.
I have an application I'm working on, and I need the user to be able to add new "Shows", "Movements" and "Dots." These are all represented by classes. At the root of the application, all the shows are shown, the user can click on the show, see the movement in that show, then tap on a movement and see the dots in the movement. It works beautifully.
Now, I need the user to be able to add and edit these instances of these classes. The way I am thinking this will work is when the user clicks on the "Add Show" button (Or the "Add Movement", etc) a new view will be pushed onto the Navigation Controller. This works. When the button is pressed, a new instance of the show class is created, and passed to the new view controller. This also works. If the user wants to edit the show, then they will hit the edit button for the row, and the instance of the class (which already exists) will be passed to new view controller, and the user will be able to edit it (It should use the same view controller for adding and editing)
My question is, in the examples I have seen, it is always really dirty to create the editing view. The edit view is a table view with each row having some sort of control. Usually it is a UITextField, but it may be a slider, and it may be one where another view is popped, and the user needs to check one value. (This is similar to the address book application when adding and editing a contact)
Is there any way that is cleaner than just manually going in and creating a bunch of arrays to hold what custom table view cells need to be at what row? This gets very messy, very fast. I can do it this way, I just was wondering if there is a better, possibly faster way.
To my knowledge there's no structural solution to solve this. I'm afraid managing the cells with child UITextField or other controls yourself is the only method. This indeed gets dirty and painful very fast, I certainly feel your pain.
Although it doesn't exist, it would be very convenient if Apple added out of the box editing cells to the SDK, similar to the different normal cell styles. I haven't come across an open source project that addresses this issue, but it might exist.
If you do find a better/cleaner method to handle these situations, be sure to ping back.
as far as i know, editing mode is the only way to make the changes you describe (if i understood correctly). I agree that it doesn't seem like the most elegant approach.
http://developer.apple.com/iphone/library/documentation/UserExperience/Conceptual/TableView_iPhone/ManageInsertDeleteRow/ManageInsertDeleteRow.html#//apple_ref/doc/uid/TP40007451-CH10-SW19
I have struggled and now I just need to see it in action. I have an info-button on my title page (UIViewController) and I want to bring up an About-view with a 'dismiss' button on the left and a 'detail disclosure on the right.' If one presses the 'detail disclosure', it brings up the PrivacyStatement-view with the same buttons. If one presses the 'detail disclosure', it will bring up a Credits-view. I should be able to continue this for additional Legal, etc.
According to the Apple doc's one dismiss will dismiss the entire sequence, regardless of where one is at the time.
I have been able to get the views to show, but they won't dismiss themselves. These leads me to think that I am not using the preferred approach but rather, I have developed an ad-hoc approach that leaves me with dangling structures.
Any suggestions? I have my thoughts, but I am only one two levels deep and the dismiss doesn't work! :( I have a total dead-end and have to Quit the app to get back on the real App view.
I got it! Basically, the code is cascaded along the 'workflow' of viewcontrollers. I devised a style where most of the technical class management is done by the tools and leaves me with book keeping and content. I will need some review for memory management, as I think my current code is probably leaking controllers up and down the path. Also, the fact that I can traverse back and forth leads me to think that I really just have a stack of views and not modal views. I will post the code sometime by the end of the week.
I've gone through most of the example code and I still need some help. I want to make an uber-simple app: show one screen at startup with a label and a button. click the button and we slide over to another screen (I suppose these are called views) which has another label and the "back" button in the top menu bar. I just want to click back and forth between the two screens.
How do I do this?
Take a look at the NavBar sample on Apple's Developer website. http://developer.apple.com/iphone/library/samplecode/NavBar/index.html
You'll need to use a UINavigationController to accomplish the "slide"/"back button" behavior you're talking about. It is as simple as you might think, as long as the app is setup correctly. Essentially, UINavigationControllers allow you to push and pop instances of UIViewController or subclasses thereof, and take care of the animation and view history tracking for you.
The best way to get started, by far, is just open XCode, choose "New Project", and start with the "Navigation-Based Application." Dig around that project for a while and I think you'll start to see clearly what needs to be done.
You can checkout how to get started with that using this tutorial: at wattz.net