I would like to put two different views( list and map) into one View Controller. User will be able to change view by pressing the right button on the top. For both there will be search option. If this possible, I want to separate classes for list and map.
I would be gratefull for some tip how to make it.
views http://img201.imageshack.us/img201/1104/56044506.png
I would suggest you create a parent class that is a subclass of UIViewController, the purpose of this class will be to handle the search bar functionality and any common delegate callbacks from your datasource.
From a theory perspective this class will act as an abstract class, meaning it should only ever be subclassed rather than directly initialised, but as this is not possible to enforce in objective-c don't worry too much about that.
This next part depends on whether you'd like to use two view controllers for list and map (as at the end of the question you said you wanted to use two classes...?)
You can then either create two UIViewControllers, one for map and one for list, and they both will subclass the above mentioned abstract class. This will allow them to inherit the datasource delegate callbacks and search bar functionality.
Or you can combine the two into one UIViewController that subclasses the above mentioned abstract class and as in A'sa Dickens answer, you can manage two views in a single xib file and swap between them by hiding and showing, or adding and removing them from their superview.
Hope this helps.
with in your xib or storyboard have 2 views 1 for the map view and 1 for the list view, when ever they click one of the buttons it hides one of the views and reveals the other with the hidden property
[listView setHidden:NO];
that's an example ....
make sure you have a reference to both views, and that the reference is linked. That is an obscure way to do it. you could also try a tab view controller... but that is more complicated
Use a UITableView and a MKMapView and add them to the same content view.
Use the hidden property to hide and unhide the views depending on the button clicked by the user.
Related
I'm new to Swift, so I apologize for my lack of knowledge of almost anything related to Swift.
Right now, I'm developing an app that uses the ARSlidingPanel library, so now there are two ViewControllers present on the screen (Main view, with the dark background, and Panel view, which is the green background). I want to be able to set vars/call functions from the Panel view to the Main view. For example if I click a button in the panel view, I want to display some text in the main view. Right now I've started with using static vars but from my knowledge of Java/Android, I know this is probably not the right way to go. Any tips for a cleaner/more acceptable way of doing things?
There are a few different options here. However, the first thing that comes up to mind is if you really need to use two independent view controllers for the same view?.
One solution would be to use delegates. Write a swift protocol that has has the methods and functionality you want to expose, for example setting up values in the view controller's outlets, then implement the protocol in one view controller. In your other view controller, you can then create a delegate variable of type UIViewController -let delegate: UIViewController - and use that instance of your delegate to modify the view. Here's a guide on this
Even better, you can add view controllers as sub view controllers
of your view, apple provides a good bit of documentation on this, you
can find it
here.
Hope this helps.
I have an application where every view controller subclasses from BaseViewController (A custom view controller that subclasses from UIViewController). I need to differentiate the subviews of a certain view controller's view from each other, from the BaseViewController. The application is pretty huge and each subview doesn't necessarily have a tag. What other ways are there to differentiate the sub views?
The application is pretty huge and each subView doesn't necessarily have a "tag". What other ways are there to differentiate the subViews?
That's exactly what the tag property is for -- differentiating between views that are otherwise similar, like each button in an array of buttons. You should only need to differentiate between the subviews managed by a single view controller at any given time; any given view should only be known by the view controller that manages its parent view, so the size of the app really doesn't change the tag property's utility.
The other obvious way to tell the difference between views is to use the fact that they're distinct objects, each with its own address. For example, say you've got a bunch of similar views representing people on a seating chart, and you want to keep track of which view goes with each person in the chart. One way to do that is to have your view controller maintain a NSDictionary where the keys are people and the values are the views.
XIB and Storyboard files are just XML. You could write a script to load the XML, put in tag attributes and save. The XML element name tells you what kind of view it is (button, imageView, etc).
Alternatively, if you can have different tags on each load, you can just programmatically tag the subviews in viewDidLoad
I want to launch a XLForms view controller as a Form Sheet. I want the controller to have a toolbar at the top and then the XLForm tableview underneath it. How?
The view controller isn't a navigation controller and so I need to add a toolbar at the top (or bottom) where I can add buttons. So how do I do this?
It turns out that this is not too difficult. I just wish that it was documented somewhere.
All the sample code I could find showed the top view controller inheriting from XLFormViewController. In this case, the IB controller only requires a topline view.
I wanted to expand the view controller to have other components in it other than just a "View" object. I wanted a toolbar across the top and a couple of other things.
So, here's how I did it. I'm not sure that this is the best approach but it did work.
Create the View Controller in IB and add all the components you want.
Include a TableView object someone in your design
Go into the "Assistant Editor" and hook the TableView object to the "tableView" object defined in XLFormViewController.h by ctrl-dragging and dropping on the IBOutlet tableView object.
All other controls work as usual.
Important:
Do not treat the tableView object like a regular object. In other words, do not implement UITableViewDataSource and UITableViewDelegate methods.
Hope this helps.
I am using ECSlidingViewController, a library that gives a side-drawer effect. My application opens to a (navigation controller holding a) table view controller of 'Nearby' results, and the cells segue to a scroll view controller.
The hidden left menu is a table view controller (of different class) with a few options, 2 of which are other table view controllers that will use the same layout, cell prototypes, and detail scroll view as the table view seen on startup.
I would like to know if it would be better design to make a more generic tableView with some sort of property like an enum'd typeOfDisplay, which lets me conditionally manage different nuances like populating cells from server/CoreData, navbar titles, sort order, toggling auto-updating, editability, etc. - OR - if I should make a NavigationController->TableViewController->ScrollViewController for each different view controller (A 'Nearby', 'Featured', and 'Saved')
I'd like to reuse my table view because the cells/display/detail will be identical, but the methods for populating the table are different, and I don't want to make something that's difficult to modify.
Edits -
If you are familiar with table views inside tab-bar contollers, the implementation details should be nearly the same.
It's better to put view configuration into view controller. But there can be ways to reuse the configuration actions.
I have ran into the same situation like yours. And I decided to use Strategy Pattern to refactor my controllers. I put all the data related stuff into a TableDataManager class which conforms to the UITableViewDataSource and UITableViewDelegate protocols and I applied polymorphism to it to configure the data in cells and the appearance of the UITableView under different circumstances at runtime.
All the identical actions are implemented in TableDataManager, and nuances are overridden by subclasses of TableDataManager. By assigning a proper subclass of TableDataManager to a view controller, there is no need for you to copy and paste the identical cells/display/detail actions here and there.
That's my experiences. Hope it will help.
I would recommend you to use different view controllers for different datasources. It sounds good initially to put them all together in one place, but as time goes by, you may need to add different functionalities to each table view, and your view controller will be a horrible mess.
I need to implement an accordion control for iOS. By accordion, I mean a UI like this:
I see two basic ways to do this, but I'm not sure which one to choose.
Method #1: Create a ViewController container, something like a UITabBarController, except that instead of showing tabs at the bottom, I draw a vertical stack of buttons, and when you tap one, the corresponding panel opens and shows the corresponding view controller's view.
Method #2: Create a composite view, add a bunch of views directly to it, and show/hide them as needed.
How do I choose here? What would make me want to treat the sub-units as view controllers vs views?
Generally speaking, if I can avoid it I try not to subclass UIView and instead do everything within UIViewController subclasses. A controller is usually required anyway (model/view glue code, user interaction, delegate stuff, notification handling, etc.), so if no custom drawing is needed it is usually possible to do without a UIView subclass.
In your case I could envision one reusable UIViewController subclass that represents a list entry. It has the following responsibilities:
Create two alternate view hierarchies (collapsed/button, expanded/panel)
Toggle between the view hierarchies in reaction to user interaction (with/without animation)
And another UIViewController subclass that represents the entire list. It has the following responsibilities:
Override the appropriate methods from UIViewController to make it into a container VC
Add/remove child VCs as appropriate to the internal model
Possibly adjust the container view in reaction to collapse/expand events in its child VCs