On iOS, if a subclass of CALayer is used with an empty display method, then app seems to go into infinite loop? - iphone

If a Single View app is created, with a FooView that subclasses UIView, and do a
NSLog(#"hello");
in drawRect, then it is printed.
And if I create a subclass of CALayer called CoolLayer, and add this method to FooView.m:
+(Class) layerClass {
return [CoolLayer class];
}
and at the end of FooView.m's drawRect, do a
NSLog(#"layer's class is %#", self.layer.class);
then CoolLayer is printed. So now the view's underlaying layer is CoolLayer.
But when the following is added to CoolLayer.m:
-(void) display {
}
which is the method that is automatically called to redraw the layer (similar to drawRect), then no NSLog whatsoever was printed. It might be that the app went into an infinite loop. (even my touchesBegan that prints out NSLog messages is not printing). If a breakpoint is set at display, it will stop there once but when I continue the program, it will never arrive at display again. What is wrong with this and how can it be fixed?

The layer's display method will not be called again unless the layer is dirty, i.e. set to need a redisplay. This is usually a good thing, and is why you don't see the method being called more than once.
Also, the normal implementation of display will call the drawInContext: method. Since you override this in your subclass, the drawRect: method of the view is never called. You need to either replicate the standard behavior of CALayer, or call the superclass' display method in your own implementation.

That does not sound like an infinite loop. If you were in an infinite loop your app would freeze, and after a few seconds the springboard app would kill it for being unresponsive.
Call setNeedsDisplay or setNeedsDisplayInRect on your layer to make it "dirty" and require drawing again. Note that you don't want to call setNeedsDisplay any more than you have to, because it takes a lot of work to re-render the layer and push it's contents onto the screen. Only display when something has changed

You're not seeing an infinite loop here. If you were, as Duncan points out, you'd eventually crash either due to the watchdog timer or from an infinite recursion that would be immediately obvious in the stack trace you'd see in the debugger.
If you put an NSLog into your UIView's -drawRect: method, then override its default layer class with your own custom CALayer that does its own drawing, your UIView's -drawRect: would no longer be called. Drawing would now be handled by your custom backing layer.
As described in the "Providing CALayer Content by Subclassing" subsection of the Core Animation Programming Guide, you typically override -display in your CALayer if you want to somehow customize the contents CGImageRef for your layer. Normally, you'll be overriding -drawInContext: if you want to render custom Quartz drawing within your CALayer. Making your overridden -display method totally blank, and not writing anything to the contents property, is not standard behavior, so I'm not surprised that you're seeing odd results from doing that.
Based on your series of recent questions, I highly recommend you stop and spend some time reading the Core Animation Programming Guide and looking at some sample code involving CALayers before proceeding further.

Related

Force redraw with CADisplayLink

I'm currently using CADisplayLink to show an OpenGL animation which works great. Sometimes, however a parameter changes and I need to redraw the view immediately and can't wait until the next frame is requested by CADisplayLink. If I don't do that, I get one frame wrong which looks really bad in my case.
So, how can I force a redraw of an EAGLView without interfering with the CADisplayLink stuff?
If your CADisplayLink is calling method drawFrame, for example, then just call drawFrame yourself when you need to. No reason you need to wait for CADisplayLink if you don't want to.
Your question suggests that you're storing your data in your view rather than in a data object. You should be able to change your data at any time, and your view should update when its needed to display. Move the data to a model object, and have the EAGLView draw itself based on the data when requested from the CADisplayLink rather than redrawing itself when the data changes.

iPhone: Resizing in drawRect:

I have a UIView based control which I need to resize depending on various criteria and properties of the control. I'm not sure if the way I'm doing it is the best way but so far it's the only one I've found that seems to work. Because the size of the control is dependant on various properties, I cannot set the size in a constructor.
I have a method called setupControl: which contains all the code to finish the setup based on the properties set. I don't want setupControl: called manually, so in drawRect I detect if I need to call it and then queue a selector like this:
[self performSelector:#selector(setupControl)withObject:self afterDelay:0];
return;
At the bottom of setupControl: I then do:
[self setNeedsDisplay];
self.hidden = NO;
I've also overridden the initWithFrame: and initWithDecoder: constructors so that they set the UIView to be hidden to start with until the setup code is executed. The idea being to eliminate any "flashes" on the display as the control resizes.
As I said this works fine, the controls can be drawn ay size is the xib file and then set themselves to the correct size at run time.
My question is whether this method of queuing a selector, exiting the drawRect: and then using a setNeedsDisplay is the only way to do this? O is there some method I haven't found that I can override? or something else?
What you probably want to override is layoutSubviews rather than drawRect as you're changing the layout, not implementing custom drawing.
You may also have to use a custom setter for any properties that change the size of the view and call [self setNeedsLayout] in the setter to make sure your layoutSubviews method is called before your view size is computed.

Parent View issues with UIImagePickerControllerSourceTypeCamera

I have an odd problem with UIImagePickerControllerSourceTypeCamera. My application gives the choice to select a pic from the gallery, or take a photo with the camera. If I choose the gallery, I pick a photo and return to my view, no issues.
However, when using UIImagePickerControllerSourceTypeCamera, it appears to do something odd with my view when I return to it.
For example, I have a bunch of code in the viewDidLoad method which moves some objects in the view if it needs to based on some factors - this code gets called when I exit the UIImagePickerControllerSourceTypeCamera, but doesnt get called when I exit the gallery.
Is this expected?
I think your view is getting dumped by the didReceiveMemoryWarning thing which is being triggered by the resource-intensive camera stuff. You can force the simulator to generate a memory warning without the camera to test this theory.
Generally speaking, viewDidLoad needs to be able to deal with getting called multiple times. It's not an init method. It gets called again if self.view gets set to nil and the view later needs to be recreated. There may be a more appropriate place to put any code you have there that's causing problems, but the init methods are tricky because the designated initializer is bypassed by nib loading.
When loaded from a nib, the class's initWithCoder is called instead which bypasses the whole init process because dearchiving is assumed to be sucking in an already-initialized object. Therefore reinitializing the object might break stuff, like call loadView which essentially conflicts with what a nib contains as it's supposed to programmatically construct what the nib already has in it. You can still override initWithCoder as usual though as long as you pass through the args to super like you should, but then this will not get called if you initialize the object with the designated initializer. Of course if you need to worry about that you can put all the code you want executed in both into a method that gets called from both overridden methods.

CALayer delegate method drawLayer not getting called

My object a sub class of NSObject has CALayer instance variable. I use it for drawing and caching content with its delegate set to my object.
But for some reason drawLayer:inContext: method NEVER gets called. Whereas actionForLayer:forKey: delegate method does get called implying the delegate is getting set properly with layer.delegate = self in the object's init method.
Any suggestions on what is preventing my layer drawing method drawLayer:inContext: from getting called ?
I am called the [layer setNeedDisplay] often. So I guess it is some fundamental error.
drawLayer:inContext: won't get called if your frame is CGRectZero or offscreen. Also, if your CALayer isn't attached to an existing onscreen layer, it will never draw, no matter how many times you call setNeedsDisplay
Implement an empty drawRect:
- (void)drawRect:(CGRect)rect {
}
Taken from the ZoomingPDFViewer project:-
UIView uses the existence of -drawRect: to determine if it should
allow its CALayer to be invalidated, which would then lead to the
layer creating a backing store and -drawLayer:inContext: being
called. By implementing an empty -drawRect: method, we allow UIKit
to continue to implement this logic, while doing our real drawing work
inside of -drawLayer:inContext:
The layer object's setNeedsDisplay must be called. Simply adding the layer as a sublayer does not do that for you. Got this from Ray Wenderlich's CALayer tutorial.
If you're eventually using the CALayer with a UIView then the delegate must be the view object itself:
From the iOS CALayer documentation:
"In iOS, if the layer is associated with a UIView object, this property must be set to the view that owns the layer."
If you have a multi-threaded app where background processing drives the need to update the CALayer, you must call setNeedsDisplay in the main thread

Calling setNeedsDisplay on a UIView from another class

I have a UIView subclass that I manipulate a lot of graphics on based on touches. All the [self setNeedsDisplay] calls seem to be fine.
However, I used an instance variable pointer to my same UIView subclass instance, and then tried manipulating it and then calling [UIViewSubClass setNeedsDisplay] from another UIView class, and DrawRect is never being called. Are there restrictions to where you can call setNeedsDisplay from?
(This method is called when a button is clicked on another UIView subclass. The method is being called, but not DrawRect)
-(IBAction)loadGrid2;
{
tempSoundArray = musicGridView1.soundArray;
[musicGridView1.soundArray setButtonArrayToNull];
[musicGridView1 setNeedsDisplay];
musicGridView1.soundArray = tempSoundArray;
NSLog(#"loadGrid2 was called");
}
drawRect: will only be called when it makes sense; ie, the view must be visible, onscreen, and dirty. Is your drawRect: ever called? It should be called when the view is first brought onscreen as well.
To add to Ben:
This most likely means that you have problems elsewhere. Your pointer may not be nil or otherwise invalid or the view may not be added to the hierarchy properly.
You may want to consider not handling this type behavior within the view and instead in the view controller. Control behavior and save presentation state in the view controller and don't subclass the view classes. It will simplify your code with less "pointer passing". This will also make it easier to debug this type of problem.
If you feel your view controller is getting bloated, consider splitting the responsibilities up among multiple view controllers.