I am new to Obj-C so I will be happy for any best practice idea or something.
I have a table view with some objects. When any object is selected I would like to open an object detail view with tabs. These tabs divide the object properties to some logical groups.
But it still describe one object and I would like the user has an experience when creating the new object he can switch between tabs and change the values without any saving data until the save button (common for all tabs in navigation bar) was clicked.
Thanks for any help.
Not quite sure what you are asking for. I think you can use UINavigationController to lead the user to the detail screen, in the detail screen use UITableView to display your object detail. If you want to group them, you can set the tableView style to Grouped.
If you are asking for something else, please provide more details.
To be idiomatic with the iOS experience, displaying the Tab Bar should be a modal dialog with a "Done" button then.
Create a UINavigationController and place the UITTabBarController as the root controller of it, then in the navigation bar of the root controller place 'Done' button.
Note that you must keep a temporary model of whatever you are editing in memory (I would suggest subclassing UINavigationController, adding a property for the object and passing a pointer to the object to all of the tab controllers), since the views containing the changed data can be deallocated at any time when they are not displayed to save memory.
Related
Hy everybody
I am a newbie ios programmer and I'm facing many doubts when I must switch the pages of my app.
With the term "page" I mean a UIView that fills the whole screen with some widgets (buttons, textboxes. tables..)
As far as I have understood what I've read I should use an UIViewController to manage each of these pages
since each page should be a screen’s worth of content.
My App starts with a ViewScroller with many buttons and when the user clicks one of these it opens a new page.
The first page is the UIView connected to the RootController Of the Window.
So far to open the new pages I add a child controller to the RootController and it's view as a child of the view of the RootController:
RicLocaliController = [[RicercaLocaliViewController alloc] initWithNibName:#"RicercaLocaliViewController" bundle:nil];
[self addChildViewController:RicLocaliController];
[RicLocaliController didMoveToParentViewController:self];
[self.view addSubview:RicLocaliController.view];
RicLocaliController.view.frame = self.view.bounds;
When the user clicks the "Back" Button I remove the child controller and the child view.
Going down this road I would get a dynamic tree of Controllers with their Views.
So far I have not encountered problems and my app can go up to a third level in the tree and come back. Each page behaves correctly when orientation changes.
But I'm afraid that adding, for each subpage, a child controller and a child view could be not the right thing to do.
I'm afraid that if I nest a lot of pages when the orientation changes the app could respond slowly since also the superviews will do something to manage this event.
So what I wonder is if what I am doing is completely senseless, if I should use Navigation controllers or some other way to manage my page changes.
Unfortunately my boss is not giving me enough time to study well the subject and so I would like an advice to follow the best solution possibly using the most standard and less complex component offered by the framework instead of the newest features.
I read a lot of web pages on the subject but it seems to me that there are many ways to manage the navigation beetwen pages and this makes me confused.
I apologize for my bad english but i'm tired and English it's not my first language.
You HAVE to do some studying. You will spend more time clearing up all your problems later otherwise... but, here are some tips.
Using nested ViewControllers leads to all kinds of trouble so if you are short of time, skip that.
Think of each "Page" as one ViewController. A ViewController has a property called View but that is actually just the top view of a whole hierarchy of views. A view is the base class for any visual object, like labels, buttons etc. All views can have subviews, so you can add an image under a label etc. and do really wierd stuff if you want to. I am just saying this to free your mind about how you can use views.
Now, ViewControllers are supposed to hold to code to ONE view hierarchy. That view hierarchy is for that View Controller only.
When the user wants to navigate to another page, you have a few alternatives:
NavigationViewController - that should be used when the user wants to delve down into data, like opening a detailed view of an item in a list etc. The NavigationViewController gives you help with back buttons, proper animation etc. You "pop" a viewcontroller to go back one level. If the user click the back-button, this is automatic.
TabBarViewController - use that if you want a tab bar at the bottom of the screen. Each tab is connected to a ViewController, that has it's own view hierarchy.
PushModal - If you are in a ViewController and just needs to get some data from the user, which is not part of the normal navigation of the app, you can push a new ViewController modally. This is the way you interact with iOS built in ViewControllers. This is also a good way to get a value back from the view controller.
There you have it. Go learn more. :)
It sounds like, for what you are using, you should be using a navigation controller. This will automatically handle pushing views onto the stack and then popping them off again later. This will also automatically create a back button (it is customizable) in the navigation bar.
If you are using iOS 5 or 6, I highly recommend trying out "storyboards" in Interface Builder. Storyboards allow you to graphically represent transitions (called "segues") between different views.
On top of being easier to design and implement, another advantage is that, if in the future you want to change the design of your application, you don't have to trawl through all your code and manually update each view connection.
Sorry for the vague title!
I am trying to achieve the following functionality: A user is first presented with a UINavigationController containing a UITableView. When the user taps a cell in the table view, I want to push a new view which contains a UITabBarController (that'll stay visible regardless of the currently visible UIViewController) and a UITableView again, that people can again select a cell from and which will then again push to UINavigationController.
If a user selects a tab from the UITabBar, I want the first screen (without the UITabBar) to be the one that users can go back to, not the tab they just came from. Also, if a user selects one of the UITableView items on any of the tabs, I want the back button to go back to the previously displayed screen (as you'd expect with a standard UINavigationController)
I've spent hours trying to find the answer to this and I just can't anywhere! I hope I haven't been too vague or confusing in my explanation.
James.
If your desired UX is confusing to explain here, imagine how your users will feel! I would reconsider the intended design.
From the View Controller Programming Guide:
An application that uses a tab bar controller can also use navigation
controllers in one or more tabs. When combining these two types of
view controller in the same user interface, the tab bar controller
always acts as the wrapper for the navigation controllers. You never
want to push a tab bar controller onto the navigation stack of a
navigation controller. Doing so creates an unusual situation whereby
the tab bar appears only while a specific view controller is at the
top of the navigation stack. Tab bars are designed to be persistent,
and so this transient approach can be confusing to users.
That said, you can probably hack something close to what you are talking about but you'll need to write a bunch of code to handle the navigation using the UITabBarControllerDelegate and UINavigationControllerDelegate methods and keep track of whatever state you need to know where you want to navigate to based on a user action. Odds are you'll end up with something complicated to code, maintain, and worse, use.
I have a navigation controller which I push a new tableviewcontroller for each received question to be asked to the user, so in stack it builds up to 30 controllers if there has been 30 question is asked.
The difficulty is that in some of the tableviewcontrollers I want to get the input from user by using another navigation controller inside that tableview: for example in the tableview(which is one the many views in the stack) there may be uitablecell with an arrow on the right saying choose the books you want to order, and when he clicks arrow a new tableview will slide in which includes the books to be choosen multiply with a checkmark, and then he will choose and back to main tableview and continue the main navigation there.
How can implement a new navcontroller inside the main navigation controller? or any better ideas?
EDIT: That can be an idea to push the detail view to the same controller, but then they will get popped immdidatly when user "backs" but I want to show the books (which are chosen in detail view) the main table, and when user clicks again to that cell, detailview will come with previous selected books. is this a good approach
Putting an UINavigationController inside a UINavigationController is a bad idea. What you seem to really want is persistence of state data after popping some of the view controllers off your navigation controller's stack.
I would put that state information into a persistent object. If it's a tiny amount of state data I may add that data to an existing object that I know is persistent, such as the app delegate or the root view controller. I would save a more complicated set of persistent data to a custom object. This object would be retained by the root view controller, and a reference would be given to each successive view controller. This object would have the data that may have been collected by a controller that was popped off the navigation stack and therefore no longer exists.
I don't really get why you dont just push the detailview of the uitableviewcontrollers to the main UINavigationController..
Could you explain that a little bit more detailed?
I have no rights to comment your question, so I am afraid I have to post this as an answer.
MfG,
SideSwipe
I have a table view that contains a list of Project objects. When an item is selected it brings up a detail view. Pretty standard. What is the best way to implement "add" functionality (popup a modal view controller to input new values and save the item)?
Currently I have view controllers for my root view, detail view, and add view. Essentially the detail view and add view are exactly the same except for a save & cancel button in the add view. Is it possible to reuse the detail view in the add view?
Finally, what is the best way to display the list of project properties in a grouped table view separated into sections?
Thank you for your responses.
Most likely, you are already passing your detail view controller a managed object that it is supposed to display when in detail view mode. When the user decides to add a new project, just create a blank object, pass it to the detail controller and display it. (You might want to insert this blank object into another "empty" managed object context in case the user cancels the add process to avoid having to clean up your main managed object context in that case.)
The detail view controller would also need a flag that tells it whether it is in edit or add mode so it can adjust its controls (and possibly delegate messages it sends to its owner) accordingly. You would set the flag to the appropriate value before you display the controller.
It sounds like you're looking for a UINavigationController. The UINavigationController lets you push new view controllers on top of existing ones. It gives you a navigation bar at the top that will allow the user to go back to the root controller. I think it's the kind of controller Apple uses it in the default email application, to give you an example.
Concerning organization: you design your root view controller and a detail/add view controller. In your app delegate, you attach a UINavigationController to the window and you set its root controller to the main controller you want to display. That root controller can then push the add/detail controller onto the stack (and when it does so, it can tell the add/detail controller which types of button to display.)
I can't answer your grouped properties question, but it sounds like a separate question anyway.
I have a navigation app that has many screens the user navigates to. A handful of views manages these screens dynamically. What I want to try to do is add a button that will always show up on every screen the user views. I need to do this so that the user is always able to preform the action associated with the button regardless of where they are in the app.
Is it possible to achieve this by adding this button only once and having it passed between views like my navigation bar is? Or do I just have to man up and add this button and its functionality to every single view file I have?
Thanks
I would say it probably depends on what the button does. If the button is generic to all views, meaning it affects all views the same exact way so no customization for a given view is needed, then a way to do this would be to include the function in the App Delegate or as a subclass to your Navigation controller.
You can then use the rightBarButtonItem to always show the same button and just access that method. You would just have to add code for the rightBarButtonItem in each viewDidLoad (but they'd all be the same).
I did something similar to this with an "Upgrade" button on one project. Since all the button does is launch the AppStore to the paid version, it's independent of all views and I can place it anywhere.
You can put the button on the navigation bar if you want. Alternately, the more generic way to do this would be to split your single view into two views. One is small and only contains your button but always stays on the screen. The second is your workspace and you swap in and out the views that are displaying the current content. You'll note that this is the way the navigation controls and tab-bar controls work.
The last way to do this would be to put different buttons, in the same place, on each view and have them all trigger the same action. As far as the user is concerned this looks like the same button. Disadvantage here is that you can't alter the button across all views in a simple manner.