##Xcode Locations
###Xcode Provisioning Profiles:
~/Library/MobileDevice/Provisioning\ Profiles
###Xcode Font and Color Schemes:
~/Library/Developer/Xcode/UserData/FontAndColorThemes
- (void)viewDidLoad { | |
UISearchBar *searchBar = [[UISearchBar alloc] initWithFrame: CGRectZero]; | |
self.searchController = [[UISearchDisplayController alloc] initWithSearchBar:self.searchBar contentsController:self]; | |
self.searchController.delegate = self; | |
// Place it in view | |
searchBar.delegate = self; | |
} | |
- (void)searchBar:(UISearchBar *)searchBar textDidChange:(NSString *)text { | |
self.searchResults = [self search: text]; |
@interface ApplicationDelegate<UIApplicationDelegate> | |
@end | |
@implementation ApplicationDelegate | |
- (RACSignal *)rac_registeredForRemoteNotifications { | |
RACSignal *signal = objc_getAssociatedObject(self, _cmd); | |
if (signal != nil) return signal; | |
RACSignal *didRegisterForRemoteNotification = [[self rac_signalForSelector: @selector(application:didRegisterForRemoteNotificationsWithDeviceToken:) fromProtocol: @protocol(UIApplicationDelegate)] map: ^(RACTuple *tuple) { | |
return tuple.second; |
// | |
// UIView+Orientation.h | |
// | |
#import <UIKit/UIKit.h> | |
// These macros should only be used if you MUST know the interface orientation for the device itself, for example when displaying a new UIWindow. | |
// This should be very rare; generally you should only look at the immediate parent view's size (or "view orientation" using the category below). | |
#define StatusBarOrientationIsPortrait UIInterfaceOrientationIsPortrait([[UIApplication sharedApplication] statusBarOrientation]) | |
#define StatusBarOrientationIsLandscape UIInterfaceOrientationIsLandscape([[UIApplication sharedApplication] statusBarOrientation]) |
##Xcode Locations
###Xcode Provisioning Profiles:
~/Library/MobileDevice/Provisioning\ Profiles
###Xcode Font and Color Schemes:
~/Library/Developer/Xcode/UserData/FontAndColorThemes
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/
A lot is being written these days about ReactiveCocoa and the paradigms it introduces. In my opinion, there are only two sides giving their opinion: the ones that know a lot about it and are therefore obviously biased, and the ones that refuse to learn it.
I decided to write something myself because I think I'm right in the middle. Some months ago I knew nothing about it, and now I know enough to want to use it every day. I hope that by not being an expert, I can actual introduce a few really simple ideas in a much easier way to pick up by new-commers, to show why I think ReactiveCocoa is an incredibly powerful tool to help us write better, cleaner, and more maintainable code.
The base of everything that happens in ReactiveCocoa is signals. I'm going to try to explain what they represent and why they fit in the way we think about what happens on an app. A lot of the things you may read about Functional Reactive Programming end up confusing you when
// Created by Tony Mann on 3/22/15. | |
// Copyright (c) 2015 7Actions. All rights reserved. | |
// | |
// Adapted from http://ossh.com.au/design-and-technology/software-development/implementing-rich-text-with-images-on-os-x-and-ios/ | |
import UIKit | |
class ImageAttachment: NSTextAttachment { | |
var verticalOffset: CGFloat = 0.0 | |