Author: Chris Lattner
/// Used to identify traits of the current UI Environment - especially useful for cross-platform code | |
public struct MNCUITraits: Withable { | |
/// Does *not* identify the device type, but the idiom of the layout to apply | |
/// This means that e.g. on iPad the layoutIdiom can be `.phone`, if run in Split Screen or SlideOver | |
public enum LayoutIdiom { | |
case phone(hasRoundCorners: Bool) | |
case pad(hasRoundCorners: Bool) | |
case mac | |
} |
- (UIImage *)dynamicImage | |
{ | |
UITraitCollection *const baseTraitCollection = /* an existing trait collection */; | |
UITraitCollection *const lightTraitCollection = [UITraitCollection traitCollectionWithTraitsFromCollections:@[baseTraitCollection, [UITraitCollection traitCollectionWithUserInterfaceStyle:UIUserInterfaceStyleLight]]]; | |
UITraitCollection *const purelyDarkTraitCollection = [UITraitCollection traitCollectionWithUserInterfaceStyle:UIUserInterfaceStyleDark]; | |
UITraitCollection *const darkTraitCollection = [UITraitCollection traitCollectionWithTraitsFromCollections:@[baseTraitCollection, purelyDarkTraitCollection]]; | |
__block UIImage *lightImage; | |
[lightTraitCollection performAsCurrentTraitCollection:^{ | |
lightImage = /* draw image */; |
extension Sequence { | |
var headAndTail: (head: Element, tail: SubSequence)? { | |
var head: Element? | |
let tail = drop { | |
if head == nil { | |
head = $0 | |
return true | |
} else { |
//Swift 4 modifications for this gist: https://gist.github.com/krooked/9c4c81557fc85bc61e51c0b4f3301e6e | |
import Foundation | |
import UIKit | |
extension UIImage { | |
func cropImageByAlpha() -> UIImage { | |
let cgImage = self.cgImage | |
let context = createARGBBitmapContextFromImage(inImage: cgImage!) | |
let height = cgImage!.height | |
let width = cgImage!.width |
import Foundation | |
// A lens is a getter and a setter combined | |
struct Lens<Whole, Part> { | |
let get: (Whole) -> Part | |
let set: (inout Whole, Part) -> () | |
} | |
// We can create a lens from a key path | |
extension Lens { |
// Swift Playgrounds Beta 1.0 | |
import AVFoundation | |
import AVKit | |
import Accelerate | |
import Accounts | |
import AudioToolbox | |
import AudioUnit | |
import CFNetwork | |
import CoreAudio | |
import CoreAudioKit |
/** | |
* A class that can be part of a tabbed navigational interface (expected to be a `UIViewController` but can also be a | |
* coordinator that proxies through to an underlying controller). | |
*/ | |
public protocol TabComponent { | |
/// The tab metadata | |
var tabItem: TabItem { get } | |
var viewController: UIViewController { get } | |
} |
State machines are everywhere in interactive systems, but they're rarely defined clearly and explicitly. Given some big blob of code including implicit state machines, which transitions are possible and under what conditions? What effects take place on what transitions?
There are existing design patterns for state machines, but all the patterns I've seen complect side effects with the structure of the state machine itself. Instances of these patterns are difficult to test without mocking, and they end up with more dependencies. Worse, the classic patterns compose poorly: hierarchical state machines are typically not straightforward extensions. The functional programming world has solutions, but they don't transpose neatly enough to be broadly usable in mainstream languages.
Here I present a composable pattern for pure state machiness with effects,
// http://blog.krzyzanowskim.com | |
import Cocoa | |
struct ChunkSequence<Element>: SequenceType { | |
let chunkSize: Array<Element>.Index | |
let collection: Array<Element> | |
func generate() -> AnyGenerator<ArraySlice<Element>> { | |
var offset:Array<Element>.Index = collection.startIndex |