ashevin

Debug Console

There are times you might find it convenient to be able to tweak a setting that has no UI. Perhaps you need to reset internal state without reinstalling the app, or you have a some counters that QA would like to adjust to test business logic. If any of these apply to you, the Debug Console is for you.

What is it?

The Debug Console consists of a UIViewController and a set of UITableViewCell descendants which allow one to easily add tweakable options and actions.

The Base Class

ashevin

Observable/Observer

A case study

Observable is an implementation of the reactive programming style. This document explores the considerations which went into the implementation.

Memory Management

Instances of Observer are intended to be chained in order to appropriately filter and transform emitted values. It is critical that special care is exercised to avoid unintended retain cycles.

ashevin

Unit Testing

The Unit

While it is generally understood that unit testing is the activity of running tests to ensure that a unit is upholding its contract, the concept of a unit is often left undefined. In short, a unit is a subset of code which can be compiled on its own. For example, a framework or library is a unit. However, units may be comprised of other units. Internal types may form their own units, which are depended on by the public interface of the library. Any type with functionality (methods) may form its own unit.

The Tests

One of the fundamental differences between unit testing and other forms of software testing is the specificity of the tests. Each test covers a single entry point into the public interface, and does not endeavor to test how pieces interact. Any such interactions are treated as implementation details. The unit test ensures that the contract of the entry point is met. The how is unimportant.

ashevin

//
//  NSPredicate+extensions.swift
//  CoreDataManager
//
//  Created by Avi Shevin on 23/10/2017.
//  Copyright © 2017 Avi Shevin. All rights reserved.
//

import Foundation

ashevin

//
//  CoreDataManager.swift
//  CoreDataManager
//
//  Created by Avi Shevin on 23/10/2017.
//  Copyright © 2017 Avi Shevin. All rights reserved.
//

import Foundation
import CoreData

ashevin

import UIKit
import PlaygroundSupport

extension String {
    subscript(range: NSRange) -> String? {
        guard range.location + range.length <= self.characters.count else {
            return nil
        }

        let r = index(startIndex, offsetBy: range.location)..<index(startIndex, offsetBy: range.location + range.length)

ashevin

Core Data describes objects as entities, with relationships between entities.  At runtime, Core Data will create an instance of NSManagedObject, which will allow access to the properties of the entity.  Functionally, an instance of NSManagedObject acts much like NSDictionary, wherein a key matching the name of one of the entity's properties is used to access that property's value, or to change it.

Using raw NSManagedObjects are a poor choice in any serious application.  There's no type-safety.  Access to properties is predicated on correctly spelling the property names, and generally all the downsides of stringly-typed data and properties.  For this reason, Core Data allows the model to specify subclasses of NSManagedObject, one per entity, which will be created when Core Data needs to present an entity instance at runtime.  These subclasses specify strongly-typed properties, matching the property names in the entity definition.  Such classes may also contain other properties, not backed or managed by Core D

ashevin

//: Playground - noun: a place where people can play

import UIKit

extension Array {
    func binarySearch<T: Comparable>(key: T, returnInsertionIndex: Bool = false) -> Int? {
        var range = 0..<self.count

        var midIndex: Int = 0
        var value: T?