Table of Contents
- Structure: Architectural Patterns
- Process: Information Flow
- Programming Principles
- Design Patterns
- Solopreneurship and Indie Development
Behind the Scenes
- The Archive
- General Things About Programming and Stuff
I tend to think about two parts of the architecture that depend on each other: "structure" and "process". The former is about statical snapshots and most patterns; the latter is about the design of information flow, control flow, and message passing.
- When You Code, You Design Both Structure and Information Flow sums this up.
- Try to draw more diagrams!
Structure: Architectural Patterns
- Plain Swift Objects
- Plain Controllers to Help View Controllers. You can always add a new service type to perform a task, and then delegate from view controllers to that. I have the feeling this needs to be repeated more often. An app doesn't just live in its view controllers.
- Iteratively Improving Your App: Decoupling Components at Module Seams and Adding Facades
- Framework-Oriented Programming: this is really about larger modules, and how to box them in to make cohesive parts to use in apps.
- Layered Architecture
- VIPER (View–Interactor–Presenter–Entity–Repository)
- Separate Read Model from Write Model to Support Complex Forms; it's a simplistic take on the topic, but nevertheless could get you started thinking along the lines of CQRS.
Process: Information Flow
- 5 Heuristics for "I have a complicated nested view controller setup. How do I handle passing data?"
- Unidirectional Data Flow
- ReSwift Actions and UI Events
- Handle Pending File Changes with ReSwift using "pending" states.
- How I Avoided Over-Architecting a Simple Event Handler with ReSwift, Cheating with Existing Reactive Code. Instead of doing All The Things in ReSwift (which is like redux.js), I went with keeping the flow in my Application layer of code, where RxSwift/reactive code lives.
- Reactive programming is all about making the flow obvious to the reader.
- 3 RxSwift Building Blocks of UI Components: input and output ports of types in the UI layer map to Observer and Observable, and mutable properties can be expressed as well. This piece shows how.
Learning to do things in Swift, the nice way:
- Magic Numbers Represent Concepts, you just have to name them!
- Single Responsibility Principle
- Tell, Don't Ask
I argue that design patterns are not software architecture. They are practical for your daily work, and to express the information exchange between a couple of objects in a succinct way. But they cannot inform you about the structure of your application, why and how to decouple modules, or what a module is in the first place. That's higher-level thinking you need to do in a different kind of mind-set.
- Iteratively Improving Your App: Decoupling Components at Module Seams and Adding Facades – the nice thing about a façade is that it can be added without cost, and you can transition to using it in client code immediately.
- MVVM Primer – it's a "model of the view", not "a model for the view" in my understanding.
- Decouple UI from Model with View Models and Controls is a practical intro to the term "view model" and how you can change it from a controller (or "control").
- MVVM Is Quite Okay at What It Is Supposed to Do – not as smashing a statement as other folks tend to propagate, but I still think it nails down the problem really well: people expect a design pattern like MVVM to do far to much.
- MVVM's Place in Your App should be very confined. It's just glue code between view objects and application logic. (It is not, for example, your database.)
- As generalization of the above, Do Not Apply Code Heuristics When You Need a Broader Perspective talks about the problem of applying code-level tricks to much higher-level problems.
- Testable Singleton in Swift
- Strategy Pattern using blocks/closures
- The "Cake Pattern" is useless in practice
Solopreneurship and Indie Development
- My book: Make Money Outside the Mac App Store
- App Pricing and How to Make More Money
- Being Afraid to Change a Working App
- To Subscribe or not to Subscribe? A guest post uncovering the phrases of the advocates of the subscription model of payment.
Behind the Scenes
- Being Afraid to Change a Working App: it's a bit more personal than the usual data-sharing.
- Coding TableFlip: the Bigger Picture
- Splitting Up the Monolithic View Model and an aftermath
- Putting TableFlip on the App Store because I wanted to see how bad it really is, and if it makes a difference for my business.
General Things About Programming and Stuff
- Programming Does Not Grow Up: the amount of programmers grows just too quickly to have enough experienced people teach the newcomers about best practices. Programming, in this regard, is very much unlike traditional crafts.