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.
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.
I've put together an app that uses a table view and navigation controller to display a list of documents (HTML docs) and by clicking on a document title will open up a detail view and display its contents. That works a treat but it will ultimately be part of a bigger app which will have a menu of which this would be just one of the options.
I've done a lot of digging around but am still unsure on the best approach to take for building the overall app. A lot of advice seems to be to use the navigation based application template and push out the menu view and hide the navigation bar but is this really the recommended way to go?
I've read the Apple docs and Modal View controllers sounds like they could be and option but I am then unsure how I would slot in my existing RootViewController etc?
Really appreciate someone taking the time to help get me on the right track
Cheers
Kieron
Using a navigation controller is a very common way of structuring this. And as you note, the nav bar itself can be hidden on some view controllers.
Be careful about presenting view controllers modally -- Apple's advice in the HIG is to use modals when you are focusing the user's attention on a certain piece of information or a crucial task -- don't just use them willy-nilly.
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...
I've got a UISearchBar in my view, and when the results button is pressed I'd like it to load in a new view. Is this possible without using a navigation controller?
I'm new to iPhone development so not entirely sure if moving between views is solely reliable on a navigation controller or not. From all the examples I've seen using pushViewController, it seems to look that way. Hoping I'm proven wrong.
UINavigationController provides the simplest way to manage a stack of view controllers, but it's not necessary by any means; you can move your views around, and add and remove them from the hierarchy, however you like. Can you elaborate on what you're trying to do, and why you want to avoid using a navigation controller?
This is more of a philosophical question than anything, so give me your thoughts.
The iPhone SDK documentation specifies that you may have a tab bar controller contain a navigation controller, but you can't have a navigation controller contain a tab bar controller. It seems that there are times when you might want to organize views within a view that is part of a navigation controller stack in a tabular fashion. Is this unreasonable?
I accept what Apple dictates in these areas as gospel as the HIG does provide best practices that seem to reveal the path of least resistance (I'm sure there are exceptions to that). In the tab bar case, however, I'm not sure the design reasoning behind it. Maybe it's obvious to others, but I can't think of a good reason why you wouldn't allow tabs as anything but a root level view controller.
What do you all think/know? What design flaw would this create? How would you solve this problem of wanting a tabular presentation of views within a view? Do I need to re-think the entire design?
Thanks.
I can see where they are coming from, from a design perspective. Tabbars feel anchored, constant, where navbars feel dynamic and mutable. So a tab containing dynamic content makes sense, whereas a single spot in the dynamic hierarchy of a navigation stack containing a tab bar, anchored to the bottom of the screen doesn't feel as right. The Three20 implementation does handle this in a way that makes more sense, anchoring the tabs underneath the nav bar, so that they feel more like they are part of that spot in the navigation stack.
Having said that, Tweetie rolls it's own tab bar, if I remember correctly, without a UITabbarController to circumvent this detail in the UI guidelines, and it totally works from an interaction perspective.
The short answer is it would be confusing to the user to allow UITabBars inside a nav controller. The app would certainly not behave as most users would expect. But, that's just UITabBar, not the design concept of tabs in general. Tabs inside a nav controller, should, in my design opinion, go at the top, not the bottom, as does a UITabBar.
There are a few different ways to do this.
I've done "tabs" inside a navigator view controller by having the first row in a table view have a segmented picker. (See the HangTime app on the app store). I think it works pretty well, but they aren't really "tabs".
Joe Hewitt, the guy who wrote the Facebook app, solved this problem by creating his own "tab bar" view and controller, although it's rendered quite differently than a UITabBar. That element is available through the Three20 framework, and open source library. Check it out:
http://github.com/joehewitt/three20/tree/master
I think the tab bar controller is intended to be the main point of navigation around an app if it's used. If a nav controller contains a tab controller, then the tabs will switch whenever you navigate elsewhere, which may be confusing to users who are used to using them the regular way in other apps. I think its a cool idea however, but apple may not feel the same way.