More of a "best practice" question with regards to good application design. I have an application that has a number of popover controllers, each with different content. My first instinct was to create a new TableViewController for the content of each popover.
Is this the best way to go about things? I was wondering if it was possible or more tidy to handle the display of all this content within one TableViewController, and present different arrays of content depending on the popover?
Thanks
Unless your delegate/data source code is very similar between all tables I would recommend keeping the classes apart. It will make your code more modifiable in the future if you want to sub-split out one of these views or add additional popovers.
Related
I am busy to learn building applications for iOS and started creating one by myself. I am currently running against the following and am curious about the process of other iOS developers out here.
Populair apps like Twitter has multiple sections within a view controller. What is the best method to organize a layout on one Storyboard with multiple sections like a header section with labels, a tableview and a mapview?
"What is the best way to..." type questions are not a good fit for SO. That leads to opinion-based answers, and possible arguments.
Better to ask "What are some options to..." type questions.
If you are looking to create a modular design where you divide your screen into discrete tiles, you can look at using container views and embed segues. With that design you can make a view controller responsible for a section of the screen. Then you can embed one of those view controllers in another view controller wherever you want it.
I won't say it is "the best" way, but it is an approach that can be useful.
I'm making a UITableView that is going to act as a settings view controller. Obviously its going to have a few types of input. One cell might have a slider, one might drill down to another view controller, one with a textbox etc. Is there any way to avoid making umpteen different subclasses for UITableViewCell?
Try this github project: QuickDialog.
I found this in SO; it doesn't exactly answer my question, which is: is there a way to clone a UITableView from one controller to another while using Storyboards and maintain synchronization?
You can clone them in the sense that their initial property values remain the same, like position, layout etc. For this, just copy the UITableView from storyboard, go to destination view controller and paste it there.
If you share same UITableView object between two view controllers, it is still possible, but you must estimate how much work you would have to do yourself. When a view controller solely handles a table view, much of the work is done under the hood and table is handed over to you. In case of your UITableView shared between two view controllers, you would have to play with it quite carefully. You need to take care of entire life cycle of the view - see the usual methods like viewDidLoad, viewDidAppear and so on. How would you take care of them when your view exists in two scenes? Maybe you would be inventing a unique design pattern - if at all you find the most optimistic and programmatically correct way to accomplish it.
With storyboards, you cannot achieve cloning up to the level wherein data changes will reflect seamlessly between the two. Storyboard is, as the name suggest, just a board, where you can draw things to know how would they look initially, before your code takes over.
In order to achieve what you want, you have to create a shared model that updates two table views through proper delegate methods. Most likely such a model (NSArray, or any such collections as per your requirement) can reside inside a shared class (app delegate isn't a wrong choice), from where both your view controllers can refer to it. That is neat practice, it not only is right from programming perspective but also extensible and helpful to anyone who deals with the code any time.
For details about how to update UI from your model, there is nothing better than starting from scratch, going through the books I mean.
I am not aware of such possibilities.
I would pass the tableview source object amongst different controllers and let the view controller handle their own table view.
I think the best approach would be to use a framework such as the freely available Sensible TableView, then use the same model for both table views. This should be really straight forward.
So what I'm looking to do is have a UIPageViewController that will end up displaying three view controller vies, one fully visible and then two as previews to the right and left. An example would be the iOS6 App Store:
Is doing this using a UIPageViewController set to UIPageViewControllerTransitionStyleScroll possible?
Basically I'd ideally like to have is a case where I can have three UIViewControllers that I recycle as the user pages through the 1- items in the list (with n being at least 50). I know an interface that behaves like this can be done with a UIScrollView with paging enable, but re-using views would take some view shuffling code that I'd rather not write if Apple has already done it for me.
I'm totally comfortable with the fact that this is iOS6 only, by the way, and also comfortable with alternatives, if they exist.
Thanks!
Check the new collection view. I think you may be able to create something like that with reusing cell etc.
I want to have two tables and a webview in one iPad screen from the following:
The first table will parse items from an RSS feed, and will have an option for a
checkmark
The second table will be comprised of all checked items
The webview will be the content from didSelectRowAtIndexPath from the first table (so basically the first table gives the opportunity to display content from didSelectRow, AND check a box (or whatever) to create the secondary table.
I am told for the second table, I should have the checks write to a plist with NSMutableDictionary, and then the second table will just be a table of the plist...but really, what's the code for this?...where do I put it?...etc etc etc. And if the user unchecks the items, the line in the plist will be cleared, right???
I PRESUME I can show all three classes in one screen with something like
[viewController.view addSubview:someOtherViewControler.view];
Is there any reason why I should not do this??
Thanks so much!
XOXO
There is no reason you shouldn't do this, and you will be happier with your proposed approach than you would be if you tried to do it all with one view controller.
Organizing with design patterns is done to simplify design and maintenance of your software. What you have described is clearly three independent data sources each with their own independent views. You can use the MVC design pattern independently on each one of them. This independence lends itself to having separate view controllers that are easy to design and maintain.
The fact that they are collected into one main view for your application is outweighed by the simplification in maintainability that you will obtain with separate view controllers.