import UIKit | |
import PlaygroundSupport | |
/// Simple sample diffable table view to demonstrate using diffable data sources. Approximately 33% of the time, it should show "bad weather" UI instead of apples and oranges | |
final class DiffableCollectionViewController : UIViewController { | |
var collectionView: UICollectionView! | |
enum Section: String, CaseIterable, Hashable { | |
case apples = "Apples" |
typedef CF_ENUM(int, CFNetworkErrors) { | |
kCFHostErrorHostNotFound = 1, | |
kCFHostErrorUnknown = 2, // Query the kCFGetAddrInfoFailureKey to get the value returned from getaddrinfo; lookup in netdb.h | |
// SOCKS errors; in all cases you may query kCFSOCKSStatusCodeKey to recover the status code returned by the server | |
kCFSOCKSErrorUnknownClientVersion = 100, | |
kCFSOCKSErrorUnsupportedServerVersion = 101, // Query the kCFSOCKSVersionKey to find the version requested by the server | |
// SOCKS4-specific errors | |
kCFSOCKS4ErrorRequestFailed = 110, // request rejected or failed by the server | |
kCFSOCKS4ErrorIdentdFailed = 111, // request rejected because SOCKS server cannot connect to identd on the client |
#!/bin/bash | |
# | |
# Fool'n'Lazy-Proof iOS .crash Symbolication | |
# | |
# Just run this script on a folder with your `.ipa`, the corresponding `.dSYM`, | |
# and (1+) `.crash` files. Will output symbolicated `sym-*.crash`es for you. | |
# | |
# Copyright (c) 2016 Ferran Poveda (@fbeeper) | |
# Provided under MIT License (MIT): http://choosealicense.com/licenses/mit/ |
import CoreData | |
import Foundation | |
protocol CoreDataManager { | |
var uiContext: NSManagedObjectContext { get } | |
func newBackgroundContext() -> NSManagedObjectContext | |
func performBackgroundTaskOnUI(_ block: @escaping (NSManagedObjectContext) -> Void) | |
func performBackgroundTask(_ block: @escaping (NSManagedObjectContext) -> Void) | |
func loadStore(completionHandler: ((Error?) -> Void)?) | |
} |
PRODUCT_NAME := Foo | |
SCHEME_NAME := ${PRODUCT_NAME} | |
WORKSPACE_NAME := ${PRODUCT_NAME}.xcworkspace | |
UI_TESTS_TARGET_NAME := ${PRODUCT_NAME}UITests | |
TEST_SDK := iphonesimulator | |
TEST_CONFIGURATION := Debug | |
TEST_PLATFORM := iOS Simulator | |
TEST_DEVICE ?= iPhone 11 Pro Max | |
TEST_OS ?= 13.3 |
If you hate git submodule
, then you may want to give git subtree
a try.
When you want to use a subtree, you add the subtree to an existing repository where the subtree is a reference to another repository url and branch/tag. This add
command adds all the code and files into the main repository locally; it's not just a reference to a remote repo.
When you stage and commit files for the main repo, it will add all of the remote files in the same operation. The subtree checkout will pull all the files in one pass, so there is no need to try and connect to another repo to get the portion of subtree files, because they were already included in the main repo.
Let's say you already have a git repository with at least one commit. You can add another repository into this respository like this:
The libdispatch is one of the most misused API due to the way it was presented to us when it was introduced and for many years after that, and due to the confusing documentation and API. This page is a compilation of important things to know if you're going to use this library. Many references are available at the end of this document pointing to comments from Apple's very own libdispatch maintainer (Pierre Habouzit).
My take-aways are:
-
You should create very few, long-lived, well-defined queues. These queues should be seen as execution contexts in your program (gui, background work, ...) that benefit from executing in parallel. An important thing to note is that if these queues are all active at once, you will get as many threads running. In most apps, you probably do not need to create more than 3 or 4 queues.
-
Go serial first, and as you find performance bottle necks, measure why, and if concurrency helps, apply with care, always validating under system pressure. Reuse