I am trying to switch an existing NSView with a new view loaded from nib file. I see there are two approaches to this
Remove my subview from super view and add the new subview to the super view.
[NSView]RemoveFromSuperView and
[NSView]AddSubView
Replace my existing subview with the new subview using this call
[NSView] ReplaceSubviewWith(NSView, NSView)
Are these both calls the same ? Is there any significant advantage or difference in using one over the other ?
If you are really swapping out one view for another use replaceSubview:with:; after all, that's the exact job it was designed for! It's useful if you want the replacement view to be in the same place as the old view, and it's probably optimized a bit more for the subview replacement use case (I doubt that makes a huge difference though).
Related
I've been trying to figure out what can go wrong when using UIViews instead of UIViewControllers and haven't been able to find any therefore I've been just using custom UIViews when generally UIViewController is recommended for some reason.
I prefer UIViews mainly because when custom animating for transitions they're easier to manipulate as far as I know. Correct me if I'm wrong.
Also, I customize everything on my own programmatically such as tab bar, navigation bar etc hence to me, a custom UIView does everything a UIViewController does..
So, is using a separate custom UIView instead of a new UIViewController problematic? If so, please enlighten me..!
Edit
I am aware of MVC model and by UIViews instead of UIViewControllers I mean ignoring the whole one UIViewController per screen thing and use UIView as a container for all objects for certain screens.
For example, when showing menu screen, instead of pulling a UIViewController up for its own "section", I just don't do UIViewController at all and do it with a custom UIView which works as a container, draw/add everything in there. The same goes for the rest of "sections".(settings, option etc etc)
Is this problematic?
I've been trying to figure out what can go wrong when using UIViews instead of UIViewControllers
You cannot do it generally, because view objects and view controller objects occupy different places in the Model-View-Controller hierarchy. They are not even one-to-one with each other, because a single controller often manages multiple views.
I prefer UIViews mainly because when custom animating for transitions they're easier to manipulate as far as I know.
In situations when a piece of functionality can reasonably go in either a view or in a view controller, it most likely belongs in the view, not in the view controller, so your observation is correct. Custom animation that can be encapsulated in a single UIView should be encapsulated in the UIView, even though the same code could go in a UIViewController as well.
I am making an app that has about 20 different view controllers that are loaded into a single container view. Some of the views have sliders and buttons and some have only buttons.
Is there a strategy I can use to make building the views controllers more inline with Objective C coding techniques?
Currently I am trying to combine similar methods into model objects but before I get too involved I thought I'd ask if there is a better way. I'm also willing to do the groundwork and research so any keywords to point me in the right direction would help, i.e. protocols, delegates, etc.
The main piece of advice I'd give you is to consider whether or not each one of those view objects needs to be controlled at all. Consider UIViewController like the delegate between the view and the model. If you don't need an extreme context switch (i.e. pushing a new view onto the navigation stack), then is it really advisable to have 20 delegates floating around? In most cases, not really. UIViewController is not a "heavy object" by any stretch of the imagination, but it can quickly make your codebase unwieldy and large if every time you decide to throw a new component onto the screen, you subclass UIViewController.
Try to focus your attention on dividing the logic to setup the view and the actual responsibilities of the controller (reacting to model changes, dispatching operations, updating the view) into a UIView subclass and a UIViewController subclass respectively. If you truly do need to keep some component of the view separate because its logic simply cannot fit under the main view controller's category of responsibilities, then, and only then, is a new view controller appropriate.
Just a concept question.
What would you prefer doing and why, should you need to insert into a view a subview, would you rather have a nib file to add it or would you programatically insert it?
I am talking about xcode 4.~ development using storyboards.
Regards, Guy.
That depends on your situation. If it's something very simple or something dynamic (variable number of buttons for example) then I would do it programmatically. If it's a complex but static view (something like a settings view) then I would try using IB.
I personally will do it programmatically if i need the view to be dynamic. But it can be done even with the view created in the xib file. I would prefer creating in xib if the the view needs no dynamism so that it would reduce my coding portion
XCode 4.2 (the only version of XCode I've ever used) creates a ViewController with a default View property.
I cannot see the code for this default View so I cannot draw on it (because I cannot access drawRect). Is that correct?
Assuming answer to the above is that I cannot draw. If I want to draw on the window should I:
Add a subview to the default View and then draw (via drawRect) on the subview? or
Replace the default View with one that I create and can therefore draw on via drawRect?
This is not a question of how to do this, I want to know what would be the best way. Thanks.
If you need to do custom drawing in you view, then you should define your own custom UIView class, where you override drawRect to do the custom drawing.
Now, wether you follow either approach 1. or 2. depends on what your app does. Both are perfectly reasonable.
Say, for example, that you would like to do your custom drawing, but also show some kind of controls (e.g. to clear the drawing, to reset it, and so on), then I think it could be a better design if you have a root view that you add both the custom view and the other view to as subviews. But this is just an example and it depends on what you are trying to accomplish.
Hope this helps a bit...
I want the effect of a UISplitViewController however I am not using the split view template.
Is it relatively easy to achieve without the template? And with using normal UIViewController?
What I want it a customary sized and positioned UITableView which then has a customary sized detail view which then of course goes into a popover and detail view when portrait.
Doing it without Interface Builder, you would create a UIViewController class. In the viewDidLoad method of that class, create a UIView or a UITableView with the frame origin where you want it and a size that you want. (Release it in the viewDidUnload method.) Then set the UIViewController's self.view to point to this new view.
self.view = [[UIView alloc] initWithFrame:...]; // edit - added in response to your question
If you created a UIView, then you will want to put your UITableView inside this new view. (This approach lets you add more items to the container UIView if you need to.)
Make sure your UIViewController adheres to the UITableViewDelegate and UITableViewDataSource protocols. Add the delegate and datasource methods and you should be good to go.
This new view can cover other views, or you can size the other views to fit beside it. You only need to set there frames according to what you want to do with them.
There are some limitations if you use a UITableViewController, so a lot of people recommend using a UIViewController instead. like I described above. You can google for more info on that topic.
Just great a new temporary Xcode-project from that template and judge yourself, if it is complicated for you, to adept your (real) code.
Yes. You can do it quite easily. Just use delegates to pass messages between the left and the right side views (root and detail). For instance the didSelectRowAtIndexPath tableView method could be used along with delegation to pass a message to the right sided detail view. Tap a cell on the left table, show its text as a Label on the right side. Its just a simple example. And yes you can handle the rotations and send left side view into a UIPopoverController as well, thus giving the detail view full screen real estate in Portrait orientation.
Also try MGSplitViewController . It gives you a lot of other customization options on a split view controller.