Relative newcomer here, sorry for sort of newbie question. I've tried searching for the answers.
I've coded up a way to apply a visual animation effect to a UIImageView on a view controller, based on the angle at which the user is holding the iPhone. Basically I'm using a CMMotionManager to provide an angle, then using that angle to shift a UIImageView by changing its bounds.center. Works great when everything is jammed into the view controller but I want it to be cleaner and reusable.
So I subclassed UIImageView, added to it a motion manager, a motion manager block handler and operation queue, plus a couple methods that map the device angle to a number corresponding to the shift in the UIImageView. I created a custom init method that accepted various parameters to control the visual effect. Then it was as simple as adding the instance of this class as a subview (addSubview:) to my controller's view. It was even using background threads and autorelease pools. Slick, I thought.
While it appears to work visually, for a slew of reasons (including that Instruments shows ever-increasing memory consumption), I'm thinking this is not what I should be jamming into a subclass of UIImageView. Is there a better way to architect this? For example, unlike UIViewController, a subclass of UIImageView doesn't have viewDidLoad/viewDidUnload/...appear/etc. which would let me start and stop the motion manager updates; and I should be able to create a single motion manager for the entire app instead of instantiating it in my image-effect class.
I do realize I must have only once instance of CMMotionManager per app, and have implemented Jonathan's method, but then I find myself needing to access appDelegate from my nifty class, when it would be easier to do it from the view controller, and it just spirals downward from there.
Am I asking for too much, or just not understanding a very simple concept?
