Author: Chris Lattner
#!/bin/sh | |
if [ "$#" -ne 1 ]; then | |
echo "$0 <path>" | |
exit 1 | |
fi | |
APP_PATH=$1 | |
BUNDLE_ID=`/usr/libexec/PlistBuddy -c "Print :CFBundleIdentifier" "$APP_PATH/Info.plist"` | |
for DEVICE in $(xcrun simctl list -j devices | jq --raw-output ".devices[][] | select(.state == \"Booted\") | .udid"); do |
- (void)tableView:(UITableView *)tableView willDisplayCell:(UITableViewCell *)cell forRowAtIndexPath:(NSIndexPath *)indexPath | |
{ | |
if ([tableView respondsToSelector:@selector(setSeparatorInset:)]) { | |
[tableView setSeparatorInset:UIEdgeInsetsZero]; | |
} | |
if ([tableView respondsToSelector:@selector(setLayoutMargins:)]) { | |
[tableView setLayoutMargins:UIEdgeInsetsZero]; | |
} | |
if ([cell respondsToSelector:@selector(setLayoutMargins:)]) { | |
[cell setLayoutMargins:UIEdgeInsetsZero]; |
import Foundation | |
class Foo { | |
let length = 255 | |
// !!! not like this because self.length can't be used here | |
// var arrayConstantLength = [Byte](count:self.length, repeatedValue:0) | |
// but like this (with lazy I can use self.length constant) | |
lazy var arrayConstantLength:[Byte] = { |
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.
Command Line
pry -r ./config/app_init_file.rb
- load your app into a pry session (look at the file loaded by config.ru)pry -r ./config/environment.rb
- load your rails into a pry session
Debugger
Storyboard Segues initially seem like a pretty cool way to construct interfaces using minimal glue code. But actually, ordinary nibs already support this, and in a much more flexible way.
Certainly, a Storyboard lets you bind a button action up to display a view controller with no code, but in practice you will usually want to pass some data to the new controller, depending on which button you used to get there, and this means implementing the -prepareForSegue:sender: method, which rapidly becomes a giant if/elseif statement of doom, negating most of the benefit of the codeless segue:
- (void)prepareForSegue:(UIStoryboardSegue *)segue sender:(id)sender
{
if ([segue.identifier isEqualToString:@"modalSegue"])
{
ModalViewController *controller = (ModalViewController *)segue.destination;
controller.someProperty = someValue;
Ideas are cheap. Make a prototype, sketch a CLI session, draw a wireframe. Discuss around concrete examples, not hand-waving abstractions. Don't say you did something, provide a URL that proves it.
Nothing is real until it's being used by a real user. This doesn't mean you make a prototype in the morning and blog about it in the evening. It means you find one person you believe your product will help and try to get them to use it.
// | |
// NBResponderChainUtilities.h | |
// | |
// Created by Nicolas @ bou.io on 19/04/13. | |
// | |
#import <UIKit/UIKit.h> | |
@interface UIView (NBResponderChainUtilities) | |
- (UIView*) nb_firstResponder; // Recurse into subviews to find one that responds YES to -isFirstResponder |