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.
Related
I've fairly new to Swift and I've been reading a lot of answers to questions but I'm still struggling to figure this out. For what I'm building, I want the option to swipe between three main pages but I also want a tab bar that serves as an index and another option to navigate between the three pages. Currently I have three main pages that are each embedded in individual navigation views which are embedded in a page view controller. I tried simply adding a tab bar for each of the pages but that doesn't seem very practical. I was reading on orders of embedding but it doesn't seem to be what I want. How would I go about doing this? Thank you!
sounds like a lot of hierarchy but maybe you can try this
Have a single UIViewController that holds your page view controller. Build a custom uiview guy that holds three buttons which will serve as your tab bar and pin it to the bottom of this UIViewController.
For your page view controller, you can proceed as normal and have it hold 3
children. You'll need proper delegation with protocols from: custom tab bar > uiviewcontroller to tell him to move the pages around.
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 developing app that has multiple skins and I have a dilemma on how to implement this.
One of the solutions would be to have separate nib files for every skin, and load it depending on which skin is currently selected. Problem with this is that I can't edit navigation bar of navigation controller (which my app uses), and I have to change it's background image and back button image etc.. I came up with an idea to hide this navigation bar on every screen and replace it with custom UIView in Interface Builder which will act as navigation bar and custom back button with IBAction for popping current View Controller, so that user won't see any difference.
Is this approach acceptable and if I make it this way, will I have problems with rejection in App Store?
If you choose to hide & replace the UINavigationBar with your own UIView it's no problem as far as Apple goes.
However, I can tell you that you will have to spend some time trying to replicate some visual effects that come naturally with UINavigationBar.
For example, when you push/pop a new controller, you will see that the navigation bar title will slide & fade beautifully. The same applies for left and right bar items.
Personally I would not completely hide the UINavigationBar, but customize it. In the end it all depends on what you want, but by default the UINavigationBar is pretty customizable.
You can add your own buttons or even entire UIViews as left and right bar items. Also, you can add your own UIView as the title (with your own label, custom font or whatever) or change the background.
EDIT:
To easily customize the looks in your entire application, you can subclass UINavigationController and create your own CustomUINavigationController. Then, in viewDidLoad method you can change whatever you want to the navigation bar and this will be accessible in the entire application.
No way, what you are doing is perfect. This will work & no way it will get rejected from app store (just based on this approach). I too have explored several ways to provide skins & what you wrote seemed to be the least hassle-some. Plus its way more easier to create UI elements in Interface Builder hence the separate nib files for different skins.
I am saying this so confidently 'coz I have done the same thing & app store approved.
Best of luck.
Trying to implement the following behavior on an iPad.
I have a map-centric application which uses a tab-bar interface. The tabs at the bottom allow the user to choose between looking at the various different types of points that are marked on the map (e.g, think of the tab-bar items "food", "lodging" and "gas", where the "food" tab shows a listview of all the restaurants in the area, and so on).
The top half of the screen should always show the map. The bottom half of the screen is what should be controlled by the tab bar. However, there needs to be one tab on the tab bar that will make the map full-screen (not covering the tab bar itself, but covering everything else).
My impulse is that what I need is a map-view which always covers the whole screen, and then a tab-bar-controller that controls a view which sits on top of the map view, and then when the user selects the full-screen-map tab, the content view just gets hidden. But how do I actually do that?
Thanks!
I would go so far to say that this barely possible using a standard UITabBarController. Instead, you should use the UITabBar directly in your interface and then link the actions of the items directly to your root view controller. This controller should then lay out the content area accordingly. This could be done quite easily by giving your nib a structure like this:
- ViewController
- View
- View // place contents here
- TabBar
- Item1 // link action to ViewController
- ...
Depending on how generic you want your solution to be, you could also implement a custom subclass of UITabBarController that does the custom layout. The above solution is the simplest and might require the least code.