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!
Related
i am struggling to add a side menu to my already existing app.
i've read all kinds of tutorials, but almost each and everyone of them uses a container ViewController, which I'd try to avoid to use..
I got a single page app, with thousand of code rows, embedded into a navigation controller (for a additional settings page)
I've added a UIBarbuttonItem on the top left to toggle the visibility of the menu.
now I created the side menu in a different ViewController on the Storyboard / InterfaceBuilder, and just can't find a way to easily slide that ViewController in from the left side.
one approach was to create single view behind my app and push the main view aside to reveal that view, but the result was not as sexy as I wanted it to be, and designing a view in the background of another view would not be that easy to work with too...
I'd just use a container View Controller if I absolutly have to, and I don't want to use any cocoa pods...
does anyone know how to proceed? any push in the right direction'd be greatly appreciated!
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 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'm looking to create a UI similar to that of the Maps application just to try out some odds and ends and brush up on my knowledge of interface builder.
What i'm struggling to discern at the moment is how the Maps application handles the interactions between the toolbar and the navigation controller and which UI elements are needed to mimic the interface. I'm guessing that the Maps app only has one view controller which kind of negates the need for a navigation controller so i'm not sure if i'm using the right application template currently but i'll come back to that one later.
To give you an idea of what I'm looking to copy, if you search for directions between two locations and then hit route, the navigation controller changes from:
[Clear] Directions [Cancel]
to:
[Edit] {car | train | walk} [Start]
That's all fine so far, nothing out of the ordinary from what i'm used to doing. What is confusing me however is the semi transparent view underneath the navigation controller that displays the total distance and time (or other information depending on the search method). What is the UI element? Is it simply a toolbar tacked on to the main view? How would I go about adding this to my app, is it part of the view, or part of the navigation controller?
Also, in a similar vein... Clicking the "Search" segment in the toolbar displays the search field at the top of the app. Is this in the navigation controller, or is the navigation controller hidden whilst the search field is displayed? Again, clicking "Directions" displays the search field but this time with an additional search field and a button to switch the order of the fields. How is this achieved?
I'm not so good with the terminology so excuse me if i've mixed up some terms. I'm just trying to get to grips with the UI elements as i've spent most of my time learning OpenGL so it's all a bit new to me still. If anyone can point out the right UI elements used in the Maps application, that would be greatly appreciated!
Many thanks for reading.
Edit: I've uploaded an image to illustrate the UI elements i'm querying in this question.
I have no inside information, so I'm speculating on how I'd do it.
I'd use a UIToolBar for both the top and bottom bars, not a navigation bar. You can put a tool bar anywhere as they're just a subclass of UIView.
The semi transparent view underneath the navigation controller is likely just a custom view on top of the map view. Again, just a subclass of UIView.
The items in both toolbars would call methods in the view controller that could change the contents of either tool bar or hide or show other views.
For example, the Search button might call a showSearchToolbar: method, while the Directions calls a showDirectionsToolBar: method. Both methods would just change the contents of the top tool bar and hide or show the view beneath the top tool bar.
Check out the UICatalog example code from Apple to see how to dynamically change the contents of the tool bar.
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...