Across my app I have several different subclasses of UIView: UIDatePicker, UIPicker, UIButton, UITableView, UITableViewCell, UITextView, etc. etc... For each of these I'd like to add a very simple drawRect custom implementation that I have working great.
Is there a simple way to get multiple subclasses of UIView to all have the same drawRect implementation without creating a subclass and repeating the same code across each UIPicker, UIButton, etc. etc... ?
I realize the solution to this is probably to write a delegate class for UIView's layer property and do the custom drawing in drawLayer, but I thought I would ask before I go re-working my code.
The answer seems to be no.
Furthermore, it appears that my idea for the workaround also doesn't work: I was thinking I could write a nice little class that implements the drawLayer method from CALayerDelegate and do the drawing in there, and then in each UIView or UIView subclass' init method do a self.layer.delegate = niceLittleCALayerDelegateClass.
My research, however, happened upon this: https://developer.apple.com/library/ios/documentation/GraphicsImaging/Reference/CALayer_class/#//apple_ref/occ/instp/CALayer/delegate which contains the damning sentence: In iOS, if the layer is associated with a UIView object, this property must be set to the view that owns the layer.
So, double nope.
Against rmaddy's advice I'm going to just write a subclass for each of the UIView subclasses I want to implement this drawing behavior in. We'll see how that goes.
Update:
I can't believe I didn't think of this before, but the "right" way to do this (that is to say without subclassing UIView's subclasses and adding a custom drawRect method to each subclass's subclass), from everything I can find, seems to be to either create a subview or a sublayer with a transparent background that does whatever custom drawing you want.
Obviously this is going to draw on top of the UIView you're actually using, so this would get exceedingly complicated if you're trying to draw things that interact with the default elements of the UIView, but for my purposes (just a simple frame drawn with a UIBezierPath) it seems to work great.
At present I'm not sure if the subview or the sublayer approach is more efficient. If anyone can shed light on that, I'd appreciate it.
Related
i'm very new to xcode. i've googled this and even serched here and i didn't find exactly what i was looking for. i really wanna get this. especially since it's the most basic thing there is.
so, i have the .h and .m files
i want to DRAG a uiview into the .xib file, i don't want it to be as big as the screen, so i resize it.
now i want to draw a bunch of rectangles INSIDE this view object.
how do i go about doing this?
your help would be greatly appreciated!
So you add a generic UIView then create a subclass of UIView and do your drawing inside the drawRect method.
Then change the class of the UIView to your subclass name in the inspector.
Be sure to #include your header in the app delegate.
That's the basic thing.
For more sophistication, you're going to want to learn to use UIViewController subclasses as well. These are used all over ios.
I'm trying to refactor my code in the best possible way and I'm wondering what the proper architecture for the given situation is.
What I'm Trying To Do
What I'm doing is pretty simple: I have some custom CALayer subclasses that represent an interactive UI element. They are broken up into multiple layers since some of the parts of the UI are static, so I didn't want to redraw those static elements needlessly. Right now, the layers are added as sublayers in the initialization part of a CustomView class that is a subclass of UIView.
There is currently no corresponding CustomViewController class that is a subclass of UIViewController because when I'm using the CustomView, it's contained within a UITableViewCell or a part of a generic UIViewController with other views in it, so I felt another UIViewController for each CustomView instance would be redundant.
Also of importance is the that the only operation that I'm doing inside of the UIView class is I'm responding to touch events and sending the touch information to the sublayers so that the UI can update its appearance accordingly. I'm not overriding the drawRect method or anything like that.
The Question
Basically, I'm trying to figure out whether I should either:
Option 1:
Get rid of the CustomView class, create a CustomViewController class that is a subclass of UIViewController, and simply add the CALayer objects as sublayers of the CustomViewController's built-in view property.
or
Option 2:
My thinking about the UIViewController subclass being redundant is correct, so I should leave it the way I have it and have a CustomView class with the CALayer objects inside of it.
I would highly appreciate any advice on this.
I think that in terms of MVC, the code you're describing (option #2) is well written and maintains a very clear boundary of responsibility. You're not writing any code that has nothing to do with the view layer itself in this class which is great. I think that in this case there's no need for a separate UIViewController subclass to manage these instances because as you said - they are handling their own touch events and visible layers (exactly their responsibility).
If for any reason there is a need for something more complex that requires data related logic or other such computation, I would definitely consider subclassing a UIViewController or maybe looking at the problem in an entirely different way.
Given the situation you've presented, I think that maintaining the CALayer instance within this UIView subclass ('CustomView') is the right way to go.
I saw this question here (How to create popover in iPhone app?), and wanted to design a class that could create a popover object, I find all the libraries for popovers right now aren't doing quite what I'd like to do.
So I figure I'll create my own, but I'm a little new at it. Do I subclass UIView directly? Could anyone point me in the right direction for this task?
Subclass UIView. Implement the layerClass class method of your custom UIView subclass and return [CAShapeLayer class] (from the QuartzCore framework), or use your own subclass of CAShapeLayer instead of CAShapeLayer itself. In your UIView subclass' implementation of initWithFrame: you can set the view's layer's path to get the popover shape you want to display.
Creating a popover by subclassing is one of the way to achieve your goal, even its a simple matter of doing google as there are may solutions on StackOverflow about the same.
Take a look at this answer This will help you to proceed.
I am just starting out with iOS app development and it's been a great experience so far. Apple documentation is great, but there are some questions I have that are not as technical and only someone with experience might be able to answer.
I have a bunch of UIViewController which handle the "dynamic skinning" of the custom UIViews that they control. This leads to a controller with big chunks of code which seems a bit unpractical to me.
So the question is: Following the MVC pattern, should I give the responsibility of setting a UIFont, UIColor, etc to the view itself? Or should I create "micro" controllers that handle this task using some kind of input?
Thanks for the response.
Creating UIView subclasses that handle the layout works. Override layoutSubviews in the UIView subclass to do the positioning layout (setting frames etc). I find the init method to be a good place to set fonts, colors etc.
Now the UIViewController has relatively little code related to the custom UIView. The viewController just needs to position an instance of the custom UIView and perhaps set a few properties (like a textLabel's text).
If I'm creating a UIView programmatically and I wish to change the UIView properties (background, for example, or actually, messing with CALayers), must I place the code outside of UIView such as in the View controller? Can I put the code somewhere inside UIView?
I was checking out the CoreAnimationKioskStyleMenu example, its code is inside UIView but it's loaded from Nib and can be placed at awakeFromNib, so it doesn't seem to apply to my case.
That depends. Obviously, a good way to handle this is to use a xib file, as it is designed to hold data like this, but that isn't always the best answer for every situation.
If the view is meant to be reused frequently (like a button, or some widget) throughout the application, its best to store all that customization in a subclass of the UIView.
If its a single larger view that will always be managed by a UIViewController, you can keep some of the information in the UIViewController. However, if you end up subclassing a UIView anyway it's probably best practice to keep the data in the UIView.
As a general note, I believe its worth your time to push as much of this data into a xib using interface builder. Magic values (like colors or sizes) peppered through your code will always be a problem if you want to modify it. I have found modifying a xib to be much easier.
Actually there are some methods where you could place initialization/ customization code.
(void)willMoveToSuperview:(UIView *)newSuperview;
(void)didMoveToSuperview;
will get called as soon as u add the view as a subview to another view, at which point you already have the frame and all the properties, and you can do further customizing as you wish.
(void)layoutSubviews -- generally used for changing subviews' frames and layout organization.
Will get called each time the view needs to be redrawn by the system, or when you specifically call [self setNeedsLayout] on your UIView.
Hope this helps.