nicklockwood

Schrödinger is a programming language, inspired by a Twitter joke: https://twitter.com/nicklockwood/status/425337273014816768

The Schrödinger language is C-like, but features only one primitive type, Cat, which can have one of two values, Dead or Alive.

You cannot assign values to a Cat, you can only ask what value it has. The value is determined randomly at the point of inspection but remains fixed from that point on. In that sense, a Cat is not so much a variable as a constant with a random value.

Here is some sample code:

Cat muffin;

if (muffin is Alive)

nicklockwood

# Mac OS X
*.DS_Store

# Xcode
*.pbxuser
*.mode1v3
*.mode2v3
*.perspectivev3
*.xcuserstate
project.xcworkspace/

nicklockwood

Singleton.h
-------------

@protocol Singleton
@optional

+ (instancetype)sharedInstance;

@end

nicklockwood

#import "TableViewController.h"

@interface TableViewController ()

@property (nonatomic, strong) UISearchBar *searchBar;

@end

@implementation TableViewController

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

nicklockwood

//here is an array factory method

@interface Foo: NSObject

@end

@implementation Foo

+ (NSArray *)newArray
{

nicklockwood

- (void)writeObject:(id)object toFile:(NSString *)file withPassword:(NSString *)password
{
    NSData *data = [FastCoder dataWithRootObject:object];
    CryptoArchive *archive = [[CryptoArchive alloc] initWithRootObject:data password:password];
    data = [FastCoder dataWithRootObject:archive];
    [data writeToFile:file atomically:YES];
}

- (id)readObjectFromFile:(NSString *)file withPassword:(NSString *)password
{

nicklockwood

import Accelerate

struct Matrix4 {
    var m11: Float
    var m12: Float
    var m13: Float
    var m14: Float
    var m21: Float
    var m22: Float
    var m23: Float

nicklockwood

var React = require('react-native');
var { requireNativeComponent } = React;

module.exports = requireNativeComponent('Carousel', null);