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.
Related
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 just started playing with the UISplitViewController - I've cobbled together some code from various tutorials, but I'm having trouble seeing how to send data from the Master to the Detail. I'm creating an RSS reader just to illustrate to myself how it should work. I've parsed an RSS feed and populated the MasterViewController with a UITableView, but I'm stuck figuring out how to take a row click and load the corresponding article in a UIWebView in the detailViewController. Any tips are appreciated.
A good approach is to use delegates. That allows one view to call a callback provide by the other. In this case the detail view relies on the master existing so having it callback is fine. I would avoid letting them have direct references to each other and reading each others data directly.
What exactly does delegate do in xcode ios project?
Here's a tutorial with UISplitViewController that does just that (delegate between master/detail):
http://www.raywenderlich.com/1040/ipad-for-iphone-developers-101-uisplitview-tutorial
Specifically this section:
Hooking Up The Left With the Right
Time to play matchmaker and hook
these two sides together.
There are many different strategies for how
to best accomplish this. In the Split View Application template they
give the left view controller a pointer to the right view controller,
and the left view controller sets a property on the right view
controller when a row gets selected. The right view controller
overrides the property to update the view when the property is
updated. That works fine, but we’re going to follow the approach
suggested in the UISplitViewController class reference here – use
delegates. The basic idea is we’re going to define a protocol with a
single method – “selectedBotChanged.” Our right hand side will
implement this method, and our left hand side will accept a delegate
of somebody who wants to know about this.
Another approach would be to have a shared model - sort of like a singleton with notifications to trigger different views to update themselves based on either the data from the notification or querying the model in reaction to a model changes. This is sometimes better in an app with many views that don't rely on each other and just bubble up data in various ways (which is not the case here - the detail view relies on the master existing so a delegate is fine).
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.
I'm just getting into desktop Cocoa development (I have experience with iOS development). If this question seems basic, forgive me.
That being said, I'm dealing with a large program with lots of calculations and functionality to deal with. There are almost a dozen views, organized with an NSTabView. Rather than dumping everything into one monstrosity of a class and creating a XIB file that brings my system to its knees (Xcode apparently isn't that efficient…who knew? :P). I'd like for each tab to be its own NSViewController with accompanying XIB; as such, I'd like to load each tab's view from the corresponding XIB.
I'm thinking of this in terms of UITabBarController, but this doesn't seem to work (there isn't an NSTabViewController as far as I could find). I'm not sure how to do this (or even if it's possible—but I can't be the only one with this issue?), and I'd appreciate any assistance. Thanks!
Update: I tried assigning the controller's view to the tab's view, but quickly realized that wouldn't get me anywhere. Is it worth creating an NSTabViewController from scratch, or is there a solution out there?
Cocoa development on the desktop has some major differences compared to iOS development. One of them is the use of view controllers - they aren't strictly necessary - and when you use them you can just stick to a generic NSViewController regardless of what kind of view it contains. All of the methods you need to control the tab view are in the NSTabView class - not the controller.
Having said that, putting 12 views in to a tabview sounds like a painful way to interact with a program. Have you thought about a source-detail type setup (think itunes or mail with their sidebars - each entry in the sidebar corresponds to a different view)?
I've ditched the tab bar, and as per sosborn's suggestion, I have used a split view—or rather I've put a table view on the side, and a custom view taking up most of the screen. Then, in my AppDelegate, I have individual controllers as ivars (I need individual controllers because there are a lot of calculations involved, and I don't want to have a monster class handling them all). They'll be lazily loaded, and the view will be assigned to the current controller's view as necessary.
I am making a UIView-based class for use as a tableHeaderView. It will have several controls that will be based on edit mode - some will appear/disappear and some will change appearance when it switches modes. The height of the view itself will change when it switches modes. Seeing that the layout will change a lot, I decided it would be better to just make the whole thing programmatically than to try to lay it out in a nib.
What I am struggling with is where the view/controller separation should be. Should the viewcontroller have an object for each control (UITextField, UISegmentedControl, UIButton, etc) or should it just have an instance of my UIView-based class?
Where should the code that actually creates the controls and sets the properties reside? Should my view have a method that gets called to set the entire view (based on edit mode) or does this put too much power in the view that should be in the controller? Should the view only set the positions of the controls? Or should there not even be a UIView-based class - the view controller will declare and configure all the controls by itself?
What is the proper MVC separation here?
jorj
The MVC rule of thumb is that your controller is the go-between – if your model is storing information about the edit mode, then your code will be cleaner if the controller does the work. If the edit mode settings are discarded when the view goes away, then the controller doesn't need to know about them.
It's also worth considering whether this code will be re-used – if you're creating a view that you're going to use again elsewhere, that may make it easier to decide where the "brains" of the code should reside.