This is a question regarding iPhone objective C design. How can I have 2 UIViewControllers manage the same view? Each UIViewController will be created at different times, but their views are essentially the same thing.
To help explain, here's an example:
Let's say I have one ViewController that synchronizes a list of tasks from the server, allows the user to edit/delete these tasks, and displays other information on the view (like status messages), etc. At a separate time, I want to show a "read-only" list of those tasks using the same view (since the view has already been created, tableView is created, status message textbox is there etc.), but based on different things, I want this view to act differently and update different status messages.
So in this example, I want to reuse the view but use 2 different controllers depending on where the user is. If he/she is in edit mode, display UIViewController 1 which manipulates VIEW 1. If he/she is in read mode, display UIViewController 2 which manipulates VIEW 1.
I'm wondering the best way to design this if this is 1. possible or 2. should I just duplicate VIEW 1 as VIEW 2 and have UIViewController 2 manage VIEW 2, even though they'd be the exact same.
Thanks in advance for your help.
Create a base UIViewController class that each of yours descend from. Put all of the common interface element declarations (either plain ivars or IBOutlets) in the base class. If you use InterfaceBuilder then make the files owner the base class.
Related
I have a simple project that was started from a Master/Detail template for iOS7.
I'd like to layout the detail view controller just like iOS settings. Do folks recommend using a table for that or just laying out the controls one by one?
Here is a screenshot of the effect I am looking for:
This is probably a matter of taste/opinion but I prefer tables for this kind of thing for these reasons:
You get all the nice features of tables right out of the box (efficient scrolling, cell reuse and delegate methods to handle where to push new view controllers on to the stack, etc...).
Flexible data model backed cell data. Your table view needs to be backed by some "settings" model object collection, obviously. That collection can be modified to include or exclude settings programmatically. Combine this with custom cells and you're off and rolling. This is really nice if your UI needs to change on the fly.
Code Reuse. If you have another set of "settings" you can use this data-backed table view approach and change only your data model. Doing this manually means you have a new view controller for every settings view. In your example picture, I'd bet my lunch that the 3 view controllers you see in that image are the same type of object.
The table's delegate methods are really helpful when segueing or pushing to new view controllers. Imagine having 10 settings that all took you to separate view controllers. You'd have to manually hook those transitions one by one, yuck.
Of course if you only have 1-2 settings that will never change, perhaps manual is the way to go. For my money, though, tables make sense because things like this always seem to change.
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;
}
I have one NSTableView nib that contains a number of cells that will be reused throughout 3 different NSViewControllers. The NSTableView and cells function in the same way and look similar but present different data in each of the different views.
Right now I can set the File's Owner to one of the NSViewController classes, but not all of them meaning I'd have to duplicate the nib 3 times. Given that I'm loading with initWithNibName:bundle I don't see any way to set the File's Owner first either.
How can I use one nib with multiple File's Owner for NSViewControllers?
Any ideas?
Have you tried simply NSViewController or a subclass of it that is an abstract superclass of your view controllers?
One subclass could even be sufficient if the differences between your instances can be managed with conditional logic in the subclass.
Either way, it sounds like you have some refactoring to do, but minimal.
I am an iOS developer not OSX but we also face this problem. In our case I would have used a UIView class(surely you will have NSView kind of class) and then added table on that class and made File's Owner of the table to that view class.
I can reuse this class whenever I want in any view controller by adding this view on that controller and changing its data set.
I have two view controllers which should work like described below:
First view controller displays a view which has a table in it. The table contains data which is constantly changing. I have a delegate method for reloading the data when a change occurs. So that is taken care of. When the user selects a row in the table I would like to display a second view which would also contain live data in text format (one UITextView which would constantly change).
I would like to allow the user to access view 1 while view 2 would still be monitoring and displaying live data and vice versa. While user is on view 2, view 1 should still be monitoring and displaying any changes in the table content.
I guess its like having two view controllers present at the same time and switching between them.
What is the easiest or the most standard way to accomplish this? I dont mind if its all done programatically.
It's a little hard to tell what you're asking here. First, views shouldn't be processing data at all -- they should only be displaying it. It sounds like what you're describing is having a background process that updates to your second view. That process could certainly be running while your table is on screen, and when you switch to the second view, you can update it using this running process. Exactly how you would do this depends on the details of what you're trying to do. So, I think we could help you better if you provide more context on what kind of process you want going on that updates your second view, and how choosing a row in your table affects that process.
After Edit:
You can certainly do what you want to do. I think the main thing is that you need to have a property (typed strong) in your first view controller that points to your second view controller, so that when you go back to the second controller a second time, it goes back to the same instance. Based on the selection from the table, you can start whatever process you need to populate your text view, and that process can keep running even after you go back to the table view, since that controller won't get deallocated when it's view goes off screen (due to the strong reference you have). You would just have to have some sort of if clause in your second view controller to know whether the user has selected the same row again, and if so, just show the updated text view, rather than starting a new process.
That's about as specific as I can be without more detail from you.
what you have is a problem where you need a custom parentviewcontroller
look into splitviews as one example :: SplitView like Facebook app on iPhone
cool intros of how to do custom container view controllers :: Container View Controller Examples
I am new to Objective-c, I want to ask what is the different between view controller and view such as "UITableView" and "UITableViewController"?
What happen if I use UITableView instead of UITableViewController?
Thanks
You should look up the Model-View-Controller pattern in the Apple's documentation, since it is very important for using Cocoa. Basically, the idea in Model-View-Controller is a pattern for designing your class structure. Broadly, the model is where the application's data should be kept. The view is what controls the application's appearance and the controller is the place where the two are assembled. (Ideally, the view and the model classes do not even need to know about the other's existence).
Hence, the UITableView and UITableViewController are two different classes with two different purposes. The UITableView controls the appearance of the data and the UITableViewController "controls" the view (generally by passing it the correct data for display and layout). Since this pattern shows up again and again in Cocoa programming, you should take some time to become familiar with it.
They are two different things, they cannot be substituted for the other.
iOS follows the MVC design pattern, which stands for Model-View-Controller. The two classes you mention are 2 pieces of the overall puzzle.
The View is what gets displayed on the screen. That is its responsibility. So, the TableView is responsible for telling the phone what to render on the screen.
The View is also accompanied by the Controller. The controller decides what to do when something happens (user interaction, and other events that can happen at any time). So, the TableViewController is responsible for making the table do stuff (for example, telling the TableView what data to use for displaying on the screen).
So to sum it up, they are completely different, but they work very closely together in your application (you will almost always have 1 Controller for each View.
Well, the short answer is that one is the View and one is the Controller. Combine this with your data (the Model) and you have all the parts of MVC (Model - View - Controller).
Think of it this way, the UITableViewController controls the UITableview. They are complementary and they need each other to work.