This seems like a typical problem, but I have a UITableView that has identical behavior for two separate data sources. What is the best way of going about designing the class hierarchy to have as little duplication and if/else conditions? The view controller is going to do the same exact thing to both data sources, they're just unique in their data set. Should I have the parent controller just set its data source/respective title?
The same issue is relevant as well when using a UISegmentControl for displaying two views with the same interfaces, but different data sources.
Be careful with your terminology here. A UITableView has something called a dataSource but you seem to be referring, essentially, to two different sets of data.
In the case you're suggesting, in the table's dataSource (the object that adheres to the UITableViewDataSource protocol), I'd have three arrays.
currentlyViewedArray
datasetOneArray
datasetTwoArray
In the dataSource methods, use the currentlyViewedArray as the source of the table's data.
Then, set the currentlyViewedArray to whichever array you want to view:
self.currentlyViewedArray = self.datasetOneArray;
[theTableView reloadData];
You can use the UISegmentedControl to switch between the two arrays.
Related
1) My problem: how to call NumberofRowsInSection of UItableViewDataSource Method of another UItableViewdataSource.
2 ) HOw to make aggrateTableViewDataSource from n number of Different CustomTableViewDataSource?
Need Help.
Thanks
I think there is some conceptional confusion in your question.
datasource is a delegate protocol. That means that you can have a class that adopts that protocol. That again means that it has certain required or optional methods, e.g. tableView:numberOfRowsInSection: in the case of the protocol UITableViewDataSource.
Therefore there is no such thing as "two datasources". If your class that implements the datasource protocol has more than one source for its data, that's a different kind of "data source" - and a question completely unrelated to the datasource protocol for table views.
Of course, you can have more than one UITableView that refers to the same class as its datasource. This is actually common for search tables which typically can display both the original and the search result table. In this case, you check in your datasource methods which table view is requesting the data.
I would suggest to make a model that calculates this from the source, not the tables. If you are using core data, create a class that fetches the objects and calculates the figures then observes changes to update the basis for the figures. Make your aggregate functions output as read only properties.
If not core data use, I'd need more info to advise.
I have a bunch of model objects that inherit from NSObject (Result). And I have a bunch of view objects that inherit from UIView (ResultView). They exist in a 1:1 relationship (one model for one view). In my controller I have an two arrays: one for Result objects and one for ResultView objects. The controller displays many of these result views and they can be added/deleted/reordered. Trying to keep 2 arrays in sync (results & resultViews) isn't working out. How should I approach this problem?
I'm considering initializing a view object with a model object (eg: an initWithResult: in my ResultView class and then retain a pointer to the Result object in the ResultView). Then I could do something like ResultView.result to access model data. Is there a better solution? This would break MVC, wouldn't it?
Unless you're trying to persist these model objects in a DB or something similar, I would put a view property on the model objects. If you don't have to create the view for any reason, then just nil it out to save on memory.
Does it break MVC? I guess. But if your model objects will always have a view associated with them, it starts to go into the blurry line area. No programming god will send you to hell for breaking the standard a little bit.
Do what's clean, optimal, and easiest for another programmer to understand when looking at your code.
Ok, if I understand your question correctly, the model objects are persistent while the views are dynamically created/deleted. You are relying implicitly on the index of the two arrays to achieve the mapping of two parts. One simple way is to add a "model object id" in your view class. Then you can easily reference to the correct model object in the view.
thanks right away. This is my first question and am excited to join the iOS developer community. I have one core data entity (say, a car). I have a tab view controller with two tabs - one displaying all cars and another displaying all types of cars (Chevy, Ford, etc.). The question deals with this second view controller. My question is - do I want to fetch all of my cars when the tab is loaded then pass all relevant cars of that type when the row is selected, or do I want to fetch my results after a row is selected meaning I'd have a different view controller for each type of car?
UPDATE:
I do, indeed, have two table views. The second one with the types has a list of types. When a row is selected I'm curious if I should pass the relevant cars to this VC or fetch the results?
I'd say you use 2 ViewControllers: 1 for all the Cars and then 1 for all the relevant cars of that type. You can just pass the relevant data (let's say an array of carmodels) from the FirstVC (where you put your initial array of cars , or dictionary if you will) to the secondVC and adjust your VC-looks accordingly.
(Seems you want to work with a UITableView to do this, it is very simple to pass these kind of messages through to a new VC and do the customization you want anyway)
You will all find your UITableView answers right here in the AppleDoc: http://developer.apple.com/library/ios/#DOCUMENTATION/UIKit/Reference/UITableView_Class/Reference/Reference.html
A UITableView object must have an object that acts as a data source and an object that acts as a delegate; typically these objects are either the application delegate or, more frequently, a custom UITableViewController object. The data source must adopt the UITableViewDataSource protocol and the delegate must adopt the UITableViewDelegate protocol. The data source provides information that UITableView needs to construct tables and manages the data model when rows of a table are inserted, deleted, or reordered. The delegate provides the cells used by tables and performs other tasks, such as managing accessory views and selections.
One of these delegate methods you seek is the
- (void)tableView:(UITableView *)tableView didSelectRowAtIndexPath:(NSIndexPath *)indexPath
This method will trigger when you select a row in your tableView. In this method you want to call and show your new VC and this is also when you pass the relevant data to that new VC. The rest of the above will still hold up then.
Good luck.
Problem Statement :== I have an application wherein I need to draw different cells at different table view controllers based on the kind of data my controller is holding. I have like 17 odd cell types.
My Solution :== I am thinking of writing 17 different classes each returning a particular type of cell. Now my controller classes will call a cellSelectionController along with the data it have which in turn, based on data and kind of controller, will instantiate the specific cell class and return the UITableViewCell object.
Is the correct way of implementing this scenario or something better than can be done keeping all design issues in mind?
I don't know that it's a better solution, but Matt Gallagher has some good stuff about heterogenous table cells in a recent post: UITableView construction, drawing and management (revisited)
Although there is sample code in the ADC for parent/child (one to many rather than inheritance) core data, the child relationship is managed by simply loading all of the related objects into a set, and then into an array. The application I have in mind may have huge amounts of related data per parent object, therefore I would like to use NSFetchedResultsController on the child side. My attempts to do this have worked other than the controllerDidChangeContent delegate callback. With one fetched results controller on the master tableviewcontroller and another on the many side, and aFetchedResultsController.delegate = self; the delegate callbacks were fired against random objects - errors returned from invalid selector 'controllerDidChangeContent:' on things like the toolbar and sqllite whenever the underlying data was updated.
Can anyone suggest working sample code of how to use NSFetchedResultsController in both parent and child parts of a relationship.
You definitely can implement an app with several table views in which each table view has a table view controller as its datasource/delegate and each table view controller has its own fetched results controller (that may fetch objects of different entities and/or with different filter predicates and/or with different sort descriptor(s)).
It would be hard to give you specific recommendations without knowing more about what your are doing (with code examples) and the specific issue(s) that you are having.