Deep linking in iOS is all the hype. It’s interoperability opens up the platform both for developers and users. But it brings new transitions to the platform and with them new responsibilities to design your application.
The Apple Watch is all the hype since it gently reminds you to stand up and move regularly. That’s a very good thing. A gentle reminder won’t cut it for me. That’s why I created a solution which jumps right into my face.
Look at the project page of Move!.
It features responsive timers: when you don’t touch your input devices, the clock will not start to tick. Only when you sit down and work will the timer start and make you stand up soon.
Move! is now ready for El Capitan. The upcoming OS X update can come!
I found a very useful distinction by Matthijs Hollemans to grasp what protocol extensions in Swift 2 can be: instead of interfaces, they are traits or even mixins. At the same time, I want to raise awareness for misuse: just because behavior is mixed-in doesn’t mean it’s additional behavior. The code may live in another file, but its functionality can still clutter your objects.
I just found a shortcut to use Dependency Injection less during tests. In “Unit Testing in Swift 2.0”, Jorge Ortiz adapts solid testing principles to Swift. If you don’t have a strong testing background, make sure to watch his talk for key insights into the How using Swift!
I have written a book about releasing apps outside the Mac App Store. It comes with two fully working sample applications to cover checkout from within the app, licensing, and locking the app after a trial period.
It’s called:
Make Money Outside the Mac App Store: How to Sell Your Mac App with FastSpring, Secure It With License Codes Against Piracy, and Offer Time-Based Trial Downloads.
I’d love to have feedback on this.
If you want to help out, just shoot me a line at: hi@christiantietze.de
Thanks!
P.S.: The secret Leanpub page is here.
I have just discovered how cool the new guard statement is to keep unit tests lean and shallow – avoiding if-let nesting, that is. Update 2021-05-11: Modern XCTUnwrap is even better. Consider this test case: There are two optionals I have to deal with. That’s why I throw in assertions to cover problems. I don’t want to assert anything new here, though: the test helper soleFile() is valdiated in another test case already. But I need some kind of failure in case the Core Data test case goes nuts.
Swift 2 brings a lot of Cocoa API changes. For one, Core Data’s NSManagedObject’s executeFetchRequest(_:) can throw, returns a non-optional on success, but still returns [AnyObject]. While refactoring existing code to use do-try-catch, I found the optional casting to [MyEntity] cumbersome.
A UISplitViewController has a master and a detail view controller. When the selected item is deleted and the detail is visible, you can perform a segue. If the detail is not visible, performing a segue to change the detail will present it. I didn’t want that. There are two cases where you will want to change the detail although it’s not visible:
UISplitViewController is the way to go when you want to make your iOS app universal without much hassle and can model the scenes in terms of master/detail. While getting Calendar Paste ready for the upcoming iOS 9 release, I discovered that using UISplitViewController across devices is one thing, while Storyboard segues are another.
I banged my head against Xcode’s wall (which is my computer screen) today, trying to find the source of an EXC_BAD_ACCESS code=2 termination. Turns out it’s the Swift 1.2 compiler which doesn’t catch a problem here. The signature of the block causing trouble with the version shown above:
Again I was reminded about the value of service objects to encapsulate sequences in two places: the Domain, where business rules are kept, and in client code, where database management and transactions play a role. This distinction helps create clean code and deliver flexible components. I am building a feature for the Word Counter in a separate “library” project until everything runs smoothly. Then I’ll integrate the code into the main application. Since I consider this to be some kind of library, I thought I wouldn’t need many service objects, but I was wrong.
Writing clean code makes your life better in the long term, and I find it’s more fun initially. According to Bernstein, CLEAN is an acronym:
His book “Beyond Legacy Code. Nine Practices to Extend the Life (and Value) of Your Software” seems to be a good read. Not through, yet.1
Affiliate link; I get a small kickback from the vendor if you buy from my link but it won’t cost you anything. ↩
During summer, I have created a work break timer called Move! which really works. It gets in your way, it cannot be postponed. I created it to make me get up and stretch and do something else for a couple of minutes every half hour.
Sascha and I plan to add exercise instructions later. Right now, we’re happy to have a tool which forces us to get up every now and then and get healthy. (Backed by research, mind you!)
It will get on your nerves. Continue to take breaks when it tells you to.
You’ll hate it.
You’ll yell at it.
But it will make you feel better in the afternoon.
Do yourself a favor and try to do some diagonal stretches or a healthy 1-minute routine.
Download Move! on its dedicated page now and experience it for yourself.
The other day, I wrote a post about bind() and the >>= operator and how it can help chain function calls together. The example was a bit too contrived and making it fit the requirements left us with really bad code. I came up with an even better implementation: use plain Swift objects and express your intent carefully.