January 6, 2013
I recently saw a post on Twitter from @chpwn that described the alogorithm that Apple uses for its “rubber band” or “bungee” scrolling.
b = (1.0 – (1.0 / ((x * c / d) + 1.0))) * d
<?xml version="1.0" encoding="UTF-8"?> | |
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> | |
<plist version="1.0"> | |
<dict> | |
<key>items</key> | |
<array> | |
<dict> | |
<key>assets</key> | |
<array> | |
<dict> |
mr Marathi | |
bs Bosnian | |
ee_TG Ewe (Togo) | |
ms Malay | |
kam_KE Kamba (Kenya) | |
mt Maltese | |
ha Hausa | |
es_HN Spanish (Honduras) | |
ml_IN Malayalam (India) | |
ro_MD Romanian (Moldova) |
(by @andrestaltz)
If you prefer to watch video tutorials with live-coding, then check out this series I recorded with the same contents as in this article: Egghead.io - Introduction to Reactive Programming.
import UIKit | |
extension UIView { | |
func currentFirstResponder() -> UIResponder? { | |
if self.isFirstResponder() { | |
return self | |
} | |
for view in self.subviews { | |
if let responder = view.currentFirstResponder() { |
In this article, I'm going to explore a way that we can create views that implement custom Core Animation property animations in a natural way.
As we know, layers in iOS come in two flavours: Backing layers and hosted layers. The only difference between them is that the view acts as the layer delegate for its backing layer, but not for any hosted sublayers.
In order to implement the UIView
transactional animation blocks, UIView
disables all animations by default and then re-enables them individually as required. It does this using the actionForLayer:forKey:
method.
Somewhat strangely, UIView
doesn't enable animations for every property that CALayer
does by default. A notable example is the layer.contents
property, which is animatable by default for a hosted layer, but cannot be animated using a UIView
animation block.
import UIKit | |
extension UILabel { | |
func setText(text: String, withKerning kerning: Double) { | |
self.attributedText = NSAttributedString(string: text, attributes: kerningAttribute(kerning)) | |
} | |
func setText(text: String, withLineSpacing lineSpacing: CGFloat) { | |
self.attributedText = NSAttributedString(string: text, attributes: lineSpacingAttribute(lineSpacing)) |
import Foundation | |
extension String { | |
func replaceCharactersFromSet(characterSet: NSCharacterSet, replacementString: String) -> String { | |
let scanner = NSScanner(string: self) | |
scanner.charactersToBeSkipped = nil | |
let sanitizedString = NSMutableString(capacity: self.characters.count) | |
while(!scanner.atEnd) { |
Modern Cocoa development involves a lot of asynchronous programming using closures and completion handlers, but these APIs are hard to use. This gets particularly problematic when many asynchronous operations are used, error handling is required, or control flow between asynchronous calls gets complicated. This proposal describes a language extension to make this a lot more natural and less error prone.
This paper introduces a first class Coroutine model to Swift. Functions can opt into to being async, allowing the programmer to compose complex logic involving asynchronous operations, leaving the compiler in charge of producing the necessary closures and state machines to implement that logic.
class BlurryOverlayView: UIVisualEffectView { | |
private var animator: UIViewPropertyAnimator! | |
private var delta: CGFloat = 0 // The amount to change fractionComplete for each tick | |
private var target: CGFloat = 0 // The fractionComplete we're animating to | |
private(set) var isBlurred = false | |
private var displayLink: CADisplayLink! | |
override init(effect: UIVisualEffect?) { | |
super.init(effect: effect) | |
setup() |