The Builder design pattern is often overlooked, I find. Apart from plain builders, in Ruby I found that some us it like a configurator. You can use a configuration object in Swift in the for of block parameters, for example: This would make the internals of ComplexThing configuratable through the block. Instead of messing around with an instance of a ComplexThing, you can do atuff with the configurator which determines how the instance will look.
I watched an AltConf about API design the other day. I cannot seem to find which talk it was, though. Anyware, the presenter talked about using parameter objects when the parameter list grows too long or is open for change in future versions. Parameter objects can change internally and evolve with the API. You can add or remove attributes, for example, while the API calls of old client code don’t have to change: they still pass the same type in. That makes framework updates a bit less painful because method signatures stay the same.
When I wrote about MVVM with a “control” which really was a presenter, the view in question displayed some kind of data. Any sufficiently complex view would do, but the example focused on a view controller which consisted of a single composite view. UITableViewControllers are a different kind of beast, though.
I read a post by Erica Sadun about making try? more useful. This new variant of the keyword transforms thrown errors into nil. That can be convenient, but it doesn’t help handle the errors. Erica proposes a wrapper which logs errors. I like that idea and take it a step further.
I really like the power of enums in Swift, so I was naturally inclined to see what the presentation “Simplifying Login with Swift Enums” by David East had to offer. Here’s the setting: you’re going to offer multiple ways to authenticate users with your app. How do you model this?
View Controllers should only be responsible for view lifecycle events, Marcus Zarra reminds us. That means they should populate views with data, and show and hide them – stuff like that. View controllers should not do the work of views.
While I like his overall advice, it contains a few problematic points:
Put Core Data out of the view controller. His solution to provide a single data source tied to a NSManagedObjectContext will not scale well as I’ve experienced. – Still, don’t tie it to the view controllers. That makes matters worse.
His definition of “business logic” is odd. Business logic is not reducible to I/O code. It’s not just about fetching data from a device and doing network requests – except when your app is a very, very simplistic display for data with CRUD operations. Business logic can exceed data-centric rules and entail a real domain with complex behavior without much imagination.
Views should be responsible for displaying data, agreed. Since validation problems will be presented to the user, validation error messages will be part of that data, too. But views should not validate. Validation rule objects (WWDC’14 talk) should be the strategies that do validation.
If we create an object to sit between the view and the view controller then we are creating unnecessary additional objects.
Where do presenters sit? Between view and and view controller – but they make it easier to read and extend the code. They’re hardly unnecessary.
I strongly believe that it’s impossible to give advice about how to code and architect something if the problem domain isn’t part of the example. Because everything depends on the problem space in the end.
Remember to take every advice with a grain of salt. Collect things like Marcus’ tips to obtain new tools, but don’t take the tool for the solution of modelling a program to solve real problems.
They didn’t use the ? because Ruby method names usually have a postfix question mark when they return a boolean; also, they will have a postfix bang when they mutate the receiver. This would’ve led to confusion.
Since Swift came out, I haven’t used Ruby a lot, really. I still use it for all my scripting needs, but coding real applications? Rarely. I really like strong typed languages for that: leaning onto the compiler for refactorings and such.
To debug my threading issues and help bring forth future problems, I have created a simmple object that slows the current queue down:
letIsRunningTests=NSClassFromString("XCTestCase")!=nilstructQueueJigglePoint{/// Randomly interfere with the thread.staticfuncjiggle(){guard!IsRunningTestselse{return}#if DEBUGusleep(2*1000000)// 2 seconds#endif}}
I got this idea from Brett Schuchert on pages 188–90 of Uncle Bob’s Clean Code. A Handbook of Agile Software Craftsmanship. There, interference with traditional threading should randomly sleep, yield, or fall through. Enqueued blocks are a lot less volatile, so I only came up with sleeping.
Randomizing the sleep interval is up next. But a fixed number of 2–10 seconds helps find UI-blocking code already.
Just throw in a QueueJigglePoint.jiggle() in NSManagedObjectContext.performBlock executions, when dispatching async to the background, or when reading files, for example.
Recently, I was discussing adding a feature to an application which is about event creation and booking. The project manager has a strong database background and works on the schema himself. The schema is also his go-to tool to express changes in the features. But thinking about the real Domain in terms of objects revealed much, much more.
Recently on Google+, someone recommended Wallace Wang’s Swift OS X Programming for Absolute Beginners. Well, I’m not a beginner anymore, but the book sounded fun, so I gave it a spin. And I’m quite impressed. That’s why you read the review here. In short, Swift OS X Programming for Absolute Beginners (or SOXPAB as I would like to call it to save myself from typing that much) is the best programming book to teach the reader about user interface programming. I can’t honestly judge how well this textbook will actually work for non-programmers. But that’s because I can’t fathom learning to code from a book anyway. If you know programming, or the Cocoa APIs already, this should work for you.
It seems the Unit of Work I envisioned is not the one I need. It seems Core Data calls NSManagedObjectContext a “context” for a reason. It doesn’t suffice to set one up and pass it to every data store. At least not if you perform changes on background queues and with nested contexts.
I ran into problems with my Core Data Unit of Work/Transaction implementation the other day. I was not exercising good NSManagedObjectContext hygiene and end up with conflicts from time to time. Race conditions. Hate ‘em. The problem is that the parent–child setup of Core Data managed object contexts seems to work just fine for so-called “scratch pad” contexts: create a new child context, perform changes on in, then discard, or save to pass changes to the parent context.
This year, the team of Texts, Brett and I teamed up to bring you the best minimal writing product bundle for the Mac. It’s designed to get you through NaNoWriMo: the accompanying guide tells you how to make the habit of writing stick and how to get most out of the apps.
The lineup of apps:
Texts for focused writing (even on Windows PCs!)
Marked for previewing and reviewing
Word Counter to increase your productivity
BONUS: iThoughts X (coupon for 30% off) to plan the plot with Mind Maps
BONUS: Minimal Writing on the Mac guide
I use these apps myself to write, so creating this bundle was a no-brainer and a very exciting experience – oh was I busy! – but more on that later.
The Productive Writer’s Bundle is a sexy deal at more than 50% off, for $25 instead of $60 – for every author, be it novelist or non-fiction technical writer.
