I have some custom drawing code in drawRect which also performs some calculation of sizes.
When is the earliest I can be sure that this code has been loaded, e.g. if I want to modify it's containers size accordingly?
-[NSView viewWillDraw] is a reasonable place for last minute layout.
I have some custom drawing code in drawRect which also performs some calculation of sizes.
When is the earliest I can be sure that this code has been loaded, e.g. if I want to modify it's containers size accordingly?
An object can't exist until its class is fully loaded. If you have an instance, the class that it's an instance of is completely loaded, because you wouldn't have an instance of it if it wasn't.
As for when it's called: It's called when you need to draw. This normally happens as part of the event loop, if anything has marked the view as needing display. It is possible to directly tell an NSView to display, but, as far as I can tell, this is not possible for UIViews.
So, if you need to do something to it before it gets told to, either do it immediately after creating it or, if you're about to set the view as needing display, do it before you do that.
Just before the view is displayed or when you call
[aView setNeedsDisplay];
I just created my first customView app. This was one of my questions. my drawRect method was called once upon creating my window (or recreating). And millions of time when resizing my window.
Related
This question seems to get asked a lot but I have never found a definitive answer as to whether or not it's possible to have custom transitions the same way UIKit does.
I know you can do tricks like take a screenshot of the current view and the upcoming view, and then animate those while you change view controllers under the animation. However, this takes quite a bit of memory, as you have basically 2 full extra screens worth of drawing (because of the screenshots).
I'm looking for a more elegant way of presenting view controllers with a custom animation. Or, is there a more memory-efficient way of doing the above approach?
There are several ways to accomplish this, depending on how you want to transition, whether your controllers are embedded in a container controller, etc. In the simplest case, where you have a single controller, and you want to transition to another controller, you can do it with the following steps:
instantiate the new controller (lets call it B, and the original one A)
add B's view as a subview of the window (gotten from self.view.window)
set B's frame to be off screen in which ever direction you want or make its alpha 0, or make it have zero size, depending on what kind of transition you want.
do what ever transition you want with animateWithDuration:animations:completion:
remove A's view (in the completion block)
in the completion block, make B the root view controller of the window
Essentially you're having the system automatically retain and release, along with do whatever is happening below the calls rdelmar's answer outlined. Transitioning a view controller is just animating a view while having the system keep your controller in memory.
But, to answer more of your questions, UIView animations create duplicates and cache the images, too. (Btw, the system cache doesn't unload its memory, so avoid UIImage imageNamed.
You will probably want to code it yourself using a timer if you want efficiency, and drum up all the graphics tricks you can think of.
And never, ever trust iOS to work the same way it did the last version. Everything I said is subject to being wrong the same way iOS 6 broke retain on annotating, and the manuals stated iOS 3 animations will become obsolete (and are now replaced instead?) gah, just saying be careful with efficiency, it may be broken or updated in the somewhat distant future if you try it.
I am using the AFOpenFlow library to generate a coverflow-like effect, but trying to add arbitrary UIViews to an AFOpenflowView, not just images. I am doing this by creating a subclass of of AFItemView, lets call it NewAFItemView, which represents the view I want to add. I also extended AFOpenFlowView, call it NewAFOpenFlowView and overrode the method
-(AFItemView *)coverForIndex:(int)coverIndex;
In the overridden method, I allocate an NewAFItemView object and return it as the cover view for that index. The NewAFItemView views appear correctly in the open flow but scrolling is immediately disabled. Switching back to allocating AFItemViews works but using NewAFItemViews does not scroll.
I have not overridden any of the touch events.
Any ideas on what might be happening?
Cheers.
why don´t you use iCarousel?
https://github.com/nicklockwood/iCarousel
i use this, and it works perfect for uiviews =).
I've understood that I need to subclass a UIView t be able to draw inside it.
The thing I don't understand yet, is the philosophy of the way i must be done...
Let's say I have a view controller, and depending on context, I may want to draw a line into one of the subviews it manages, or a circle, or a rect, or a processed graphic. Or lets say two points that are moving inside a view into a defined rect and that display a bigger point when they are close.
How may I subclass and define the subview to make it able to do this only into its drawRect method ?
How does the controller, that manages more than this simple UIView (let's imagine you have a view controller that manages a view inside which there are many other view, and you want to make some drawings in two of them), and that knows what is needed to be drawn into the correct view (it's a controller, isn't it ?), may interact with the views ? And when the drawing is done, how may the views interact with the controller ?
I've read many doc about drawings (apple, web, forums, tutorials, ...), but I still can't touch the philosophy of the way this must be done.
it's very simple. Make a new class, OliverView, which is a UIView. (ie, it is a subclass of UIView.) In that view, make it draw stuff in a fancy way, inside drawRect.
Now make a UIViewController, called OliverVC. In storyboard put an OliverView inside OliverVC. (beginner explanation of how to do that).
In the OliverView, have properties "hours", "minutes", "seconds".
Now, in OliverView - in the drawRect - have a fancy way to display those values. (Pie chart, glowing letters, animation - whatever you want.)
Now, up in OliverVC, do some calculations to determine the time in Zimbabwe, for example.
Once you want a time displayed, simply set those properties in OliverView - - and you are done.
Your colleague could be programming the OliverView. You need know nothing about how she is going to display the time. Conversely, your colleague need know nothing about your calculations in OliverVC..
So, it's simpleL One part has the job of displaying the data. One part has the job of coming up with the data (doing whatever sort of calculation is relevant in the app).
It's the only architecture possible in a "real time" screen device where the views can and do change at any time.
In answer to your question below: you've forgotten that quite simply, if you have a button that would be a whole separate element. (Perhaps sitting "on top of" the OliverView.) So, it's easy!
The -drawRect method in your UIView subclass defines the onscreen appearance of the view. All drawing is done in -drawRect. Your UIViewController calls methods on its UIView to tell it to draw something differently or to perform some other action.
The UIViewController manages everything to do with the view that is not inherently associated with the drawing of the content. Data associated with the view is often stored in the controller.
I discovered that my drawRect is being called more than once. Unfortunately this had the unfortunate side-effect of double-drawing everything because all my subviews are drawn in drawRect (I'm s strict atheist w.r.t. Interface Builder).
What is the best way to deal with a multiple calls to drawrect? A flag to check if it's being called again? Or clear the whole view and redraw from scratch (as I have done?)
What do you mean by "your subviews are drawn in drawRect"? If you mean that you're putting calls to -addSubview: in your drawRect, don't. Move those to a more appropriate place that gets called only when it needs to (probably the -initWithFrame: method for your view if the subviews are always there), and use drawRect only to do custom drawing.
Strictly speaking, being called multiple times is the entire point of -drawRect. It's called to update small parts of your view when needed. It's actually called quite often if you're updating your view (moving it around, updating the superview, etc.), so it should be as simple and fast as possible to avoid performance problems.
When UIKit calls drawRect:, the graphics context set up to draw into should already be cleared for you (unless you have set the clearsContextBeforeDrawing property to NO). Are you perhaps calling drawRect: manually instead of calling setNeedsDisplay/setNeedsDisplayInRect:?
Also, each view is responsible for drawing only its own content and not the content of its subviews.
I'm implementing a UIView's (UITableViewCell to be more exact) drawRect method.
My view has a transparent background, so when something is changed in the view, the older drawn version still remains there. So if on the first drawRect draw an "A", then a "B" on the same point, I get both of them drawn on top of each other.
How can I tell the framework to redraw the background?
(which I suppose it doesn't do because is not always needed, but in this case it badly is)
I guess what I need is the equivalent of win32's invalidateRect, however I went thru UIViews members and didn't find anything.
Btw, i've tried setNeedsDisplay, it didn't help.
I think I've used CGContextClearRect(CGContextRef context, CGRect rect) for this before.
you should set clearsContextBeforeDrawing
I wonder if, since it is your own view that is retaining the drawing, whether you yourself should erase the rect being passed in?
What happens if your background is not transparent?
It's possible having come from the Windows world that you're thinking about the problem wrong. Having also come from the Windows world, I've done the same many times myself. Why do you need to override drawRect? Whenever you do that, you are responsible to take care of everything. Is it possible to do what you are wanting another way? What are you drawing in drawRect? Can you just add sub views or sub layers to your cell instead?
BTW, are you calling [super drawRect:rect] at the beginning of your drawRect override?
I'm no longer reusing cells.
This is working for me because I always have < 20 cells in my table. I guess this is not a solution for everyone, but it's the way I'm planning to go.
Rather than have the framework create and reuse 10ish cells, I'm creating my 20 while fetching the data for them, and later at display time things go smoother because they don't need to be re-customized every time.