what is difference between view based and navigation based system in iphone . which one better to use and when?
if you have hierarchy of views, use navigation based else use view controller based.
You're talking about default templates that Xcode offers you to start your project with. It's not like they're different "systems" per se, they're just different starting points.
A view template is good if your app is one screen, or maybe a couple screens. Movement between those screens is up to you (and there are some pretty easy and good tools for animation screen changes, but you have to hook into those yourself).
A navigation template is good if you're going to be navigating a hierarchy of data, possibly with lists, sublists, detail screens, etc. Shifting between views is done with a call to UINavigationController, that handles all the transitioning business for you.
navigation based system is used if you want to use something like moving from main view to its inner view
like parent to child then subchild and so on...
While if you have no such hierarchy then you can use view based..
Navigation Based gives you a flexibility to reverse back to the view controller which you have already visited. like say for example you move 1->2->3->4->5 now if you want to go to 2 you can go easily. Navigation adds a top bar while view based is used if you dont want any kind of hierarchy..
hAPPY cODING...
Related
I have used a fairly common design pattern for a standard IOS slide out navigation. I based the design off of the example found here: http://www.raywenderlich.com/32054/how-to-create-a-slide-out-navigation-like-facebook-and-path. The basic design takes four view controllers, a center view controller, a left view controller, a right view controller and a main container view controller to hold and manage the three other views. The main container places the center controller on top and when the user slides his or thumb left or right, the view slides over to display the appropriate controller beneath. I recently adapted this to a project that has almost thirty different controllers. I have it working with the initial view but am wondering what is the best way to scale this feature? I want this slide-out navigation to be available on every single page so the user can just slide and navigate to anywhere at all times. The right and left view controllers will always be the same no matter what controller your on, is there a way to have a common main container that dynamically loads the center controller depending on the view the user is on? Or do I need to go and implement a container controller for every single controller I want to have the slide-out navigation functionality? Obviously I would think the first method would be the most efficient and scalable, but I have no idea how I could do that or if it is even possible.
An easy way to have a side slide out navigation is to intergrate opensource code into your project. The code normally comes with directions on how to implement it and a demo app.
Here is an example of an opensource slide nav like facebooks
mfsidemenu
The website this link takes you to (www.cocoacontrols.com) has some great opensource iOS controls as well!
I am making an app that has both a bottom bar and a top bar (both are customized) and i want them to stay there the entire length of the app while the middle portion switches between views. But the kicker is at some points in the app, i want to have the top bar and bottom bar slide off the screen and be able to be dragged back on.
What i was thinking was to have one main UIViewController with three UIViews (top bar, middle section, and bottom bar) each running code from their own respective files. Sort of like how a Tab bar works with a nav controller. or do i have that backwards? i dont really know... but any constructive advice helps =)
Im fairly new to xcode and i've been trying to find a way for a few days now, so please dont be too harsh on me. Thanks!
In general, we build one view controller for each 'screenful' of content. So the basic advice for you would be to make the app in a way where each 'section' is it's own view controller. This is especially important to the MVC paradigm, where your business logic should be in the viewControllers, not the views (just display and interaction logic there). If you had just one view controller, it would get convoluted FAST by trying to manage multiple sections.
A good route may be this: Embed the whole hierarchy in a navigation controller, which gives you the top bar. Then make a custom view controller class which knows how to make your bottom bar, and have each section subclass that.
The side effect is that the bottom bar will be uniquely created for each section VC. If that is not desirable for you, you can explore view controller 'containment'. It is basically a technique for building components like the navigation controller, which keep certain elements onscreen for a long time, while exchanging 'content' view controllers for a smaller portion of the screen. It's not the easiest thing to do, and should be considered carefully. However, if you really need to keep the same instance of something on screen while other view controllers come and go, it may be the right way to go. That said, consider the other idea first (each section manages it's own bottom bar). You can accomplish it in a way that promotes code re-use, etc.
I am trying to wrap my head around controllers in Cocoa Touch. The main problem is that I would like to have more than one controller “on screen” at once – I want to have a large view (with controller A) composed of smaller views controlled by their own controllers (say B). I’d like to have it this way because the division makes the code much cleaner. What’s bad is that the additional controllers (of type B) are not “first-class citizens” on the screen, for example they do not receive the autorotation queries and notifications. (And cannot easily display modal controllers, they have to send the presentModal… message to their parent controller.)
What is the difference between the A and B controllers from Cocoa viewpoint? Does the system keep some kind of pointer to the “frontmost controller”, a privileged one to which it sends notifications and such stuff? Why don’t the other controllers receive them, even though their views are on the screen? Is having multiple controllers “on screen” considered a hack? Or is it supported and I am just missing some point? Thank you.
More about the problem I am trying to solve: I am writing a simple photo browser. Photos are displayed in full screen, user can swipe left or right to change photos. The A controller takes care of the scrolling part and the B controllers take care of each photo itself.
Isolating B seemed like a good idea, since the photos are loaded from network and there is a lot that can happen, like the network might be down et cetera. In the B controller the code is fairly simple, since B only works with one particular photo. If I moved the code to the A controller, things would get messy.
The only thing I don’t like about the current solution is that I have to manually work around B not being a “first-class” controller. I have to pass some calls manually through A to B and when B wants to display a modal dialog, it has to send the presentModal… to A. Which is ugly.
There is now a first-class support for this scenario since iOS 5, it’s called controller containment.
swift controller containment
objc controller containment.
It's not closely related to the original question but important. Apple clearly states in View Controller Programming Guide that a view controller is responsible for controlling exactly one screen's content:
"Each custom view controller object you create is responsible for managing exactly one screen’s worth of content. The one-to-one correspondence between a view controller and a screen is a very important consideration in the design of your application. You should not use multiple custom view controllers to manage different portions of the same screen. Similarly, you should not use a single custom view controller object to manage multiple screens worth of content.
Note: If you want to divide a single screen into multiple areas and manage each one separately, use generic controller objects (custom objects descending from NSObject) instead of view controller objects to manage each subsection of the screen. Then use a single view controller object to manage the generic controller objects. The view controller coordinates the overall screen interactions but forwards messages as needed to the generic controller objects it manages."
However in iPad Programming Guide they also say that there may be container view controllers:
"A view controller is responsible for a single view. Most of the time, a view controller’s view is expected to fill the entire span of the application window. In some cases, though, a view controller may be embedded inside another view controller (known as a container view controller) and presented along with other content. Navigation and tab bar controllers are examples of container view controllers."
Up to my current knowledge I would not use sub-view controllers in a view controller but try to subclass NSObject and send messages to them from my main view controller.
Also check this thread:
MGSplitViewController discussion
First, and this is important, view controllers don't get "on screen" -- views do. Your "top level" controller can certainly pass along the kinds of messages you're describing to its "sub-view-controllers". In fact, this is how most apps work. Consider an app that has a tab bar, and where the views use navigation controllers. You actually have several view controllers "running" at the same time, each with its own view on screen at once -- your "root" view controller will be an instance (or subclass) of UITabBarController, which then has several nested UINavigationControllers, each which will display nested view controllers (like an instance or a subclass of UITableViewController).
You might want to read up a bit on how responder chains work. Consider a touch event. It will be generated for the view closest to the top of the stack, that can receive events, which is also underneath the tap. If that view can't handle it, it gets passed up the view hierarchy food chain until something deals with it (and then eats it).
As to the specifics of your question, on the whole, I'm not sure exactly what the strategy you describe is really doing to benefit you in terms of complexity. It depends on how exactly you're implementing things, but having separate view controllers for each little subview may require more bookkeeping code than just having one view controller that knows about all its sub-view components.
This is a pretty old question, but since I guess there are people who might face the same problem today I'd like to share my solution.
I was writing this application that had this one screen with a lot of information, pagination, controls etc. Since according to Apple's MVC documentation on the role of ViewControllers, you should not implement the logic in view itself, or access the data model directly from it, I had to choose between having a Massive ViewController with a few thousand lines of code which was both hard to maintain and debug(even with unit tests) or find a new way.
My solution was to use UIContainerView like below:
this way, you can implement each part's logic in it's own ViewController, and the parent view controller takes care of constraints and sizing of the views.
Note: This answer is just a guide to show the way, you can find a good and detailed explanation on how it works and how to implement it HERE
Actually you can make it work earlier than iOS 5, since most of us are targeting 4.x and 5.x at the same time. I've created a solution that works in both, and it works great, few apps in appstore use it :) Read my article about this or just download and use a simple class that I've created for this purpose.
I'm programming for the iPhone and I'm wondering when to use the addSubview method of a view and when to present to use the modal view controller (presentModalViewController). What complicates this even more is if you are using a navigation controller (I'm not) and you can use the pushViewController method?
When would you use each and why?
Thanks.
-presentModalViewController and -pushViewController are two ways of going about the same thing: displaying a new view. Which you use depends on the user experience you're going for. They mean different things to the user, but are very similar in implementation.
-addSubview is completely different. It adds components to the current view. You should never use it to display an independent UI. -addSubview is most often used when programmatically creating the UI in -loadView, though it has many other uses.
Here's one way to look at it:
A sequence of view-controllers within single navigatoin controller represent a single workflow in user's head. If at some point you need to interrupt the current workflow and create a diverging workflow you create a modal dialog. If the new workflow only has one step you simply present corresponding controller, but if there are many steps you create a new navigation controller to string the steps together.
The visuals are different - with nav controller user's attention moves from left to right, while with modal dialog from top to bottom. Imagine that you are flipping a book (left-to-right) and at some point you move the book away from you and then pull another book from under the table and place it in front of you (top to bottom), and then start going through that another book (left-to-right). Then you close the whole second book and move back to first book where you left off.
The addSubview method is on a different abstraction plane - subviews are used to create the two experiences I described above. You can use subviews to create a different experience which would be on the same abstraction level. Couple more examples of the constructs on the same level are UIAlertView and UIActionSheet.
Im a budding iphone developer, and doing my best but i have a query regarding the UINavigationController.
I have a tab bar app, with 3 tabs.
The 1st tab has five UIButtons, each loading a different "section" of the app, and each section will have a number of views.
The other tabs simply display some info.
as users select any of the UIButtons on my first tab i am using [self.view addSubview: xxxxx];
and as users navigate away from this view i use [self.view removeFromSuperview];
My question is:
Is this a bad way to do things? should i use a navigation controller? The reason i have not used one is because i wanted a custom looking UI and i understand that the navigation controller forces your design a little.
And on top of that i will be using core data to implement persistent storage.... will my way of implementing this application cause an issue with core data?
Any help regarding thsi would be highly appreciated.
Cheers
Tom
First, if you don't need a navigation controller, then don't use it. You shouldn't feel bad about it. That said, I think UINavigationController doesn't impose a specific UI on you at all. It's very easy to hide the navigation bar and implement any UI you like. The thing that UINavigationController does impose is a modular design: each view is managed by a separate view controller and takes up the full screen. Only you can answer if this design is suitable for your app. If it is and if your app is designed around a hierarchy of views, a navigation controller is probably a good choice.
As you said: when one of the five buttons is tapped the users is navigating to another view and the five buttons disappear. This is what the navigation controller is designed for and helps you manage the memory better than simply adding and removing views (depending on how many views are added/removed it might also be better on performance). As Ole points out the NavigationController is highly customizable and doesn't impose much.
A NavigationController gives you more flexibility down the road: say you want to add another hierarchy level after one of the buttons has been tapped in version 2.0. Then you will find that your MainView will be growing as you keep adding views to it. A UINavigationController keeps your code well structured and lets you extend the navigation later one.
CoreData is very flexible and UI-independent. You shouldn't have to worry about this.