The Word Counter received a huge update this week. It now allows you to monitor files. That means you can create a record of your project progress. The usual words-per-hour meter will tell you how well you perform, while the file monitor can tell you how far you’ve come.
The new monitoring view with my current writing projects
I’m excited to finally release this update. I think it’ll help motivate a lot of people to make progress and marvel at their current achievements.
Up next is a graphical representation of all this, because visualizing helps to see progress, obviously.
If you have trouble downloading the update, please get a fresh download from the website. This will probably affect a lot of people. I’m very sorry for the inconvenience!
I got burned this week. Pretty bad. I shipped a small bugfix release for my Mac app Word Counter a couple of days ago to prepare for the “big one” coming this week. Naturally, I built that version on my El Capitan dev machine. I pushed the update to my server. Updates using Sparkle worked. – But now users of that version cannot ever update to the next version. Because I haven’t thought about ATS.
I got angry at NSOpenPanel the other day for visually blocking NSAlerts, and for staying in the way when the debugger hits a breakpoint. Silly me, I used ye olde runModal. When you use the block-based API of NSSavePanel or its decendant NSOpenPanel, all of a sudden they will display on top, but only per application. Also, alerts seem to have a higher display level in these cases.
Integrating new functionality is fun. But revisiting 18-months old code isn’t. Back then I created a protocol InvokesWindows to define methods like -showPreferencesWindow which I imported in the menu bar controller to show the preferences when the user selects a pop-up menu item. But I didn’t actually delegate to any instance of InvokesWindows. I used NSApp. (Insert facepalm here.)
For the upcoming Word Counter upgrade, I developed a new feature module in isolation. The outcome is very interesting, as I am including it as a Swift module, that is as a real framework, into the existing app. I need some more time to write about the resulting architecture, but I found the module boundary to be really helpful. Today, though, I want to share my ErrorHandling code.
To test the Word Counter during development, I have long used a special build target. But that doesn’t scale well if all I want is change a preprocessor macro to switch from file-based to in memory storage, for example. I’ve never played around with build configurations in Xcode. They work well with Schemes, though, and setting up a build configuration and a scheme is much less overhead than maintaining a custom target.
So you miss declaring optional methods in Swift protocols? Joe Conway
got you covered: “optional methods can be implemented by providing a default implementation in an extension.” But there’s an even better way, in my opinion: ditch the notion of optional methods and use blocks instead.
From the department of Domain-Driven Design code patterns, I today present to you: well-named value objects! You can go a lot farther than you have previously imagined with value objects in Swift. Now that Swift is more than a year old, most of us have seen the use of struct and heard how useful passing objects by value is.
Lammert Westerhoff compared MVVM to Presentation Controls recently. Since nobody likes massive view controllers, I had a look, too, and found a few interesting things. To write a real app with his tips in mind, we’re going to need a bit more, though, and refactor things a bit.
The test project I work on to develop a component of the Word Counter faster sets up a lot of service objects during launch. I shaved off 60 lines of AppDelegate by introducing bootstrapping as a thing to my code. This way you can prepare a list of Bootstrapping components and iterate over them to set up one after another.
The Unit of Work pattern is a code equivalent to database transactions: when it completes, changes are persisted; when something fails, changes are rolled back. That’s handy to perform a set of changes and have them saved. Sooner or later during app development using Core Data, you may ask: when should I save? When is the best point in time?
Move!, my personal favorite productivity and health enhancement app (and, apparently, my own creation), is now available on MacUpdate. Check it out for free if you haven’t already.
I created a generic CoreDataFetchRequest a while ago and love it. It casts the results to the expected values or throws an error if something went wrong, which it shouldn’t ever, logically – but the Core Data API currently returns AnyObject everywhere, so I have to deal with that.
It happens that just yesterday I read about architecture smells in code. Among the examples was “subclasses don’t redefine methods”. In my post about Core Data and expressive domains earlier this week, I did just that: create a Egg subclass of CoreDataEgg to inherit CoreDataEgg’s behavior. That’s not what abstraction to superclasses is meant to do.
I’ve written a whole book on the topic of architecting a Mac app using Core Data. Today I found an approach which doesn’t add lots of overhead and which also doesn’t clutter everything everywhere. It’s pretty simple and involves Swift.
In an execellent book on Domain-Driven Design that I’m reading in my spare time, they make a lot of use of domain events. I’ve written about a strongly typed publish–subscribe infrastructure in March already to get you started. Some of the book samples include what seems to be ad-hoc event subscribers. I try to port that to Swift.
So UISplitViewController is the new default for iOS apps. Most iPhones have compact-sized size classes. iPads have regular sized ones. The iPhone 6(s) Plus mixes both. Only horizontally regular-sized environments show both the master and the detail scene (or primary and secondary view controller).
