I have a doubt about the behavior of setRoot and push. If I'm not wrong, I got the same result with these methods. The method push will push a page into a stack and setRoot method will change the root page.
When should I use one or the other?? Is there any difference in performance or good practices?
If the view you want to switch to is a child of the current view, or if you want the ability to navigate back to the previous view from the new view, you should push and if the view you are switching to is not a child of the current view, or it is a different section of the application, then you should instead change the root page.
Related
I have a query regarding push notification.
Whenever a push comes and user is working on some XYZ controller and push requires another controller to be initialized and shown. Now should I show the push controller on top of the current active controller and take the user back to the currently working controller, once done?
What if the push controller has some actions involved and is a complete set of functionality associated with it. Should we restrict actions when a push comes.
What is the best deal?
It depends heavily on the flow and organization of your application. In a tab bar based application, you should have a tab for handling the notification activity, and place a badgeValue for the corresponding UITabBarItem. You could also show an alert offering the possibility of switching to the "handle notification" area on the other tab. Tab Bars are a good way of having "simultaneous" access to differing flows and switching back and forth between them without having to manage saving and restoring the VC flow yourself.
Here is the situation, I have a login page as the initial rootView of a tab bar. Once the login process is done, the view is removed from the navigation controller, so you don't navigate back to it. I have places in the app where you can logout. The logout process works fine, but when I try to forward the user back to the initial login view (the one we removed) from inside the same tab bar item, I can't seem to reset the view controller stack to contain only the desired element. Is this a question of where I am changing the view? It just doesn't seem to remove the current view. I have tried alot of stuff, popto, popview, and many others, and nothing seems to work properly. Has anyone had to deal with this?
Take a look at the View Controller Programming Guide and the various way to alter the navigation stack (push, pop, set, etc).
Look into making your login view controller into a modal view controller, which pops up when credentials need to be entered.
A modal view controller is perfect for view controllers that you don't need to keep around, but which can be needed at different points in your application usage "flow".
Laurent's link will explain to you what the different options are for a navigation stack, and Apple's document suggests contexts in which those different view controller types are useful. I highly recommend reading it.
I am new to iphone development. I have to develop an iphone application which is basically a questionare. When user runs the application he has to answer around 30 questions, each one at a time. I am planning to use the Navigation template project for this application. Where i can create a view with question and optional answers (in table view) and when user selects an answer, i can push new instance of same view to navigational controller.
Is the the best practice for creating a questionare application. Or a better template exists? Is it advisable to store 30 instances of a view in view controller stack?
regards
sandy
The navigation template is fine. However, I would do it in a slightly different way, mimicking a wizard.
Your initial root view controller should present the first question, when the user selects it, you push on the stack a new view controller in charge of handling the answer. When the user answer the question, you pop the view controller notifying your root view controller. You may do this using a protocol and a delegate or using a notification. Upon receiving the notification, or when the delegate method is called, the root view controller prepares the next question.
Repeat this cycle until the user answer the last question, then your root view controller presents to the user the final result.
could anyone help me with the next question. I am working on an app with the navigation similar to Notes app has. The problem I faced i how to implement navigation within one level and keep root view as the previous screen. So the scenario I need to achieve:
1. Drill down from the top level list to the detailed view.
2. From this detailed view navigate to the detailed view of the next/previous item.
3. Back button should lead to the root view.
I've tried several approaches and no-one worked fine for me. The most right solution from my point of view is to create a middle controller between the root and detailed controllers to handle this next/prev redirects. But the main problem here is that switching from one detailed view to another the navigation pane stays the same, so it's not involved in the animation, whether Notes app work right in this case.
Could you point me how it' better to arrange controllers interaction in this case?
Thanks in advance. Sorry for quite big post, was trying to be as informative as possible.
Best regards,
Roman
I think the best implementation is this way:
Say you have a Note class where the data is stored.
You could have two view controllers, one with the list of notes and one with the details.
Both of these can be added to a navigation controller.
Then, when you want to switch to the next note, you retrieve that object somehow and assign it to your detail controller with a -setNote: call. That method will be responsible for changing what the outlets are displaying.
I've resolved this question - it's enough to pop current view and push new one, created for the next object in the list. The only think to remember is to save the reference to the navigation controller before the pop call, because after it self.navigationController becomes nil.
Yeah, it's misbehaving badly. Jongsma's reply is the best. In case you wanted to re-create controllers, I've found this to work:
[parent performSelectorOnMainThread:#selector(showMyItem:)
withObject:myNextItem
waitUntilDone:NO];
[self.navigationController popViewControllerAnimated:NO];
performSelectorOnMainThread delays execution of the method until the next run of the main loop, and by then the previous controller is removed already and navigation controller is in a stable state.
Suppose that I want to create and application and that application will have two windows and a menu mechanism. How do I accomplish this on iPhone? I know how to create a single view and have that displayed but what I want is this ability:
a.) Upon loading app, show a navigation mechanism. The choices are Item A or Item B.
b.) If Item A is chosen, view A should be loaded.
c.) It Item B is chosen, view B should be loaded.
Thanks in advance.
To me, what you're describing sounds like three views.
1. Root View
This view has two buttons (or other controls) that allow the user to select where they would like to go.
2. View A
A view with the necessary controls and data.
3. View B
A view with the necessary controls and data.
The actual transition between the views could involve a UINavigationController. If so, the root view would be pushed onto the UINavigationController's stack initially, and clicking the buttons would push either view A or B onto the stack. Otherwise, views A and B could be presented modally when the appropriate button is clicked by calling [rootView.presentModalViewController:animated].
Is that what you're looking for?
Since you mention a "menu", is it possible the user may like to go back and change their selection (A or B) at some stage?
In that case you may like to also investigate if a Tab Bar Controller based application fits your needs (similiar to the built in Clock application)
This would always display two buttons at the bottom of the screen which the user could use at any point in time to switch between the two modes. it would automatically handle the switching of views "A" and "B" within the main part of the screen.
The real answer probably depends upon what your two views need to do, and what kind of UI they present.