Segue a UItableView to another UITableView - objective-c

I am unsure about what exactly you must keep separate when you have a multiple MVC project. Say I have two table view controllers, the first one displays a table and when i click on a cell it segues to the second table view controller. The information for the tables is created using methods in a third separate file called FlickrFetcher. The first table View has an instance created of FlickrFetcher allowing it to call the methods. Would I be allowed to import FlickrFetcher into the second table View controller too or am I supposed to keep these controllers separate and only pass the needed information via segue?

In terms of what is allowed by the language, you can certainly have an instance of the FlickrFetcher class in your second table view controller, or when you segue you could pass the reference to the same instance of the class from your first view controller to your second. Otherwise, what would perhaps be better would be to pass only the specific information you need for the second view controller from FlickrFetcher via segue (this depends on how much you need in your second view controller). It's mostly up to you, but passing via segue might be more efficient, and make more sense semantically. Hope this answers your question

Related

Two views of one controller presenting the same data in different ways - possible using storyboard?

I have a controller that will send a set of data to the view. This set of data must be viewable in two different ways (no, this is not about landscape/portrait), thus two different views. My question is, how do I create these two views, linked to one controller, using storyboard? I want to be able to see and edit both views without doing any ugly tricks.
In my experience it gets a bit messy when trying to deal with different "main" views in the context of one controller no matter what you do.
Basically you need to create another view right on top of your UIViewController's view in storyboard and make it hidden, connect its outlets to the controller and when a button that flips your presentation styles gets hit you need to either show or hide your second representation view like this:
- (void)btnAction:(id)sender {
self.secondView.hidden = !self.secondView.hidden;
}

Using one storyboard definition for two view controllers

Is it possible to use one storyboard setup of a view controller with two view controllers?
Situation: I created one view controller's view in my storyboard. This one lets the user add a new data entry. Lets call it MyNewEntryViewController. This works fine. Now I need a way to edit my data entries. For that I'd just like to subclass my first view controller and adapt it where it needs to be. Lets call this one MyEditEntryViewController.
I would load MyNewEntryViewController using instantiateViewController… on my storyboard:
MyNewEntryViewController *newEntryViewController = [storyboard instantiateViewControllerWithIdentifier:#"NewEntryViewController"];
That works great.
What if I want to instantiate my new view controller now? Trying the obvious
MyEditEntryViewController *editEntryViewController = [storyboard instantiateViewControllerWithIdentifier:#"NewEntryViewController"];
results in an MyNewEntryViewController stored in my variable because that's what I had defined in that storyboard.
So, whats the best way to work with my storyboard definition and be able to use two different view controllers? How do you guys do this?
Thanks!
–f
No this is not possible. It is possible to do this with plain old xibs. You can then specify the name of the nib when you initWithNibNamed:bundle: the view controller.
However, I think it's worth taking a step back. Is it really a good idea to do this? Subclassing view controllers can get messy. View controllers are intended to be self contained units of functionality, which is at odds with subclassing. Unless a view controller is specifically designed to be subclassed then I would avoid doing so. I would suggest that you merge the two view controllers and override setEditing:animated:.

Is there a better way to load View Controllers from a table view?

This might be a very basic question, but I could not find the answer yet.
I have a UITableView that acts as a menu for my app. Each row on the table view, when selected, opens a different subclass of UIViewController.
At the moment my code works the same way used in the UICatlog example from Apple.
In the main view controller (the table view), each menu item is described in a dictionary in an array (menuList). Each dictionary contains an instance of the UIViewController subclass for that screen and other data about the menu item. When the user selects a row, the didSelectRow atIndexPath kicks in and calls the appropriate view controller, stored in the dictionary at that indexPath.row of the menuList array.
It seems to be very wasteful to alloc and init every single view controller when the table view first loads.
My question is: Is there a better way than the one demonstrated in UICatalog to alloc/init my view controller sublasses only when the associated row is tapped?
(I know I can use a complex if..else structure in the didSelectRow, but this results in an extremely long didSelectRow method and breaks encapsulation. I wonder if there is a cleaner way to do this, allocing and initing the appropriate view controller based on data from the dictionaries)
user1349768 try to use Storyboard, but this feature only works in iOs 4 and higher.
Just a suggestion ... put some reference to each view controller into NSArray and then initiate and segue to them when the row gets tapped on (and just get the reference from objectAtIndex:).
Although I could not find a better way to do this, the memory signature of each allocated View Controller is only 288 bytes. Since the solution suggested by apple is a lot more elegant and scalable then using a switch case statement, I left it as it is.

Retain View Controller when popped from Navigation Controller using ARC

I have two table views and a detail view being managed by a UINavigationController. When a row is selected on the second table, it pops to a detailed view allowing changes specific data represented by the row. I need to be able to switch between the UITableView and the UIViewController without losing any of the data that might have been changed in the UIViewControllers (button selections, text values entered in fields, etc).
Basically, once the UIViewController is presented, one should be able to switch back and forth between the table and detail view without losing any data.
The problem is, when a UIViewController is popped from the navigation controller, that memory is automatically released, and since I'm using ARC, I can't just keep a pointer to that with a retain command in the UITableView.
I know that I could manually rebuild the view each time its corresponding table row is selected, but I feel that might be a messy solution. Another option I've thought of is keeping an array of pushed UIViewControllers and checking if the selected table row corresponds with an existing value before a new one is created, but that might also get messy.
Any suggestions?
Your final wish in this back and forth of view is what you stated in your question: you want to switch between view controllers without losing any information of the actions performed in these controllers.
But if you think at how MVC pattern works, you should consider a view controller as the glue logic between the view and the model. The view is not persistent, that's why it is legitimate for ARC to get rid of the owning view controller when the view is no more needed. Instead what you should persist while your app is working is the model data only: the model data will be shared between the involved view controllers, the view controllers will be recreated each time and the corresponding views will be updated based on the model data. The only reason why the view controller should be kept alive is when its alloc-init-loadView takes too much (e.g.: the view is OpenGL backed) but in such case I would suggest you to keep a strong reference to it in the AppDelegate and ask it to refresh the content when the model data is replaced.
So basically what you should do is:
- select the table
- extract the model data associated to the table, including all information relevant for the view controller
- push the view controller; save all view modifications to the model
- when the view controller is popped, the model data will be returned only
- next time, when you push the view controller again, you will restore the model and re-init the view controller.
This approach is not complicated and gives you the possibility to structure the app in a clean way. Tomorrow you can change your view controller structure (that its view and the logic) without any impact in the communication with the other view controllers as this managed by the model passing only.
There are a couple of solutions to this, just like you suggested.
The array solution is highly inefficient because of memory issues.
The second solution you proposed is a lot more elegant. Just write your own init method in that view controller and init the view controller with data from a plist file
If I'm reading the question correctly, you've got a tableView and a detailView that are driven by the same model data. When changes to the model data are made in the detail view, you want those changes to persist.
If you update the model based on the state of the controls when the detail view is popped, then those changes will persist and the changes will be visible the next time you drill back down into the detail view.
You don't mention what form the table data takes, but let's assume it's an NSArray of NSMutableDictionaries. When you tap the row, the didSelectRowAtIndexPath: method will need to hand the dictionary from that array index to the detail view controller through a property on the detail controller. The detail view controller will update the dictionary values in the method that dismisses it.
The way to think of this is using the model-view-controller pattern. The table and detail view data is stored in the model; the views present the data; and the controllers are responsible for updating the model and navigating between views.

Can we create an IBOutlet to a View Controller

I have a viewController. That viewController have a containerView that contain another controller. List and map.
I want users to be able to switch between list and map via a button.
So that means the parent view controller (or somebody) need to be able to refer to both the mapViewController and ListViewController.
How can I achieve that?
One way to do so is by using instantiateViewControllerWithIdentifier. However, I do not like identifier. Identifier is prone to mistyping and conflicts. I like Outlet
I read that one possible way to do so is to set a storyboardid. What about if I like the good old outlet?
As I understand it, you have to sub view controllers. What I would do is create a master controller class, which imports all of the other view controllers (think of it as the super class of the entire project) which will then control a empty view, less a button. The background of the empty view will be fed by an "active" view, which will be supplied by either listViewController.h or mapViewController.h This will let the users use both the list/map VC's, and be able to switch between the two.