It’s not often that I make spur of the moment book purchases, so when I do, it’s a pleasant surprise when they turn out to be gems. The book I purchased on a whim is “Test-Driven iOS Development” by Graham Lee, and it turned out to be one of those “right place, right time” purchases.
I’ve been trying to seriously adopt a test-driven approach to my development projects for a while, but it never really stuck. And though I’d read the standard books on the practice, I still couldn’t get past the seeming futility of it. I know I’m not alone. Most developers philosophize about the merits of test-driven development, but not as many actually implement it, and fewer still on the iOS platform.
It’s hard for me to gauge whether Graham Lee actually brings something new to the discussion, beyond the iOS details, but something clicked for me when I got through this book and then started implementing some of his techniques in my work. I currently work on a project where one group does server code, a developer might do UI code and another write the code that makes REST service calls. These tasks are often done independently and at different times, so I might need to write iOS code to make service calls long before the server folks have a chance to write their end. It’s in this environment that I realized how valuable a test-driven approach could be.
Anyway, back to the book.
The opening chapters begin with the basics of unit testing: what is it, how to write one, and tools you can use. Xcode offers OCUnit, and that forms the basis of most of the book’s code, but the author also mentions other tools that can make your life easier.
The meaty part of the book begins in chapter 5, as an example app is described. The detailed test-driven development gets going from chapter 6 through 9, in which the author steps through every step of the process from data models, app logic and finally UIViewControllers. What I really loved about this book was the lack of magic “hand-waving”. He doesn’t do something really basic and leave you stranded when you actually try a real world task. Every part of the app is developed in the book and many of the gotcha moments are described and solved as the book progresses. Chapter 10 wraps up the project, filling in some missing spots, and then the final chapters address related issues like applying TDD to legacy code, and cutting edge techniques like Behaviour-Driven Development.
I was excited to see some of the advanced techniques Graham Lee offers in this book for testing objects. He explains how to use method swizzling in Objective-C to swap in your own implementations for existing behaviour, and using associative references to add bits of information to objects to assist in verification. I’ve used these techniques to write some cool unit test code now.
Aside from the technical knowledge I learned from this book, the biggest take-away for me was a shift in my concept of why I should be writing TDD code. It’s not just to test and verify code works. That’s important, but your unit tests also describe how your code should behave. This becomes important when you pass your isolated set of classes to another developer to use. Your unit-tests become a gold mine of information on how to use the code you just wrote.
I highly recommend Test-Driven iOS Development to all iOS developers. It will make you a better person.
I recently got my hands on a review copy of the new book, “iOS SDK Development”, by Chris Adamson and Bill Dudney. The book was just published at the end of November 2012, and it’s chock full of the latest techniques and technologies in Xcode and Objective-C.
The book is appropriate for developers who are new to the iOS platform, though the breakneck pace may be overwhelming. I wouldn’t recommend it for anyone brand new to software development in general. So if you’re an experienced developer and want to add iOS development to your toolbox, this is a great place to start. But it is not a “Learn to program” book.
As an experienced iOS developer, I was impressed by how current many of the concepts in this book were. Of course, they cover the basics like Table Views and hooking up UI elements, but they also introduce and demonstrate a lot of the newer SDK and language features too. They build interfaces with Storyboard and Auto-Layout. They use UIDocument and iCloud to store data. Also covered is the new Automation capabilities of the Instruments tool, which can enable you to run automated user interface tests on your apps. This is definitely an iOS 6 book.
Something I really appreciated was that the authors explained what could go wrong in many situations. They explained how things could break, and especially how to fix them. This is sorely missing from most development books.
The authors also walk you through the entire development cycle and offer informative chapters on testing and deploying your apps, including a mention of Provisioning Profile hell.
“iOS SDK Development” manages to cover a lot of territory in less than 300 pages, and by necessity they only offer a taste of some SDK features, like iCloud, and pass over others completely, like Core Data. I learned a few new tricks from this book and I’m glad I read it. I’d recommend it especially to developers who are new to the iOS world, but even veterans could learn a thing or two from this one.
There are two approaches to learning the ins and outs of writing iOS apps. One can trudge through Apple Documentation, which consists of class documents and guides to the numerous frameworks and concepts that underlythe platform, or one can find a kick-ass book that walks through the process in a logical order and holds your hand all the way. If you’re lucky, you can do both, using the book as your base, your safe harbour, and then delving into the documentation on an as-needed basis. There’s nothing wrong with the Apple Documentation. In fact, it’s really good, and I couldn’t imagine writing iOS apps without it. But it’s still nice to have someone to offer you wise advice and occasionally wipe the tears of frustration from your face. That’s where Matt Neuburg comes in. More specifically, that’s where Neuburg’s tome, Programming iOS 4, enters the story. Published in June 2011, it’s one of the newest and most complete introductions to the iOS platform on the shelves.
If you want your hand held, but you don’t want to be treated like a child, this is your book. Programming iOS 4 starts right at the beginning, with the C language, which forms the basis for Objective-C. From there, he gently introduces (or reviews) some object-oriented programming topics before moving into the details of the Objective-C language. I am impressed with his approach and organization in chapters 4 and 5, in which he discusses separately Classes and Instances. In my experience, this is a novel approach to explaining Classes in the language, and I found it incredibly clear and helpful.
From there, he tackles the IDE: XCode. The standout chapter in this part of the book is Chapter 7: Nib Management, in which Neuburg not only describes the Nib loading process, but takes the reader into the guts of the process and attempts to reveal the dark sorcery that goes on behind the scenes. The standard approach is to simply describe how to connect outlets to code and ask the reader to accept the opaque nature of the underlying process. The rational for glossing over the details is to get the reader into building a useful project quickly before their interest wanes. Neuburg instead takes a more principled approach and works to build a strong base of understanding before launching into the “fun stuff”.
This approach follows consistently through the rest of the book, and if I have any complaints, it comes from this strategy. We are at page 125 before we learn about Nibs, and we are shielded from the evils of memory management until Chapter 12 (page 249). We are guided through Cocoa classes, events, memory management, accessors. Then views, custom drawing, layers, animation and touch handling. And only then, after we have all those building blocks in place, are we introduced to View Controllers, which form the foundation of nearly all non-game iOS apps. Chapter 19: View Controllers starts on page 435, which if I were an eager, would-be iOS developer, would require an heroic demonstration of patience and perseverance to wait for. Every Cocoa Touch app XCode template uses a View Controller as the basis of the app’s architecture, and having to trudge through 400 pages to get to this “good stuff” seems like a lot to ask. I’m not suggesting this is the wrong approach. On the contrary, I think it’s a brilliant way of building a solid foundation in the framework before getting to the magic classes that give us so much for free. It simply asks a lot of the reader and hopeful iOS developer.
Weighing in at over 800 pages and being so well-organized and thorough, Programming iOS 4 represents the best on offer, both for introductions to the platform and as a reference guide to nearly every basic component in the app development process. As you can imagine, it took a long time to put this book together, and Neuburg admits in the text that when he began writing, iOS was at version 3.1. A lot changed in that time, and the author studiously followed along and ensured the latest features of iOS 4 and especially of XCode 4 were included in the book. A side effect however, is that some chapters feel like they have unnecessary code examples that demonstrate the “old way” of performing some tasks, when simply showing the “new way” would have sufficed.
On the whole, I am extremely impressed with this book and I will be recommending it to my students in the iOS courses I teach. My complaints are minor, and I only include them here for completeness and in order to have something more to write than simply expressing how great the book is. The tragedy is that despite how new and complete this book is, portions of it are bound to be obsolete within a few short months when iOS 5 ships. We can only hope that Neuburg will once again be there to update his oeuvre and guide us into the brave new world of Automatic Reference Counting, iCloud, and all the other curves Apple decides to through our way this fall.
I often browse the public library computer shelves just in case I spot a hidden gem, and mostly I find “Create Your Own Web Page!” or “Secrets of Windows 98”. But the gems are there, and I keep finding them, so I keep looking. A few weeks ago, I stumbled on The Art of Agile Development by James Shore and Shane Warden. I’ve recently worked in a group trying to follow Agile practices, and I’m desperate to find ways to improve my own “agility” when creating my own projects, so I was drawn to the book.
Agile development is not a specific practice or process in itself, but more of an idea for how software development should proceed. Its seed is the The Agile Manifesto, signed by many of the giants of modern software development way back in 2001, and many processes and practices fall under its umbrella. The company I recently worked for practiced Scrum. In this book, the focus is on Extreme Programming. So the title is a little misleading, but then again, I likely would have passed over it had it been called The Art of Extreme Programming. Like many, I’m sure, I have been instantly turned off by the idea of pair programming, and in my head XP == Pair Programming, and that was the end of the story.
So I’ll chalk it up to good fortune that I did pick up the book, and somehow managed to find the time to read it from cover to cover.
The Art of Agile Development is essentially a textbook for successfully implementing Extreme Programming for your software project. It steps through each element of the system, provides alternatives, and emphasizes in no uncertain terms that you may not pick and choose practices to create some Frankenstein monster of Agile Development and expect it to work. Each practice supports and reinforces the others. The meat of the book is in Part 2: Practicing XP, whose chapters are Thinking, Collaborating, Releasing, Planning and Developing. These chapters are specific and detailed, and even offer Mini-Etudes to get you and your team into the mood.
I have to admit that by the end of the book, I’ve become a convert to Extreme Programming. In the pages of this book, I saw some answers to many of the issues that have frustrated me in my team-work. I have a new perspective on pair programming, and I think I could get over my “don’t look over my shoulder” issues long enough to give it a fair shake. Now, as a solo-developer, it’s impossible for me to implement most of the practices (dual-personality pair programming?), but I now feel I have a solid understanding of the process and would be perfectly willing to sign on to a team that followed this branch of Agile Development. Notwithstanding the warning about picking and choosing elements, I also plan to implement as many of these ideas as I reasonably can in my own work.
Unless you’ve actually practiced Extreme Programming, or you’ve already read enough about it to have a firm grasp on the concepts, I recommend reading The Art of Agile Development before you make any judgements or succumb to prejudiced preconceptions of thorny issues like pair programming or open “bullpen” workspaces and dismiss XP as a hokey religion.
P.S. It looks like most of the book’s text is now available online at the book’s web site: http://jamesshore.com/Agile-Book/
I’m certainly no expert on the Google App Engine (which is why I read this book), so after fiddling around with it for a couple of my iOS projects and struggling to decipher the documentation of some of the more complex parts of the Engine, I was glad to get my hands on this book. It’s not that the App Engine docs are that bad, in fact the Getting Started section was very helpful and did get me started very quickly, it’s just that they are clearly written as technical docs. I’m not your standard software developer, and sometimes I need things laid out nicely and fed to me on a big soup spoon. And Programming Google App Engine is my spoonish saviour.
The book is well organized, and is distinct from some other books I’ve read for it’s conciseness and lack of filler content. The code examples are very brief, yet each demonstrates clearly the concept being discussed, so there is not much code reading to do in this book. On the other hand, this is certainly no cookbook or even a guide to writing an app engine app. What it is, is a thorough walk-through of the App Engine’s features, with several useful explanations of some of the unexpected and subtle complexities that would likely ensnare an unwary developer. He also points out many areas where Google’s implementation differs from what one would expect coming from a relational database background.
Three full chapters are devoted to the datastore, Google’s big table implementation of a database backend. An additional related chapter is the Data Modelling for Python. Standout issues from these chapters were:
- the explanation of how query speed is increased by storing indexes of all possible queries and their results,
- multi-valued properties
- the distinction between transactions and fetches
- Entity Groups and ancestor relationships between Entities
These were all features I didn’t even know existed before I read the book, and my knowledge and understanding of them will go a long way to helping me write more sophisticated and powerful App Engine apps. The chapters on the Memory Cache and Task Queues were also particularly interesting and useful.
I should confess that my interest in the Google App Engine is purely from the perspective of the Python language, so I skipped all of the sections and chapters related to Java. It does seem that the App Engine has been designed with Python in mind and there are many features available for Python that are not yet available for users of Java, and the book reflects this in its seeming emphasis on Python.
Apparently, the book is already dated because the Google App Engine is being updated all the time, but that doesn’t bother me because the book and the documentation serve distinct roles. The book gives you a “story” of what all the pieces are and how they fit together. When I run into a situation where the book’s information is dated, then I’ll refer to the current documentation to get the more up-to-date details. I don’t think the fact that this book is *gasp* 15 months old should be a deterrent from picking it up.
I actually read the book through my subscription to the O’Reilly Safari Books Online site, but I think it will be such a valuable reference that I’ve just ordered a print copy – and I don’t kill trees very often these days, so that says something about the book!
The title of this book offers a hint to the duality of information it offers. It tries to be both a programming book and a User Experience book, focused exclusively on the iPhone, and squeezed into a mere 165 pages. I think the book would have been more effective had it chosen one of these topics to focus on, but on many levels it still registers as a successful text which adds value to any iPhone developer.
I actually read this book twice: once when I first started out with iPhone development, and again nearly two months later, once I had a degree of comfort with the iPhone. Those were two completely different experiences. I would recommend waiting until you’re well into your first iPhone app before you read this book. There will still be time to fix any horrible user experience gaffes you have committed, and you’ll find the detailed code examples much more useful.
For the novice iPhone developer, the book hits you hard with a combination of information that is either too detailed to be of use now, or so basic, it doesn’t seem worth including in the book. There are detailed code examples of handling multi-touch swipes, and several pages earlier, there are diagrams with long lists of Cocoa class hierarchies. Neither of these were what I was expecting from a User Experience book, and neither were helpful in guiding me in crafting a good user experience for my first iPhone app.
More useful from the beginning were the discussions of Cooperative Single-Tasking (Chapter 5), Progressive Enhancement (Chapter 8 ) and UX Anti-Patterns (Chapter 9). These were filled with useful User Experience (UX) suggestions that could be applied right away to designing an iPhone app. Chapter 9 on anti-patterns is a particularly useful walk through an iPhone Hall of Shame, with some useful explanations of why these practices are wrong, and suggestions for what can be done instead.
Once I had more experience under my belt, both the Touch Patterns (Chapter 6) and the Interaction Patterns and Controls (Chapter 7) chapters with all their code examples were more useful. They play out like a reference text for adding features to your app. You want to make a custom scroller? There’s a code example for that. I even found the first three chapters more useful once I had experience with creating an iPhone app. These introductory chapters are often criticized for being fluff or filler, but they actually work as a useful checklist for your app, especially as it relates to the Mobile Human Interface Guidelines (HIG). Is it an Immersive Application or a Light Utility? Is it following the Mobile HIG guidelines for its class of app?
Programming the iPhone User Experience is a good iPhone book. Read it through once, absorb some UX do’s and dont’s, skip the detailed code examples that don’t apply to you now, and then come back to them later when you need them.
Disclaimer: I had a free copy of this book to review, which my Cocoaheads development user group received from O’Reilly to read and review.