Fellow stackers,
I am developing the interface for my iPhone application and I'm in doubt about an important paradigm that is present in almost every view I am making. I've read the Apple Human Interface Guidelines but I think that my question isn't answered there.
The problem is, e.g. in the "My Account" view I have to display all the kinds of content the user has created (Comments, Favorites, Notes, etc.). I am currently planning of displaying those as UITableViewCells in the main UITableView of "My Account": there will be a cell for Comments, that pushes the comment controller in the navigation controller, and so on for the other kinds.
One problem arises anyway: I've noticed that many applications use UISegmentedControls to accomplish the same task, and they seem to do so in a non coherent manner. Sometimes they use one method or sometime another. Is there a clear way of choosing one over the other? Or is it just personal preference?
I believe that there are situations where one is likely to be better than the other. As a personal rule of thumb, I avoid cluttering the current view with buttons that link to all the other available sections. I instead prefer an index where I can pick a section and have it load up that, then when I'm done, go back if need be.
So for example if you were using a tabcontroller to navigate between views like the "My Account" view, I would not use a UISegmentedControl. I would use a UITableView. This just allows for you to be more focused on the task at hand.
However, if you belive that your users will be flipping between sections in the account view more frequently, then maybe a semgented control would be the way to go for you.
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.
In my iPhone app, I must have around 9-15 different views, all available from a main menu. I started yesterday with a simple tab bar controllers, but they are only ideal with 6-7 views. Which controller can I use? Is there a nice one for my needs?
Edit: I am talking about around 9-15 menu-points for my application.
Each point is a single, categorizable function. I though about something like the Facebook app, where the app shows 2 menu-pages (slideable) and 9 icons on each page, each with another view / function in it.
look for cocoacontrols.com . i think you will find your need there .....
I think the component you are looking for(the same used in facebook app) is in the three20 library. Its called Launcher. It's like having iphone springboard inside the app. I'd go with that.
Can your views be split into categories? If so, I would suggest using the tab bar tabs as categories, and then using a table view as a menu in each tab.
You could also try using a page control, but 9-15 views seems like they would be obnoxious to navigate with a page control.
I understand that you need to have access to those "views" all the time. You can do what an iphone CNN app does. It uses horizontal scroll, where it has lot's of "views".
This is propably the most challenging part of writing an app for mobile phones. At least i find it not that easy to find the perfect user interface. Espcially if you have so much content and navigation to show.
I think the best way to solve this problem is to write your own navigation. If you want to use something similar like the facebook app - this is not so hard.
Take a UIScrollView in combination with the UIPagingControl. Create a new View for your buttons or whatever you want your user to see and put it in the scroll view. Enable paging for the UIScrollVIew and your almost done. Maybe it's not the easiest way - but in the end it's the most flexible way. You can decide what you want to show and you dont have to be dependent on what some other developer wrote.
Just a thought :)
// Edit: Just read in another question about appLauncher. This might be such a control you are looking for.
https://github.com/rigoneri/myLauncher
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.