I've two exactly similar views which I show in a two segmented control. Refer to image below. The differences between these two views is the parameter which I send to backend to fetch the values and the title. Even the returned values are same.
I've referred to some tutorial which cycles from one view to another when segment is selected .
I've ended up with two files with exactly same code. How to optimise this implementation so that I can implement with one piece of code only.
The two contained VCs have exactly same code to fetch values from backend and display. I've only one function which I've used in both VCs to fetch but there are other code sections such as Tableview delegations and other codes which are common to both.
In storyboard both are duplicate as well.
Is there anyway I can make it more efficient?
This could be a case for making your two view controllers be subclasses of a common superclass.
Or it could be even simpler: make them two instances of the same view controller class, which knows what to do because you pass a parameter at creation time telling it what to do.
For example, my Albumen app uses four view controllers, which differ primarily just in what query they perform on the user's music library. So I've elected to make them four instances of one view controller class, with an enum property saying which query it is, and any other varying functionality determined through switch statements on that enum.
I think you need to create only 1 VC ( In IB and code ) , put all the logic inside it and either
1- Add once instance / container of it to the MainVC and manage the process of selecting a segment to reload the content ( Recommended )
2- Add 2 instances of it to the MainVC and manage hide/show when the segment is selected
Related
I'm building an iOS app in Swift which has a start page with 6 buttons. Each of those buttons will segue to a table view controller whose data is managed with an NSFetchedResultsController (application uses core data). Now, I can see it being easy to create 6 UITableViewControllers however I'm wondering if it would be more sensible to send each button to the same UITableViewController and just change the data loaded/managed by setting some kind of flag in the prepareForSegue method?
What's the best practice here? It seems crazy to have 6 tableViewControllers each backed by it's own NSFetchedResultsController when big portions of the required code for each are reusable and could be subclassed out and used multiple times.
If you can code a single view controller in a way that supports all six with a single code base, reusing a single UITableViewController makes perfect sense. Other approaches include
Composition - make a class for the data source, configure it before opening the table view, and pass it to the table view on segue
Subclassing - make an abstract base view controller, and extend it six times. Override an abstract method or two to reduce the amount of repetition
Helper - make a class that holds all reusable logic shared across the six view controllers, and call its methods from six very slip controllers.
One thing you want to avoid is code like this:
if (viewControllerType == ViewControllerOne) {
doSomethingSpecial()
} else if (viewControllerType == ViewControllerTwo) {
doSomethingElseSpecial()
} ... // and so on
When you have a chain like this, you know that you've missed an opportunity to subcllass.
I don't know if this question will be closed as opinion-based, but here's my thoughts:
Definitely use only one view controller and changed the data source in prepareforsegue()
Imagine having 6 different controllers and then deciding in 6 months that you want to change the entire UI!!! I did that. Wasn't pretty. And that was the point when I reconfigured everything and scaled down my total number of view controllers.
And don't even get me started on the pains of having to do auto layout on multiple screens. You see where I'm going with this.
I have two views, one is a main view, and another is a container view. What I wish to do is send a variable to the child and for it to execute my function. How do I tell the child view these two things from the parent view?
A few problems I have had is, ViewDidLoad does not work in container view. and when I tried to segue the information it also said that a periotical programming or container has been implemented indicating to me that the container can not be segued.
What I am trying to do is have two tables, the first table has a list, and the second table changes depending what you select in the first table. So I decided to seperate the two tables using a container view which is working for the most part.
First of all, you should note that any containers you create will be available through the childViewControllers property on your main controller. This gives you a link between the main controller and the child controller.
Now what you are trying to do is to change something in the child's table if the parent's table changes. There are many ways to do that, but in this case there is a pretty simple technique: you always know when the parent's table cell selection changes, in didSelectRowAtIndexPath. So what you need to do is simply within didSelectRowAtIndexPath, when the row changes you call a method in the child controller that passes in whatever information about the currently selected row you want to use. That method will change the table and do whatever else you want to do within the child view, since it's part of the child controller.
Using delegates or KVO or any other technique is overkill and bound to make the code much less readable.
You can use delegates to do that. Delegates are just protocols you can implement to pass data to another view:
protocol nameOfProtocol {
func someFunc
}
You can search for a tutorial or examples easily, that way you can visualize it much better than just looking at some code here.
If you want viewDidLoad to work you can create a view in storyboard, give it an identifier name (and also setting it to the correct view controller) and you can declare it like:
let viewController = storyboard?.instantiateViewControllerWithIdentifier("viewControllerName") as! ViewControllerName
For years, I've hand-coded my view code for iPhone apps, but now I'm giving storyboards another look.
One common pattern in my code is to use the same view controller in two places, but with slight UI variations. For example, when browsing a list of brands (BrandListController), I'd like to show a table view of all brands in the system; tapping a brand shows you its products. But when filtering items by brand, I'd like to show a table view of brands (with the same content and same cell appearance), but I'd like tapping a row to take you back to the filter screen instead of showing you that brand's items. I'd also like a "Search" bar button item in the top right.
It's easy to make these things happen in code, by just adding a boolean member variable so the controller can be configured before it's presented.
But how would I do this with storyboards? I could have multiple controllers segue to the same instance of BrandListController, but again, I would want the controller to have different behavior and include/exclude UI elements based on how it's used. It seems like a bad idea to create two separate instances of BrandListController in the storyboard, because then I would have to duplicate all the outlet connections and I would have to keep changes in sync. But what are my other options?
The thing to realise with Storyboards is that you don't necessarily have to only use a single storyboard.
You can use multiple storyboards or use them in conjunction with nibs etc...
However, in this case what you could do is still use you boolean property on the controller.
Then in the prepareForSegue method of the other controllers you can set this boolean property to change the behaviour. You might even have a couple of nibs that defines a small section of UI to place into the view depending on the property.
I've done stuff like this to pass blocks into view controller too.
For example...
I had a "User Search" controller that had a default behaviour of if you tap a user it will push to that user's profile page.
But I could pass in a code block that would, for instance, dismiss the search controller and I use the selected user to create a new message to them (or whatever). Or something else entirely depending on the code block I passed in.
EDIT
LOL, just re-read your question. What I did with the blocks would work for you too. I created a block property called userTappedBlock or something. If that exists then I run it when the cell is tapped. If not I do the default behaviour.
Every single time I need to create a simply tableview that is populated by a simple data set retrieved from my web server which has its code executed like this: SELECT * FROM table I find myself spending two blady whole hours trying to get the new view controller up and running as I try to update some variable names, copy and paste the required code from my previous view controllers. etc its ridiculous.
This is the end result for all my view controller pages where each will contain different data sets depending on the web service url being called:
Here is a link:
Link to downloading staple code .h .m and .xib files
This view controller contains a few simple elements seen throughout all data viewing pages:
UITableView
Titled header views
table indices.
refresh table control feature
data connection retrieval code
data connection succeeded
data connection failed
setting up all my bloody delegate and data source methods.
I find myself having to copy and paste all the staple code, functions, variables, properties, and IBOutlets; and to be frank, its getting ridiculously paintaking to have to repeat the same procedure over and over again but changing variable names between the different view controllers.
This is why I believe people create simple component like structures that make it easy for users to get tables setup and up and running.
How can I reduce this big chunk of code:
to something that will allow me at most do this:
Create a new view controller
Setup xib file
create appropriate IBOutlets, and hook them up to the xib.
Here's where it needs to change
I need to now simply able to write something like this the next time I am goin to create another data viewing View Controller:
[self setupTableForDataSetType:]; //This will make sure the tableView knows which data set its dealing with and so therefor know which DataModel classes to use
[self retrieveDataWithWebServerURL:]; //of course so that the connection code can make the right server connection with the URL given for the data set required.
Thats it. So that it is super easy for me to create the tableView pages desired and show the results quickly! Atm I have the same code everywhere in different view controllers.
Whats the best way to go about doing this?
Create a viewcontroller with all your customizable values as properties and reuse changing its values.
Well, subclassing is probably the best (maybe only) way. I've done something like this for tables with an index, since they're a bit of a pain to set up. I created a IndexedTableViewController that handles almost all the load. I make my app table view controller a subclass of that controller, and then I only need to feed a simple array of custom objects to the method, convertArray:usingSectionKey:secondarySortKey:(implemented in the IndexedTableViewController) which creates the sections and the index. The only other method I have to implement in my app table view controller is cellForRowAtIndexPath:(though I would have to implement more, especially didSelectRowAtIndexPath:, if I were doing more things with this table).
Your needs sound a bit more ambitious than this, so it would take quite a bit of work to make a superclass that would be general enough to work with most of your apps. A method like setupTableForDataSetType: could be quite complicated if it needs to handle many different data types.
My objective is to show dealer locations in two different ways: a map and a tableview.
I have a container view controller (DealersViewController) which contains two child view controllers: DealersMapViewController and DealersListViewController. The user can switch between the VCs with a UISegmentedControl placed on the navigation bar. Tapping on a map annotation or a tableview cell will push a DealersDetailViewController.
The switching is already implemented (using code from Changing view controller when Segmented Control changes) and seems to work fine, as does the pushing of the detail.
What I would like to improve is the flow of data between container and children. The dealer locations are downloaded (JSON) from the internet in the parent and on completion an NSArray *locations property is set on both the map VC and the list VC. This array will contain dictionary objects created automatically by AFNetworking, each with location data (each location dictionary will have a title, subtitle, latitude, longitude to conform to MKAnnotation protocol, but also other things like image and description etc).
My question is: How can I be sure that the container VC and both child VCs 'agree' on how location data is structured? Theoretically, if someone wanted to develop another child view controller to add to my container that shows dealer locations in a collection view for example, how can he formally know how to expect data.
Apple says: "If the container needs the child to declare methods or properties, it should define a protocol to enforce this:". I could force the children to declare the locations property but the array could contain anything…
Maybe the parent could be a datasource for the children? I haven't tried this approach yet.
I am probably overcomplicating things but my objective is also to learn how to properly create reusable components and also practice using stuff like custom protocols / delegates and design patterns in general.
Thanks.
If I understand correctly, your issue is structuring data so that all of your controllers have the same understanding of it.
Probably the best way to go around it is to create a custom location class, and have the JSON deserialize into an instance of that class and then just pass it around as you see fit. There's quite a few ways how to go around deserializing, but JSON Model is a nice example of how to handle it automatically.
Tl;dr: convert your JSON dictionaries to custom classes and then pass them to your child view controllers, via properties or delegates, whichever you find more convenient.