| import Foundation | |
| import UIKit | |
| class MyView: UIView { | |
| override func drawRect(rect: CGRect) { | |
| // just some path | |
| let path = UIBezierPath(roundedRect: CGRectMake(10, 10, 200, 100), byRoundingCorners: .TopLeft | .BottomRight, cornerRadii: CGSizeMake(30, 60)) | |
| // fill with red | |
| UIColor.redColor().setFill() |
| import AppKit | |
| import QuartzCore | |
| import XCPlayground | |
| // Parameters that define the style | |
| let hexSideLength: CGFloat = 15.0 | |
| let hexLineWidth: CGFloat = 3.0 | |
| let colors = [NSColor.redColor(), NSColor.cyanColor(), NSColor.greenColor(), NSColor.yellowColor(), NSColor.redColor()].map { $0.CGColor } |
| // I'm designing something where there are multiple different objects that can hold | |
| // exactly _one_ out of a couple of different other types, and I don't know what style I prefer. | |
| // | |
| // For example, an Input always has a name and it can hold a Symbol, a Target, or a Texture. | |
| // It should always hold exactly one of them. In just the same way, a Symbol has a name and can | |
| // hold different data of exactly exactly _one_ type of many. | |
| // | |
| // Which one of the following alternatives do you prefer? |
| - (NSURL *) writeImage:(NSImage *)image | |
| withSceneDocumentURL:(NSURL *)documentURL | |
| originalImageURL:(NSURL *)originalImageURL | |
| { | |
| if (!originalImageURL) { | |
| // Let the default exporter write this image | |
| return nil; | |
| } | |
| NSString *sceneFileName = | |
| [documentURL lastPathComponent]; |
I wanted to use enums, structs, and classes to create small, elegant objects for a basic chess game.
It started with the small squares in the chess board, and created the logic part in the main definition and an extension that is use for rendering
enum Row: Character {
case A = "A"
case B = "B"
case C = "C"
case D = "D"
The UIView animation API results in different CAAnimations being added to the layer on iOS 7 and 8. Changing the bounds of a view like this:
[UIView animateWithDuration:0.3
animations:^{
self.myView.bounds = CGRectMake(0, 0, 100, 100); // was (0,0) (200, 200)
}];
will result in one animation for the bounds key path being added to the backing layer if you are running iOS 7:
| @interface Foo : NSObject | |
| // some read-only property ... | |
| @property (nonatomic, copy, readonly) NSString *bar; | |
| @end | |
| @implementation Foo | |
| // ... with a custom accessor | |
| - (NSString *)bar | |
| { | |
| return @"Foo"; |
If you've haven't seen it before, there is a cool accessibility feature in UITableView that allows the user to toggle between different actions. It's really very elegant and it's a powerful and convenient implementation for VoiceOver users on iOS. One could say that it's the VoiceOver version of the swipe-to-delete feature.
To try it out yourselves, open one of the built in apps like Mail or Notes and turn on VoiceOver. If you are afraid to accidentally delete some of your important notes or email, you can also create a new Master-Detail Application in Xcode and run it on your device. Navigate to one of the cells and use the "Rotor" (rotate with two fingers on the screen) to find the "Actions" item. Now you can swipe up and down do toggle between "Activate Item (default action)" and "Delete". If you now double tap, the cell gets deleted instead of selected.
This is the default behavior and you get this accessibility out of the box with UITableView.
I hereby claim:
To claim this, I am signing this object:
There was [a tweet][tweetSoto] a couple of days ago that resulted in a discussion/question about what it wrong with the usage of removedOnCompletion = NO in the [SparkRecordingCircle code][code] for that [Subjective-C post][post].
We all kept saying that the explanation doesn't fit in a tweet, so here is my rough explanation about the issues.
But, let me first say that I think that the Subjective-C articles are reallt cool and useful to learn from. This is trying to reason about the general usage of removedOnCompletion = NO, using that code as an example, since that was what was discussed on twitter.
The root problem, as [Nacho Soto pointed out][rootProblem], is that removedOnCompletion = NO in combination with fillMode = kCAFillModeForwards is almost always used when you are not updating the model layer. This means that after the animation has finished, what you see on screen is not reflected in the property of the layer. The biggest issue that this can cause is that all the
