I'm building my very first iPhone application.
It's pretty simple, I'm displaying two lists the user can switch between using a tabbar.
I'm unfamiliar with the IB, so I'm building the UI from scratch, hoping to learn a thing or two about the inner workings that would otherwise be hidden.
My question for SO is:
Do I need a UINavigationController? There are no levels of navigation to this (yet), so the navigation stack described here seems excessive.
What's SO's advice?
Short answer: You don't need a UINavigationController.
Longer less definitive answer: Since you are just starting out I wouldn't mess with the UINavigationController just yet. Get comfortable with the UITabController and the two view controllers you need to show on each tab.
At some point, though, you may want to consider experimenting with the UINavigationController as you may find you want something to happen when a user taps on a list item within one of those lists. Perhaps you'll want to show more detail at that point, show a map, or a form, etc. That's when the UINavigationController is going to come in handy.
Well......... no you dont need one. But yes, I would take the time to use one. The UINavigationController and the UITableViewController are the two most used controllers in the iphone SDK. Better get to know them if you want to be an IOS programmer.
Also.. you said that you dont need "levels of navigation... yet". Better do it right from the beginning or you will be redoing all your code later on.
just my two pesos.
If you have two completely separate views, a UITabBar would be the far better pick.
This just shows a "ribbon" of sorts at the bottom of the screen which allows for choosing an option. The UITabBar is generally used for switching completely unrelated views, such as your use case.
On the other hand, a UINavigationController is used to form a tree-like hierarchy or drilldown and is ill suited for your use case.
Related
My goal is to have a main view, then swipe right to go to the next view, and again for the 3rd (so 3 different view controllers, all showing different information that is related to the main view), which seems to me like one of the most common features in most apps. Creating segues to other view controllers via buttons or tabs is super easy (just click and drag), but for some reason they make this common feature stupidly complicated for something that should be just as easy as simple segues in the storyboard.
I first started out researching the page view controller, only to find out that's not what I wanted and was too annoying to work with.
I think I found out that Container View is what I need, creating child views and what not. Does anyone know a good step by step tutorial to show you how to set all this up in the storyboard, like, a dummy's guide? I'm a severe novice, so a lot of the docs people point me towards have broken links, outdated code, or might as well be ancient Egyptian hieroglyphics.
Oh, and I'm learning Swift, not objective C!
It doesn't sound like you need to do anything other than use multiple view controllers to swipe through, passing data from one to the next, and so forth. I don't think using multiple views (parent / child views) is actually what you're after.
This is a very simple tutorial that will explain how to pass data through segues.
https://www.youtube.com/watch?v=guSYMPaXLaw
I am developing an iOS 5 application with the following visual structure:
where each square is a separate view. The blue views will be created dynamically (their number, the subviews, the logic behind of responding to the events). I was wondering which approach is better:
Creating different instances of BlueViewController and adding them as child view controllers to the rootViewController or
simple adding different views to the view hierarchy without creating the BlueViewController class and manipulating the views directly via the rootViewController
What are the pros and cons of both approaches?
That depends entirely on what they do. If they are merely views then you should just be adding views to the view hierarchy. E.g. if they are just showing some sort of info, then all you need is a view. If you do it this way, I would still recommend that you use a custom UIView subclass that handles your yellow views inside them and the layout.
If however, you find that each of them need to be doing quite a bit of "controller logic" e.g. handling complex algorithms and calculations then you should implement them as controllers.
Hope this is of help to you :)
Well, both are possible solutions, with pros and cons, and the right choice depends on the behavior of your app.
Using BlueViewControllers requires more lines code, but I think it is the best solution if you want different behaviors and you like well organized approach.
On the other side, adding YellowViews directly to the rootViewController could be easier, especially if your app doesn't have many views and an elaborate architecture.
In general I prefer the first approach, because, even if your project doesn't require BlueViewControllers at the moment of its development, it should help with future updates.
I have a very large form to build in my ipad application and I'm note sure which approach( between create multiple views in or multiple viewcontrollers ) to follow. Well, I have decided to split may form in logical sections, so I want use a splitviewcontroller with a root( a tableviewcontroller with the sections) and multipleviecontrollers for each sections. When the user select a row in tableview I will show the correspondent viewcontroller. I'm saving a reference for each viewcontroller in my app_delegate and the app_delegate also is the responsible for change the viewcontrollers. Is this the best approach? There is other approach to follow? About the multiple view I was thinking to put multiple view in the same xib file and then choose based in tag as the use tap the row in rootviewcontroller's tableview.
Thanks in advance. And sorry for my bad english.. Learning!
I will say this on the subject: currently, having multiple view controllers on the screen at the same time can be problematic if you're not using one of Apple's existing classes, such as a UISplitViewController.
The main issue is that important events your view controllers will want to respond to (rotation events, etc) won't be passed down to them. It's not a huge pain, it's just something to need to take into account - you'd typically create your own parent view controller that could pass these events down to its children.
Now, you are using a split view controller, so alls well on that front. There is no provided way for detail and master controllers in a split view controller to communicate with each other, but Apple recommend you employ a standard delegation pattern. If your application is fairly simple this could certainly happen in your app delegate as you do now.
If you're targeting iOS 5 only there are some changes that are relevant regarding multiple controllers on the screen at the same time, but I can't discuss them on here because of the NDA. You should go to Apple's developer forums (devforums.apple.com) to learnmore.
Sounds like I'm trying to do the same thing as you (large insurance forms here, how about your project?) Unfortunately I can't help out as you're a bit ahead of me. I've been able to flip back and forth between 8 detail views by tapping on the 8 rows in my UITableViewController, without keeping a reference to either the current or previous one anywhere. The data I enter into various TextFields stays where it should.
I currently have a xxxViewController.h/.m and corresponding .xib file for each detail view. That's an awful lot of code, but I couldn't see any other way to do it. Now I'm having a problem getting my button pressed handlers to fire. Also I've still got to put a database behind these screens.
Were you able to overcome your issue?
Thanks,
Jeff in Alabama
I'm tryin to grasp the fundamentals of Cocoa (Iphone) MVC design, but it's being quite tough. I've come accross several example applications, from the web, books.. but I've found nothing related to what I'm searching, since most of the examples just present a simple app (ie, a viewcontroller with a flipside viewcontr and a bit more..). So let's see if someone is willing to help me out in pointing me to the right direction:
My goal is to build a somewhat complex app. I'd like to have the following relation of views:
Presentation view (which would have a controller loading several memory intensive vars)
Main menu view: different options that would result in entirely new complex views. In example, a Begin option to initiate whatever the app permits to do; a second option to do another complex task with different views and actions within it, an Options option to configure options; a help option, an about option, etcetera..
In a first approach I tried to embed several rounded buttons in a view under the MainWindow nib with an associated app delegate. This approach though posed the question to how I manage to switch between views/viewcontrollers. After having uncaught exceptions because I probably don't fully understand the basics, I tried to move on to more 'simple' things.
Then I came accross the Navigation and Tabbar default Cocoa controllers. I don't want a tabbar, although it could come well for other parts of this app. Then the nav controller is what I think is most suitable for this case.
Thus, am I on the right spot if I build a hierarchichal app where its root is a nav controller? I've seen I can customize the main view to display a customized table, where each cell coud act as a button to spawn its respective view+viewcontroller. From here then I can keep building the 'leaf nodes' of this hierarchy of views/viewcontrollers, right? Eventhough I don't like the animation that by default provides the nav controller, I assume I can get rid off it..
So to sum it up in an easy way: I'd like to obtain a menu like those that can usually be seen on Cocos2d apps.
It's frustrating to ask this, I know it has to be easy but I find the documentation quite a mess aswell as the examples I've seen.. GUI programming it's being a tough learning curve :/
Thank you for any answers in advance, and excuse me for this long post.
Thus, am I on the right spot if I
build a hierarchichal app where its
root is a nav controller?
Almost. A nav controller (despite being a subclass of UIViewController) does not control views but rather other view controllers. The nav controller pushes and pops the view controllers which in turn causes the controller's respective views to load and become visible.
Therefore, the "root view" is actually the view that is controlled by the view controller that is in the nav controller topViewController property.
The app delegate serves to hold the nav controller and to tell it which view controller to push on the stack first. After that, the view controllers tell the nav controller when to push and pop them.
Otherwise, you're on the right track. You should always attempt to present information on a mobile platform in an hierarchal manner starting with the most general at the top and growing more specific as you drill down.
And you shouldn't be embarrassed at finding this confusing. 90% of the introductory/tutorial info out there, including books and Apple resources, focus on the gee whiz aspects of the interface and tell you next to nothing about the actual application design or how all the parts fit together conceptually.
You right about how little information is covered about app delegates to nav controllers. I been digging and trying to get all my screens linking etc. Having alot of fun watching my apps start to look more then just some Frankenstein monster UI. ahahah
The Itunes dev videos are great for looking at push and pop stack UIviews theory. I found they moved a little fast but after watching them the hands did make more sense. I have been forcing myself to watch them all and get a really good feel for whats going on. Hopefully have a nice app working soon.
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.