Need clarification regarding MVC design pattern - ios

I have a reusable UIView with its own .xib file. This UIView would be added to different UIViewControllers as subviews. In the MVC design pattern, my reusable UIView should contain only code for the user interface(UILabels, UIButons, etc..). What I'm confused about is setting up the UILabels and UIButtons. Is the ViewController that contains my UIView responsible for setting up my UIView's UIButton click events and what my UILabel displays? The problem I'm having now is that I have multiple UIViewControllers that reuse the same UIView, but they all implement the same code that sets up my UIView. This end up with lots of duplicate code across my UIViewControllers. If I move the setup code to my UIView to reduce the duplicate code, doesn't that violate the MVC design pattern? Is there a way to create a "Controller" thats only responsible for setting up my UIView so I could reuse my UIView and Controller inside my UIViewControllers?

Assuming that by setup you mean instructing the UIView on how to draw itself based on some object, this is exactly what the drawRect method is for. UIView also provides an initWithFrame method and you can even create your own initializer if you want. One more option is to create a function in your UIView subclass that will take what ever info you are displaying and will setup the view way you want. Something like: setupCustomViewWithMyObject(object).
All this to say that your setup code should be in your UIView subclass and you are not violating anything.

Related

How to draw using Quartz 2D to my ViewController

This is sort of a beginner-level question. I have inherited an iOS project and it is implemented with a few ViewControllers with associated XIB files. The XIB files contain various widgets that are controlled by code in the ViewControllers (which I think is the standard way of constructing an app).
However, I need to do some custom drawing (rectangles, lines, circles, text) in between the widgets, and I'd like to use the Quartz 2D library to do this. I've never used Quartz2D, and most of the sample code I find is centered around the View, not the ViewController.
Most of it seems to do with implementing the "drawRect" method of your View. However, my ViewController does not have a "drawRect" function, as far as I can tell. Is there a way I can implement a "drawRect" function on my ViewController or whatever View it is controlling?
*** addendum:
I have researched and reminded myself that the operational UIView is a property of the UIViewController, and it seems like UIView is created automatically by the application and bundled together with my XIB and ViewController (I think we selected "also create XIB" when we were creating a ViewController, so the UIView is implied?). I don't see where this default UIView instantiation occurs. But I assume the way to draw to it is to subclass it?
If so, what is the cleanest way to subclass this UIView and get access to drawRect while maintaining the connection to the existing ViewController and XIB (or storyboard)? I inherited the project and this change needs to be low-impact.
Thanks for any help/thoughts.
Make a subclass of UIView and override -drawRect: to do your custom drawing. In the xib, select the view of your view controller, go to the Identity Inspector (third tab in the right sidebar in Xcode), and replace UIView with your custom subclass.

Adding UIButton and UITextField directly in UIWindow or adding in a UIView

I would like to understand a simple concept. I'm going to build a simple UI made up of a UITableView, an UIButton and UITextField objects. I add UITableView to UIWindow. Now I ask you which is the best way to add the others to object, wrapping into a UIView or inside an UIWindow. Which could be the advantages or disadvantages of both the approaches?
First of all, you will most likely want to use a UIViewController or UITableViewController which you then set as your window's rootViewController, and never actually add views to the window directly.
The other views you need should then be added to the view controller's managed view.
The main disadvantages of adding directly to window is that you do not get support for multiple interface orientations.

Modify and redraw another UIView from the UIViewController

I have a flow issue in my iOS app from my subclassed UIView to its parent UIViewController.
Basically, I have a nib called preferences. It contains two sliders, two labels, and another UIView that will display a shape dictated by the two scroll bars (Stroke and opacity). I successfully painted the subclassed ui to the screen by setting the custom class of the UIView to a separate UIView we'll call subView. I have setters/getters for the scroll bars and they print out their values. How do i let the uiview class (pointed at the ui nib object) to update and redraw since it isn't referenced in the parent preferences class? I tried syntax like this:
[code]
IBOutlet SubClassUIView *subclassUI
[/code]
to no effect. It seems best to point a custom class at the UIView.
Any suggestions and advice would be much appreciated.
TL;DR can't modify subclassed uiview from "parent" uiviewcontroller
Sorry folks, i figured it out.
In addition to passing in a custom class that shares the same type as the IBOutlet (such as a UIView),
there MUST be a link referencing every object in in the .xib to its parent. In this case, the parent UIViewController needed a reference from the custom class ui to a IBOutlet UI. From there, some simple casting from generic and boring UIView to the custom class's unique methods makes for a complete flow.

Intercepting didAddSubview

I hope this is a simple question. I need to intercept didAddSubview, but will I need to subclass the UIView in order to override that method?
The UIView that I want to override is the UIViewController's view property, so I just want to know how to go about working with this.
Thanks!
From Apple UIView documentation (see Methods to Override):
When subclassing UIView, there are only a handful of methods you
should override and many methods that you might override depending on
your needs. Because UIView is a highly configurable class, there are
also many ways to implement sophisticated view behaviors without
overriding custom methods, which are discussed in the Alternatives to
Subclassing section. In the meantime, the following list includes
the methods you might consider overriding in your UIView subclasses:
...
didAddSubview:, willRemoveSubview: - Implement these methods as needed to track the additions and removals of subviews.
...
So, create your UIView subclass and override the method. Then, say to your UIViewController that its view will be the one you have subclassed. To achieve this there are a couple of ways:
by Xib
implementing loadView method and set the view property to be your custom view
redifining the view property in viewDidLoad
Hope that helps.

To subclass or not to subclass : that is the ...?

I am building an app with many views and subviews.
I am trying to figure out how to approach creation of the subclass.
one simple example:
I have a table view with heads view and footer view. (I have much more complex views then this one, but I am trying to explain my point with a simple one).
In the beginning I didn't want to create views subclasses for every view, but I found that my code is getting complex and hard to navigate in.
Then I found my self creating a view for every subview in the main view. The truth is that I like it better cause my code is clearer to me. Th only thing is that I don't know what are to cons and pros of each approach.
How do you decide when to create a custom view or create it's code in the main view?
Thanks
I usually create a UIView subclass only when there is specific functionality that would be best done in such a class. This might be that the view is a control such as a keyboard to enter a value or a UITableViewCell subclass.
Otherwise I would generally not subclass UIView but just create the view hierarchy in Interface Builder or in code and then use the UIViewController subclass to do all the business logic.
Basically, in general with iOS programming, you want to have all the logic of how a "view" (or screen, or whatever you want to call it) in a UIViewController subclass. It's hard though to really give good advice without fully understanding your hierarchy.

Resources