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
Related
I'm having a hard time understanding what approach I should take. I have a TableView controller with a list of questions, if you click a row it pushes a new QuestionViewVontroller that displays the question, answers, and next button (or done button). When a user clicks next I want to load the next question (from the tableview list) but I still want the navigation to work (back button will take you to TableView).
I'm starting to think I should keep the same QuestionViewController and just load in the question data. Is this right? Or should I use a modal view?
You have a couple of options here.
Use the same QuestionViewController and just repopulate it, like you mentioned.
Push a new QuestionViewController and use custom back button that either pops to the root view controller or pops to a given view controller.
The code for both options in #2 is below, where "self" is the current view controller (your question controller).
[self.navigationController popToRootViewControllerAnimated:YES]; //this would pop to your UITableViewController, assuming it was the root
[self.navigationController popToViewController:yourTableViewControllerHere Animated:YES]; //this would work as long as you passed a reference to your UITableViewController to your question controllers
It's up to you how you choose to solve your issue. However, if you decide to use the same QuestionViewController, include a catchy animation when importing the new question so the user knows what is happening and to make your app that much cooler :)
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 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.
The root question is "how many UIViewControllers can you push on the navigation stack?" without causing memory warnings or earning a watchdog termination.
Suppose I have an application that is basically a database for three entities where each can have a relationship with some other entity, and the relationship is shown on a UIViewController. Users can follow those relationships and each one brings up a new controller - If the entities are A, B and C and A->B->C->B->C->A then each kind of view is on the stack twice. I understand how to push and pop, how to push back to a particular controller, and I think rather than just extend the navigation stack indefinitely it might be best to reuse a view controller in the navigation stack.
To do this, every time I wanted a FirstEntityViewController I could scan the navigation stack to find an object where [self isKindOfClass:[FirstEntityViewController class]]; and then call methods designed to rejig that view for what I currently want to see - just refreshing the data in the same way you do when reusing a UITableViewCell.
This is fine except for the effect it might have on the NavigationController. If I use UINavigationController:popToViewController:animated: I think it is going to discard everything above the view I'm popping to, including the view which the user expects to find on tapping "Back" in the navigation bar. So user taps a relationship, taps back and goes "huh?"
If I remove the matching controller from the navigation stack and then pop it on to the top of the stack the back behavior remains OK as long as the user doesn't go back as far as the instance of FirstEntityViewController that was moved or else again navigation will seem inconsistent.
Is the right solution to remove the controller from the stack, and somehow hold a place in the stack so that when the reused controller is popped it can be replaced back where it came from? Should I maintain my own list of view kind and data display so that when popping I can replace the view below the view about to pop to, staying one step ahead of back navigation?
Or is that just getting too complicated? Is there no need to even worry about this situation because the OS reuses much of the view controllers in the same way as UITableViewCells are reused, and there is no real memory or performance impact in having a 50-deep navigation stack?
ViewController instances remain in the UINavigationController's stack, but any view except for the top view may be unloaded at any time (the view controller is notified via the viewDidUnload message).
In other words, the views underneath the top view do not hang around and will eventually be unloaded in low-memory conditions, so there's no need for you to attempt to re-use your view controllers.
Last I checked you can't push a viewcontroller that's already on a navcontroller stack back onto it again. You'll have to create a fresh viewcontroller and push it onto the stack and each back button will pop that one off the stack. The best you can do is make a cache of viewcontrollers and dole them out as-needed -- as long as they're popped off the navcontroller stack. But it probably won't buy you much by way of memory savings.
UITableViews are a bit different in that there's only a relatively small number of cells in view at any given time and as soon as the cell goes offscreen it's removed and returned back into the pool. If you can guarantee that the maxdepth of your chain is fixed, then you can pull a similar windowing scheme. If not, you may have to stick with going deep and be vigilant about releasing memory as soon as you can.
In my iPhone application, a user selects an item from a UITableView to choose a resource to view. The UIViewController subclass required to handle the resource is not known until the resource is retrieved, which may take a few seconds.
In response to the selection action, I push a "loading" view controller on the nav stack. That controller presents a view with a UIActivityIndicatorView along with (possibly) other status information, and initiates the download of the selected resource. From this view, the user might cancel the download, in which case I would return to the list of resources. If the resource arrives, though, an appropriate new view controller is created corresponding to its type.
Here's where it gets sticky. If I push the new type-specific view on the nav stack, the "loading" view is still in the stack; obviously once the loading is complete, there's no need to "go back" to that view. I've tried simply adding the type-specific view as a subview of the "loading" view, but that doesn't get my type-specific controller onto the nav stack, so it doesn't have a [self navigationController] for further navigation.
How can I "replace" the current view on the nav stack with a new one? Or, more generally, how can I show activity / progress when I don't yet know what controller will be used to display the resource being retrieved?
I've found pretty cool "HUD" progress indicator classes, but I don't want the progress indication to appear on top of the list of items being selected from. Instead, I want the user to perceive that they have "gone" to a new space that is waiting to be filled in.
I'm pretty new at this stuff, so I hope I've at least worded the question coherently. Thanks for any help anyone can provide.
Update: Actually, it would probably be better to display your "loading" view as a modal view. Check out this question for a few examples.
You should pop the "loading" view controller and push the "specific" view controller once the latter has been downloaded and allocated. Play around with NOT animating one or both of those actions to see what gives the best experience.