Jeff Kelley’s new book is short. How short? Under a hundred pages short. That’s because it’s part of Pragmatic Programmer’s new Pragmatic exPress series. Developing for the Apple Watch ($11 Ebook $17 Paper, $27 Combo) offers exactly what it says on the label, a quick, focused take on Watch development.
With only 100 pages to worry about, this is a terrific series for getting information to the market quickly and effectively. I love how Pragmatic is pivoting to handle Apple’s quick-change reality.
As for this book, there’s a lot to like (and a few tiny quibbles I didn’t care for). The table of contents hits all the sweet spots you’d expect for the topic. I like how Kelley organized his material, guiding you from over the core details of writing extensions, developing the UI, adding tables, and communicating with outside services.
I particularly liked the little chapter (just 7 pages!) called Quick Apple Watch Wins. It offers a really satisfying “just do this” taste of media playback and notifications.
The entire book is written in Swift, which I think is another wise move. Although Objective-C remains a more stable platform, readers really seem to want Swift content. Whether they’re already developing in Swift or just purchasing aspirationally, Swift seems to be language they want to use to communicate.
One thing I didn’t love (and this is because of OCD pedanticism) is Kelley’s use of we-voice, which drives me nuts. The writing is competent. It’s just a style I don’t particularly love reading.
Let’s get something more complicated done. We’re going to link these UI elements to our code, starting with the button, so that tapping the button has an effect in our app. We want to call a method in our code when the user taps the button, at which time we’ll change the text of the label.
For another, the examples in the UI discussion felt slighted by the quick coverage. The interfaces are fine and basic but it would have been nice to see some more examples that demonstrated the concepts he discussed.
Kelley says to use images and color effectively (“Another trick to making a great UI is to take advantage of images.” and “Another factor in making great-looking watch apps is effective use of color and type.“). I would have liked to see an image gallery of do’s and don’ts that concretely demonstrated these visual ideas instead of just including these vague suggestions as text.
Apart from these complaints, I really did enjoy my quick read. I’ve only superficially messed with WatchKit. Developing for Apple Watch: Your App on Their Wrists makes me want to clear up some time to dive in more deeply.
2 Comments
Thanks for the pointer, I’m buying it today.
I think I understand annoyance at the first-person plural: It combines bossiness and smarm, right? And if you use it all the time, it’s forced, and if you don’t, it’s distracting? And still I do it in my books (Xcode 6 Start to Finish, just out, thanks for the plug).
I have a reason. At the center is that first launch of Xcode intimidates many users. Auto Layout terrifies them. Not all, but there is more than one book because readers have more than one need. I’m the reader’s friend, I empathize, I hand-hold; while leaving space for him to tell himself that’s not what I’m doing. (That’s a matter of his dignity and patience; I really do care.) Related, I take a workflow (spiral) approach: It’s easier to be a helpful friend if you’re helping your friend get something done. (It’s also one of the books’ selling points, but that’s just a bonus.)
To the delight of my liberal-arts professors and the horror of some of my editors (there are stories), I write character and plot. Xcode is a character. Apple is another. The “narrator” is a teaching construct dressed up to look like me. The reader is the protagonist. As Vergil to his Dante, I am leading an “us” through the process. (See?! HUMANE EDUCATION!!)
I have to switch pronouns: _I_ have opinions and advice. _I_ introduce bugs and follow blind alleys, and cheerfully say I must not have been very bright. The reader fixes them, I talk her through it. That makes it a “we.” Some things (like long cascades of AL constraints) apply already-taught skills repetitively; I put them in the imperative (second person), minimal detail, rat-a-tat-tat, not just because it saves space and keeps the current topic in the foreground, but because her hard work has made her a WETSU badass.
There are many fine lines to this approach. Pronouns are a special case of preciousness. Being directive is part of the game, but I think it helps that it’s for a task the reader has bought into.
That’s my post-hoc argument, and I have no idea whether it’s responsive to your off-hand comment.
Eschew pluralis majestatis