Chris Eidhof of objc.io put some experimental code on GitHub where quite a few Cocoa view components are contained by classes he owns himself. The AppDelegate is super instructive: Your Cocoa app needs an NSApplicationDelegate. But it doesn’t have to do anything except route events to the proper collaborators. Still it’s the first object we usually put logic in only to (hopefully) refactor it out later.
Watch Saul Mora’s AltConf presentation “Object-Oriented Functional Programming: The Best of Both Worlds!” to learn more about real world use of bind and other functional concepts in object-oriented programming. His examples are really good.
In “What’s New in Storyboards” of WWDC 2015, we’re presented with implementations of unwind segues. Now I’ve stated part of my concerns with segues and app architecture already. The sample code was very straight to the point:
One thing that repeatedly messes up the conceptual purity of a view model is figuring out which entity should be mutated upon user interaction. Part of this purity stems from the fact that a view model is best served as view data to stress that it doesn’t contain much (business) logic. Making the data mutable introduces a lot of problems figuring out what that view model really is.
There’s an excellent overview of MVC, MVP, MVVM, and VIPER in iOS with sample codes by Bohdan Orlov of Badoo I recommend you read.
There are two main takeaways:
UIViewController belongs into the user interface layer and is, in fact, a composite view itself. That’s confusing at first because of the name. This insight will liberate you from thinking that a view controller is sufficient to glue data to UIKit components. There’s room for a whole application between these two.The VIPER example is exceptionally good. It takes VIPER’s heritage of Clean Architecture and Hexagonal into account and defines the Interactor through an output port. In that way Bohdan’s sample code is more east-oriented and cleaner than what you’d usually find on the topic:
protocol GreetingProvider {
func provideGreetingData()
}
protocol GreetingOutput: class {
func receiveGreetingData(greetingData: GreetingData)
}
class GreetingInteractor : GreetingProvider {
weak var output: GreetingOutput!
func provideGreetingData() {
let person = Person(firstName: "David", lastName: "Blaine") // usually comes from data access layer
let subject = person.firstName + " " + person.lastName
let greeting = GreetingData(greeting: "Hello", subject: subject)
self.output.receiveGreetingData(greeting)
}
}
Usually, you’d model provideGreetingData() as a function that returns the data to the caller. This will cause trouble in async processes of course.
You see in the full example that the amount of types seem to explode. Don’t be afraid of that as long as you can assign each type a specific responsibility. Then it won’t turn into the mess everyone seems to be afraid of.
Having used VIPER in apps myself, I see a problem with the names, though. XYZInteractor and XYZPresenter aren’t much better than XYZController in terms of expressiveness. On top of that, a concrete Presenter is always modelled to act as event handler, too. Don’t let this fool you into thinking you absolutely have to do this yourself – there’s always room to separate writing from reading operations, or event handling from view population.
Today I’m proud to announce the release of my e-book Make Money Outside the Mac App Store!
Get it for $25 $19 until Dec 24th from my store!
Shaving off VAT and then again 30% for Apple for every purchase of your app in the Mac App Store can be madness: the only real benefit is that people know how to operate the store. But if you’re just starting to run your business, discoverability is hardly a feature.
Instead of drowning in the warehouse that the app store is, put your software in your own store. You have to build an audience anyway to get started. So stay in touch with them. Know your customers. And stop giving away 30% for a promise that doesn’t hold.
Take a look at the details page for more info.
This book will save you hours of research and days of fiddling with SDKs. It shows you how to set up products for sale on FastSpring including automatic license code generation and then guides you through the process of adding license verification to your app.
Don’t need all the explanations? Just follow the setup steps and copy the code into your project and you’re ready to roll in half an hour!
I’m not affiliated with FastSpring. I just think their service is awesome.
Here’s what FastSpring’s CTO Mike Smith has to say about the book:
We appreciate Christian’s efforts in creating a guide that enables Mac developers to sell applications through FastSpring’s award-winning e-commerce platform. He has provided detailed instructions to help developers configure key elements of their online sales process. The spirit of community captured in his book reflects FastSpring’s mission to connect people globally in the digital economy.
I truly believe in the spirit of community and I believe you can make it as a developer without the App Store. This book is here to empower you so you don’t have to figure out all the scary details.
So many other indies rely on FastSpring, too, including:
Get to know their stories from this book. Be inspired and take the leap.
Because I think it’s so worth your time as a Mac developer, get it for 25% off until Christmas when you buy from my store.
Yelp reuses a setup of modular table views across their huge app. A simple timeline entry can be composed of 5 cells, each with its own model representation. These cells are used to create various component setups. What I find most interesting is the combination of registering cells for reuse identifiers in one place and using reuseIdentifierForCellAtIndexPath in another.
In a top secret project I am working on, I think I found a consistent way to create UITableViewControllers in a reusable fashion without making a mess with massive view controllers. The key ingredient is, as always, delegation from the view controller and thus composing larger components: