I found the Foundation way to check for file existence very roundabout. It returns 1 boolean to indicate existence and you can have another boolean indicate if the item is a directory – passed by reference, like you used to in Objective-C land. That’s a silent cry for an enum. So I created a simple wrapper that tells me what to expect at a given URL:
Shopify published amazing/epic stats for their Ruby on Rails “app”:
Makes you wonder:
Swift changed the game a bit. Now it’s very convenient to create a new type. You don’t need to do the .h/.m file dance anymore but can start a new type declaration wherever you are. (Except when you’re inside a generic type.) That makes it more likely we devs stop to shy away from smaller types.
But it’s still a job for our community’s culture to unlearn coding huge classes (massive view controller syndrome, anyone?) and splitting stuff.
Ruby has a long tradition of super-focused methods and very small classes. Swift is just as terse and powerful in that regard. Now it’s your turn to experiment with writing types for very simple tasks. Like the Extract Parameter Object refactoring, where you lift things that go together into a new type.
Can be as easy as writing:
struct DateRange {
let start: Date
let end: Date
}
Et voilà, there you have a new explicit concept in your code base.
Let’s say you have a Presenter that creates a ViewModel for its View from incoming data and then presents it in said view. In this case, the Presenter also is a ReSwift.StoreSubscriber for good measure, but it could receive the data by any means, really.
frameworkoriented.io hosts a text on “Framework Oriented Programming” (FOP). That title already looks similar to “Object-Oriented Programming”. But it’s not a replacement, mind you; it surely means the same for our cause as Cocoa UIKit/AppKit developers. The shift in perspective from object to framework works very well to illustrate the problem of designing large code bases.
I use a logging middleware in all my apps that use ReSwift. I love to see the event log. It makes me think the app is healthy when it tells me what’s going on. All this happens when I start the knowledge management app I’m working on in about half a second (reformatted a bit to make reading easier):
Let’s say you write a plain text editor that can work with multiple text files at a time. As a backbone for processing information, you use ReSwift to model the data flow in a clean fashion. The user has 10 files open, changes the text in 1 file’s tab. The user leaves the text field and your awesome autosaving is triggered.
I have no clue how you create drawing apps. I guess your primary concern is low latency and good-looking results rather than making the most of cool new architecture patterns like VIPER. It’s a real-time thing. Not unlike games, I imagine. Still, “in between years” (between Christmas and New Year; but I like the literal German translation), I took a day or two to come up with a conceptual implementation (MIT licensed).
In a client meeting yesterday we tried to figure out how to animate scene transitions with swiping left/right when ReSwift is the single source of truth of the app state. What goes into the app state? How do you animate that? Should the % of the transition be part of the app state for some reason? (Spoiler: Nope.)