| // CacheItem.h | |
| @interface CacheItem : RLMObject | |
| @property NSString *key; | |
| @property NSData *value; | |
| @end | |
| // CacheItem.m | |
| @implementation CacheItem |
Here's my own list of the interesting stuff announced during this year's WWDC, collected from the keynotes, various Apple docs, blog posts and tweets.
If you're planning to watch the videos, I really recommend this Mac app that helps you download and watch them: https://github.com/insidegui/WWDC.
http://www.apple.com/osx/elcapitan-preview/
When Swift was first announced, I was gratified to see that one of the (few) philosophies that it shared with Objective-C was that exceptions should not be used for control flow, only for highlighting fatal programming errors at development time.
So it came as a surprise to me when Swift 2 brought (What appeared to be) traditional exception handling to the language.
Similarly surprised were the functional Swift programmers, who had put their faith in the Haskell-style approach to error handling, where every function returns an enum (or monad, if you like) containing either a valid result or an error. This seemed like a natural fit for Swift, so why did Apple instead opt for a solution originally designed for clumsy imperative languages?
I'm going to cover three things in this post:
| // SO [UITextView - Highlight text with NSBackgroundColor - exclude line breaks](http://stackoverflow.com/questions/26558396/uitextview-text-highlighting-when-the-text-is-centered) | |
| // Source | |
| // TextViewHighlighter.h | |
| #import <Foundation/Foundation.h> | |
| @import UIKit; | |
| @interface TextViewHighlighter : NSObject |
| // meet Stringy - a simple string type with a fluent interface | |
| struct Stringy { | |
| let content: String | |
| init(_ content: String) { | |
| self.content = content | |
| } | |
| func append(appendage: Stringy) -> Stringy { |
| // Basically, these are if and else statements respectively | |
| // without the opposite clause | |
| func when(test: @autoclosure () -> Bool, action: () -> ()) { | |
| if test() { action() } | |
| } | |
| func unless(test: @autoclosure () -> Bool, action: () -> ()) { | |
| if !test() { action() } | |
| } |
| //#!/usr/bin/env objc-run | |
| #import <Foundation/Foundation.h> | |
| #import <objc/runtime.h> | |
| #import <objc/message.h> | |
| /// | |
| /// Typedefs | |
| typedef id (^TargetMethod)(id arg); |
| /// 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 |
| This is the code path that changed the status bar orientation on iOS 7: | |
| * thread #1: tid = 0x698dbf, 0x00085830 WindowRotationIssue`-[AppDelegate application:willChangeStatusBarOrientation:duration:](self=0x7a041f90, _cmd=0x0137a18d, application=0x79e39cc0, newStatusBarOrientation=UIInterfaceOrientationPortraitUpsideDown, duration=0.80000000000000004) + 96 at AppDelegate.m:23, queue = 'com.apple.main-thread', stop reason = breakpoint 3.1 | |
| * frame #0: 0x00085830 WindowRotationIssue`-[AppDelegate application:willChangeStatusBarOrientation:duration:](self=0x7a041f90, _cmd=0x0137a18d, application=0x79e39cc0, newStatusBarOrientation=UIInterfaceOrientationPortraitUpsideDown, duration=0.80000000000000004) + 96 at AppDelegate.m:23 | |
| frame #1: 0x00bb6ab5 UIKit`-[UIApplication setStatusBarOrientation:animationParameters:notifySpringBoardAndFence:] + 242 | |
| frame #2: 0x00bfa8e4 UIKit`-[UIWindow _setRotatableClient:toOrientation:updateStatusBar:duration:force:isRotating:] + 4761 | |
| frame #3: 0x00bf9646 UIKit`-[UIWi |
