Originally posted on nicolasrizk.com — March 16, 2015
Apple implements this class on homescreens of all devices running iOS 7 or later. And in English-y terms, it’s what creates the perception that the user’s point of view affects the coordinates of views on the screen: tilting side to side will make it seem that views follow the user’s eye. If that doesn’t make sense, I have provided an example below.
I thought this was an interesting topic because of its prevalence on all devices as well as the fact that there isn’t much documentation on it yet. In fact, if you go to UI Motion Effect’s Class Reference, you will see this quick blurb below the title:
IMPORTANT
This is a preliminary document for an API or technology in development. Apple is supplying this information to help you plan for the adoption of the technologies and programming interfaces described herein for use on Apple-branded products. This information is subject to change, and software implemented according to this document should be tested with final operating system software and final documentation. Newer versions of this document may be provided with future betas of the API or technology.
When reading up on the UIMotionEffect class, I analogized (is that a word? if not, oh well) its existence to the mother class of them all: NSObject. NSObject was meant to be subclasses, not used outright in its pure NSObject form. I regard it more as a toolshed rather than an actual tool. I think UIMotionEffect is similar, as it’s a class that is meant to be subclassed. In fact, UIMotionEffect cannot be instantiated directly. As such, we will use one of its subclasses, UIInterpolatingMotionEffect, to illustrate the example.
With that in mind, let’s jump in!
To start, I have created a new Single-Page Application Project. A View Controller already exists and is connected to the VC in my Storyboard. Next, I will add a UITextView of this blog post and a UIImageView that will remain static to highlight the textview’s movement as you rotate your wrist. The implementation is straightforward. An instance of UIInterpolatingMotionEffect requires two parameters: (1) keyPath, which Apple states “must correspond to an animatable property of the view to which the motion effect is attached.” The clearest example of that is the center property of a view. (2) type, which is the motion direction in which you want the object to animate.
In our method, we create two instances of the UIInterpolatingMotionEffect, one to account for horizontal motion and the other for vertical motion. Brief side-note, after playing around with them I realized there will be very rare occurrences where I will implement both a horizontal and vertical motion. In terms of clean design, implementing both on let’s say a textView, makes it seem unnatural. Especially because we read (or view text) horizontally and not vertically. This would not be the case if we were in Japan though!
Ok back to what’s going on. So I looked up what interpolating meant when researching the class and realized that all we are doing is taking an object and allow it to go back and forth between two points. Specifically, we want it to interpolate between a point and its negated value.
Therefore, after initialization, we create the maximum and minimum bounds for both effects by setting the maximum point to the absolute value of a CGFloat and setting the minimum value to the negated value of that CGFloat. We pass in the CGFloat as a parameter to the method and we call it depth.
And that’s it! I called the method on myTextView (property that is linked to the storyboard) and set the depth to 50.
My comments on the implementation of this class in terms of design:
– As said previously, unless I have 3D objects, (i.e. a map) I will most likely only use one UIInterpolatingMotionEffect. I felt that my control was compromised as user because of how “delicate” the rotation of ones wrist even decimal points of an inch can be.
-I would set the depth to a lower value to create subtlety.
