Chris Adamson:
It’s not like iOS isn’t meant to deal with asynchronous events. In fact, it has lots of different techniques… all mutually incompatible, owing to the long development of the Cocoa and Cocoa Touch APIs over the years, and the legacy of Objective-C.
[…]
So now let’s look at how ReactiveX deals with this. In Rx, things that change over time are offered as observables. […] So, where’s the rub? For starters, it takes a long time to get the hang of Rx, both to get into its mindset (it sucks when you just need to get the current value of something, but it’s an observable, so there’s no real concept of a “current” value). And then there are all the operators. Follow that link to the operators that I linked a few paragraphs back. There are over 70 of them.
[…]
In practice, there are lots of ways to mess this up. Are you right to only want one event? What if you forget to capture self weakly? The worse problem is when your closure is never called: setting breakpoints in this code will do nothing, so it’s a hair-pulling exercise to figure out if fooObservable is not producing events, or if your chain is screwing them up somehow.
[…]
In my experience, Rx turns out to be far more costly than it would originally appear from the propaganda. I can’t speak for my ex-employer of course, but my own takeaway is that 1) adopting Rx can take way longer than you’d expect, 2) RxSwift seems to really slow down the Swift compiler (possibly because of having to do a bunch of type inference through those chains of Rx operators).
Mark Lilback:
I don’t buy the idea of replacing everything with it. But use the right tool for the right job. For chained operations it is better than promises/futures and much better than callbacks/closures.
iOS iOS 10 Programming ReactiveCocoa Swift Programming Language
Adam C. Engst:
I’m sure many of you are nodding your heads in agreement, or wondering why I’m telling you all this. I’m no frequent flyer, so I’m sure that these improvements have been obvious to road warriors for a while. But I wanted to document how to do all this because I saw a lot of people still relying on paper boarding passes on that last trip. The experience of relying on an iPhone is so good, and so much better than dealing with paper, that if you’ve avoided it so far, I urge you to give it a try next time. But feel free to print a paper boarding pass as a backup until you’re comfortable with using your iPhone instead!
[…]
At the end of the check-in process, the apps I’ve used have provided a relatively clear Add to Wallet link or button. Tap it, and when it hands you off to Wallet, make sure everything looks correct in the boarding pass and then tap the Add link in the upper-right corner. You may or may not need to do this for each boarding pass; check to see what’s in Wallet after the first one. Now you’re ready for when you go to the airport.
I’d still want a paper copy in case my iPhone spontaneously shuts down. Also, sometimes they won’t let you swipe the pass yourself, and I don’t want to hand my iPhone to the attendant. I admit to not really appreciating the benefit of Wallet here. It’s an extra step to use, but then you can access the boarding pass from the lock screen instead of having to open the app. And maybe it saves you from having to rely on the airline app at the critical moment? I’ve twice had an airline app stop working after arriving at the airport but before boarding. So now I always take a screenshot of the boarding pass just in case.
iOS iOS 10 Travel Wallet
Eject (via Brian King):
One common pain point with Interface Builder is that as a view becomes more dynamic and is managed more programatically, Interface Builder becomes less helpful. This tool lets developers use Interface Builder without that concern, giving them an Eject button to hit when Interace Builder starts getting in the way, and provides an easy path to transition to full programatic view layout.
Previously: Working Without a Nib.
Auto Layout Developer Tool Interface Builder iOS Programming
Josh Centers:
On 15 March 2017, Dropbox will convert all Public folders on free accounts to private folders, breaking existing links. Dropbox now recommends using a shared folder or shared link for sharing files with others. Dropbox Plus and Dropbox Business users can continue to use the Public folder until 1 September 2017.
[…]
Although it’s annoying to lose the Public folder and its HTML rendering capability, Dropbox remains useful because it’s integrated so well into the Mac and iOS experience, and it just works.
Although, some of its recent behavior has been troubling. I just want a basic folder that syncs and doesn’t peg my CPU when there’s filesystem activity in an unrelated folder.
Previously: Dropbox Discontinues HTML Rendering.
Dropbox Sunset Web
Kirk McElhearn:
Auto-play videos suck. They use bandwidth, and their annoying sounds get in the way when you’re listening to music and open a web page. I happen to write for a website that uses them, and it annoys me to no end. (My editors have no control over those auto-play videos, alas.)
But you can stop auto-play videos from playing on a Mac. If you use Chrome or Firefox, it’s pretty simple, and the plugins below work both on macOS and Windows; if you use Safari, it’s a bit more complex, but it’s not that hard.
To do the whole thing from Terminal:
defaults write com.apple.safari WebKitMediaPlaybackAllowsInline 0
defaults write com.apple.safari com.apple.Safari.ContentPageGroupIdentifier.WebKit2AllowsInlineMediaPlayback 0
(Or substitute com.apple.SafariTechnologyPreview.)
Jason Snell:
I fought for six months to get those [videos] turned off. When I left, they turned ’em right back on.
Esoteric Preferences Mac macOS 10.12 Sierra Safari Video
