All about fighting malware extensions. Not just on Windows stable, but Windows dev and all OS X soon.
Open Always Wins!
All about fighting malware extensions. Not just on Windows stable, but Windows dev and all OS X soon.
Open Always Wins!
| TL;DR | Use standard "Import Framework" in Swift instead of the Obj-C bridging header for Obj-C Cocoapods with use_frameworks! in your Pods file |
|---|
| Versions: | OS X 10.10.3 | Xcode 6.3.1 | iOS SDK 8.3 | Cocoapods 0.36.1 |
|---|
This just wasn't obvious at all. I've been using Swift & Cocoapods < 0.36 since Xcode 6 shipped. While versions < 0.36 did not work with a Swift framework like Alamofire, you could use Objective-C pods and let them get compiled as a static library as long as you used the Objective-C bridging header to import the header(s).
With Cocoapods 0.36 and above, you can have Swift frameworks as Pods. To make that work, you have to put the use_frameworks! keyword in your Pods file. My brain misunderstood Use frameworks instead of static libraries for Pods because it automatically inserted for Swift before the Pods in that sentence.
Took me a couple hours this morning to work out all my Pods might be framworks. I'm not the first person to figure it out, just a few days ago, Johannes Luderschmidt published a blog post with the solution which put on the right path. All Pods using use_frameworks! are frameworks, not just the Swift pods. A problem like this is where experience with Xcode can really work against you. You start tweaking Header Search Paths, Framework Search Paths, User Header Search Paths, and the Always Search User Paths (docs: disabling it is strongly recommended) settings in desperation because that's usually where these problems lie. Especially when the first compiler error in your project after putting use_frameworks! in your Pod file is that the header for come Objective-C pod can’t be found.
But that’s totally down the wrong rabbit hole. I’m using the Obj-C MBProgressHUD Pod. What you need to do is:
You're now using bona fide frameworks, so your enums have moved in flight! You might have a line of Swift that was fine with the bridging header like this:
progressHUD.mode = MBProgressHUDModeIndeterminate
That now has to become this:
progressHUD.mode = MBProgressHUDMode.Indeterminate
Not to big a deal, but the pile of errors might lead you astray that you have a bigger problem than you do if you’re using a lot of Obj-C enums.
| TL;DR | 645 Unread | 25 Archived | 1 Starred |
|---|
I've had an Instapaper account since 2008 when Marco Arment launched the service until now. I haven’t been using the account for most of the last 2 years, with my last save in June 2014, the only one the whole year.
So I deleted my account. Finally!
The idea never really worked for me, even though I was very excited about it. I’ve always been a news junkie. My routine is daily RSS reader, hourly Twitter timeline, Facebook News Feed mostly on weekends, and daily manual reading of a number of sites. The idea of a service that could generate a newspaper like thing for me to read later seemed great. But I realized that after I went through my usual news reading routine, my attention was exhausted.
Instead, I used Instapaper as a bookmarking service for “important stuff”, longer form deeper think pieces I thought I absolutely had to know and would get to later. That also turned out to be untrue. Out of the 671 links I added to Instapaper, how many did I actually read? 26! 3.8%. That’s way lower than even I expected.
I’ve been using the Reading List feature built-in to Safari on iOS and OS X, but it’s where links kind of go to die for the same reasons as Instapaper, I just don’t go there, does’t fit into my routine. Bookmarks are a similar story, only the Bookmarks on my favorites bar see any action.
What I think I might need is something to save links grouped by research topic, not just one big list. Bookmark Folders kind of serve that purpose, but it’s not really an elegant or searchable tool.
I’ve also kind of become one of those people on a desktop browser that just leaves a browser window open per topic with tabs for each site until I’m ready to deal with it. Safari does an excellent job of keeping this state at the ready in my Dock on OS X.
| Versions: | OS X 10.10.3 | iOS 8.3 |
|---|
We’ve been calling functions or methods on objects the same since at least C appeared in 1972. You declare & call a function like this:
int main(void) {
printf("hello, world\n");return 0;
}int value = main();
To define, the return type is declared before the name of the function. On call, a variable is declared to hold the return value of the function call.
In Swift, you declare a function with a return type like this:
func printAndCount(stringToPrint: String) -> Int {
println(stringToPrint)
return countElements(stringToPrint)
}
I loved this change to the C convention. IMHO, the information importance follows the order you declare the function: name, parameter type(s), and return type(s). However, you still call that function like this:
let count = printAndCount("Hello, playground")
This feels like a job half done, a little bit like the tail wagging the dog
I nearly always know the name of a function or method I want to call before I know its return types.
Wouldn’t it be great if the language was fully adapted to the pervasiveness of autocomplete?
Imagine the amount of time you’d save if you could start typing the name of the function or method first and let autocomplete show & then fill in the return types?
I’m proposing that variables that are assigned the return value of a function should come after the function call using a return arrow. It would look something like this:
printAndCount("Hello, playground") -> let count
With methods, it would look like this:
someObject.printAndCount("Hello, playground") -> let count
The actual syntax is up for debate, but I’m excited by the idea. I don’t know of another language that does this.
I’m betting the pros would outweigh any cons, and this feature would greatly increase the usability of the language and editor together.
| TL;DR | Call something like [self.view addSubView:moviePlayer.view] before [moviePlayer prepareToPlay] |
|---|
| Versions: | OS X 10.10.2 | Xcode 6.2 | iOS SDK 8.2 |
|---|
I just inherited some code previously compiled against iOS SDK 6.0, ran fine through iOS 7, but crashes on iOS 8.x. Here’s the crasher:
NSURL *url = [NSURL fileURLWithPath:[[NSBundle mainBundle] pathForResource:@"impact_of_needs_goal_planning@1x" ofType:@"mp4"]];
self.moviePlayer = [[MPMoviePlayerController alloc] initWithContentURL:url];
self.moviePlayer.shouldAutoplay = NO;
[self.moviePlayer setControlStyle:MPMovieControlStyleNone];
[self.moviePlayer.view setFrame:CGRectMake(0.0, 0.0, 1024.0, 748.0)];
[self.moviePlayer.view setTag:7];
[[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(movieDidLoad:) name:MPMoviePlayerLoadStateDidChangeNotification object:self.moviePlayer];
[self.moviePlayer prepareToPlay];
App was crashing on the last line, [self.moviePlayer prepareToPlay]; every time it was called.
This is a guess (because installing an iOS 7 simulator is taking forever), but it looks like iOS 7 and below didn't care because the app was working fine. iOS 8 crashes.
The solution is adding the moviePlayerController to a parent view before calling [self.moviePlayer prepareToPlay];, like this:
[self addSubview:self.moviePlayer.view];
Given this is The Right Thing To Do™, I'm actually surprised it ever worked!
Turns out this was not the cause of the crash, which I have yet to nail down. This change did seem to temporarily solve the crash, but alas it is something to do with NSNotifications :’(
| TL;DR | Use the item property on NSIndexPath for UICollectionView instead of row from UITableView |
|---|
Just realized I littered a UICollectionViewController with calls to indexPath.row when I should have been using indexPath.item. I didn’t see any bad behavior, but should use the right property for the job!
Reference:
| TL;DR | Click the Debug -> Location -> Apple menu. |
|---|
| Versions: | OS X 10.10.2 | Xcode 6.1.1 | iOS SDK 8.0 | iOS Simulator 8.1 (550.3) |
|---|
| TL;DR | Remove the / do not add a call to... self.collectionView.registerClass in viewDidLoad |
|---|
| Versions: | OS X 10.10.2 | Xcode 6.1.1 | iOS SDK 8.0 |
|---|
Let’s say you created a UICollectionViewController in a Storyboard or a UICollectionView in a plain old UIViewController. You’re confident, not cocky, but you know Apple’s pattern on this pretty well, so you go ahead and customize the first cell, nothing that requires code, and then add a second cell that you expect to set properties on, so it might look like this:
| Obj-C | [self.collectionView registerClass:[UICollectionViewCell class] forCellWithReuseIdentifier:reuseIdentifier]; |
|---|---|
| Swift | self.collectionView!.registerClass(UICollectionViewCell.self, forCellWithReuseIdentifier: reuseIdentifier) |
If you've customized the stock UICollectionViewCell in your Storyboard, the cell with the matching reuse identifier in code will cause UICollectionView to load an empty UICollectionViewCell! If you went full steam ahead and added a bunch of custom cells with matching reuse identifiers and registerCell calls in viewDidLoad, you, ah, might not figure this one out for a while.
No article or blog post has ever captured how I feel about Javascript like a JS framework on every table.
It’s not like I hate Javascript, but with limited time to invest in learning stuff outside the Apple stack, the constant turnover in JS frameworks means nothing ever really rises above the level of noise for me.
Except Angular.js! Looked like that had some heat, some staying power. Too bad Angular is breaking compatibility between 1.3 and 2.0. I’d heard many good things and even dabbled with it on a project, and thought it might be time to dive deeper, but now…*sigh*