nicklockwood

Hacking UIView animation blocks for fun and profit

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.

nicklockwood

Suppose we want to add support for a new iOS 8 API in our framework that replaces an older iOS 7 API. There are a few problems we might face:

1. The new API will crash if we call it on iOS 7
2. The new API won't compile if we build it using the iOS 7 SDK
3. The old API will raise a deprecation warning if built with a deployment target of iOS 8 and up

These three problems require three different technical solutions:

1. We can avoid calling the new API on an old OS version by using runtime detection (e.g. respondsToSelector:)
2. We can avoid compiling new APIs on old SDKs using the __IPHONE_OS_VERSION_MAX_ALLOWED macro

marcboquet

#! /usr/bin/ruby
require 'pathname'

platform = "iphonesimulator" # or "macosx"
contents_xcplayground = <<XML
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<playground version='1.0' sdk='#{platform}'>
    <sections>
        <code source-file-name='section-1.swift'/>
    </sections>

cabeca

#!/usr/bin/env ruby

device_types_output = `xcrun simctl list devicetypes`
device_types = device_types_output.scan /(.*) \((.*)\)/

runtimes_output = `xcrun simctl list runtimes`
runtimes = runtimes_output.scan /(.*) \(.*\) \((com.apple[^)]+)\)$/

devices_output = `xcrun simctl list devices`
devices = devices_output.scan /\s\s\s\s(.*) \(([^)]+)\) (.*)/

wouter-swierstra

// A type-level SAT solver in Swift


// Two types to model Booleans
struct True { }

struct False { }

// Negation, Conjunction, Disjunction

andymatuschak

//
//  MultiDirectionAdjudicatingScrollView.swift
//  Khan Academy
//
//  Created by Andy Matuschak on 12/16/14.
//  Copyright (c) 2014 Khan Academy. All rights reserved.
//

import UIKit
import UIKit.UIGestureRecognizerSubclass

jspahrsummers

/// Observes a run loop to detect any stalling or blocking that occurs.
///
/// This class is thread-safe.
@interface GHRunLoopWatchdog : NSObject

/// Initializes the receiver to watch the specified run loop, using a default
/// stalling threshold.
- (id)initWithRunLoop:(CFRunLoopRef)runLoop;

/// Initializes the receiver to detect when the specified run loop blocks for

steipete

/// Performs `block` immediately and ignores subsequent calls during the same runloop.
#define pspdf_ensureCalledOnlyOncePerRunloop(block) do { \
static const char __onceKey; _pspdf_ensureCalledOnlyOncePerRunloop(self, &__onceKey, block); } while(0)
extern void _pspdf_ensureCalledOnlyOncePerRunloop(id self, const void *key, dispatch_block_t block);

void _pspdf_ensureCalledOnlyOncePerRunloop(id self, const void *key, dispatch_block_t block) {
    NSCParameterAssert(block);
    NSCParameterAssert(self);
    PSPDFAssertOnMainThread(); // run loop needs the main thread.

JaviLorbada

Videos

• Introduction to Functional Programming Johannes Weiß - https://vimeo.com/100786088
• ReactiveCocoa at MobiDevDay Andrew Sardone - https://vimeo.com/65637501
• The Future Of ReactiveCocoa Justin Spahr-Summers - https://www.youtube.com/watch?v=ICNjRS2X8WM
• Enemy of the State Justin Spahr-Summers - https://www.youtube.com/watch?v=7AqXBuJOJkY
• WWDC 2014 Session 229 - Advanced iOS Application Architecture and Patterns Andy Matuschak - https://developer.apple.com/videos/play/wwdc2014/229/
• Functioning as a Functionalist Andy Matuschak - https://www.youtube.com/watch?v=rJosPrqBqrA
• Controlling Complexity in Swift Andy Matuschak - https://realm.io/news/andy-matuschak-controlling-complexity/

gist:8a163db3f7f3d81d5296

Your goals are to reduce the number of things that you have to keep in your head at any given moment, and to rely as little as possible on your own ability to consistently do things right.
If you make a thing immutable ('let' in swift), you never have to think about what happens if it changes, or what other parts of the code you'll effect if you change it.
If you split complex functions into several smaller functions that only interact by passing arguments or getting return values, then you limit the amount of code you need to consider when hunting for a bug, and you can test each small piece separately.
If you understand what things must be true in your code (aka invariants, for example "a person's age must be greater than 0"), and either provide no function that can cause them to be untrue, or check and crash immediately when they're untrue, then you don't have to debug issues caused by incorrect assumptions.
If you remove possibilities (for example, Swift removes the possibility of things being nil unless