In the first part of this post I have explained how to synchronize rotation animation in iOS between its virtual keyboard and the view floating above it. Many things have changed since then, iOS 6, iOS 7 and now the iOS 8, which is the reason why I am writing the second part of that post. In short, Apple changed something in their iOS 8 implementation causing keyboard notifications observer methods to execute their code while animations are disabled. But only when notifications are posted as a consequence of an interface orientation change while the keyboard was visible.
Hit-testing is the process of determining whether a point, such as touch-point, intersects a given graphical object, such as
UIView, drawn on the screen. iOS uses hit-testing to determine which
UIViewis the frontmost view under the user’s finger that should receive the touch event. It implements it by searching the view hierarchy using reverse pre-order depth-first traversal algorithm.
Hi, today I would like to show you how to make a
UIViewto stay attached to the top of the iPhone’s keyboard while the keyboard is animated. But not only when the keyboard is animated while it is being presented or dismissed but also when it is animated when the iPhone is rotated and the interface orientation is changed.
Although many answers could be found explaining how to make a
UIViewto stay attached to the keyboard while the keyboard is being animated when it is presented or dismissed. I have not found any solutions that also make that
UIViewto stay attached to the keyboard when device is rotated and rotation of the interface orientation is animated.
After writing my first post about how to be notified when specific font-families downloaded and rendered on a web page, I kept thinking that this approach wasn’t too efficient. The fact that the time taking to download and render fonts on a web page depends on many different factors like the network latency and processing power of the client device, makes it difficult to choose the right time interval for sampling dimensions of elements. Using too long interval may introduce extra waiting time if the font was loaded just after new timer iteration was started. On the other hand, using too short interval may present processing time overhead when trying to get the dimensions of elements by obtaining layout triggering properties like
offsetHeight. So I kept thinking how you can force the browser to notify you when custom font is loaded without polling the dimensions of “font container” element.
Following event timeline overview show the difference between the events fired in web page when using typekit’s Web Font Loader that uses timeouts, and the events fired when using method that does not use timeouts, as explained in this post. These event timelines are taken from the chrome developer tools.
typekit events timeline (with timeouts)
fontloader event timeline (without timeouts)
If you just want to use the FontLoader without reading this post you can download it on Github: