Preface

I have had the opportunity during my years in working in this industry, to see concurrency in many contexts. When I was in school, it was a topic for dissertations. As a journeyman developer, I saw a lot of concurrent code, nearly all of it Java, in distributed back-end systems. Recently, I’ve had the opportunity to experience first-hand the turn to languages like Erlang and Scala, in the hope of making concurrent code easier to design and write.

I recall early in my career, being coached by a very supportive interviewer into reinventing double-checked locking. I certainly recall the furor, about a year later, when it was discovered that the double-checked locking idiom was not safe, and soon after, the first sighting of incorrect byte-code in the wild. Perhaps most surprising of all, though, I recently removed an implementation of the double-checked locking idiom from a piece of code written in 2015.

The constant, over this time, is the mystery and debate surrounding the topic. Perfectly competent novices suddenly balk or make naïve mistakes when concurrent code is necessary. Developers who are otherwise entirely reasonable sometimes disagree—occasionally quite vehemently—over the correctness of a particular piece of concurrent code. Their arguments, which may go on for hours, inevitably end up hinging on minutiae so fragile that the argument’s actual winner is irrelevant.

I readily admit to feeling some kind of glee when I walked out of that early interview after having been led to double-checked locking. It was a shibboleth. I’d been initiated! Recently, I think I’ve seen the same kind of excitement in the faces of lecturers and their audiences as the lecturer passes on a secret: some fast and loose—and frequently downright incorrect—concurrency trick.

A really clever algorithm and a good shot of glee are wonderful things. We would all write better code, though, if we could strip some of the mystery and magic from concurrent programming. It would be great if instead of being the realm of the wizard, the correctness of a piece of concurrent code were something on which the opinions of two developers—even two developers with wildly different interests—rapidly converged.

If you are a novice developer, you will probably find some of the terms and concepts here unfamiliar. If you are a developer working on his or her very first Android app, you will probably be more concerned with simply getting familiar with the Android framework.

There are some really good books for you, already in existence, if you fit into either of these two categories. If that is the case, I encourage you to set this book aside for a while, enjoy the thrill of the steep part of a learning curve, and to come back when you have one complete Android app under your belt.

While it may sound obvious, I intend this book for reading. It is neither a cookbook nor a reference manual. I absolutely encourage you to try out the sample code. The examples are just sandboxes for experiments. Extend them. Try new experiments with them. Build your own personal understanding of the details of the Android OS. I hope, though, that you don’t have to prop the book open next to your laptop to get value from it.

I was at one time bewitched by Perl. Looking back, I think that a major reason for that is that it was so much fun to read the Camel book (not the pink one, the blue one: the 2nd edition). I recall many enjoyable hours far from a keyboard and with no specific application in mind, simply reading that book.

I do not compare myself to Larry Wall. I do not by any means compare Android to Perl. I do hope, though, that you enjoy just reading this book. I hope that it is something that will make good company, perhaps on a plane flight or a long commute.

I urge you not to skip Chapter 1, at least. It presents a model of concurrency that is somewhat atypical and that is the basis for the discussion in the following chapters.

Chapters 2 and 3 are intentionally short. They are a refresher for some basic ideas and provide an opportunity to reintroduce some common idioms. Experienced developers may choose to skim them.

Chapter 4 is a cautionary tale.

The heart of the book is Chapters 5 through 7. These chapters are a deep dive into some of the details of the Android operating system.

Chapter 8 is dessert: a bit of a how-to for some concurrency tools.

Register your copy of Android Concurrency at informit.com for convenient access to downloads, updates, and corrections as they become available. To start the registration process, go to informit.com/register and log in or create an account. Enter the product ISBN 9780134177434 and click Submit. Once the process is complete, you will find any available bonus content under “Registered Products.”

Bold indicates new terms, URLs, email addresses, filenames, and file extensions.

Constant width is used for program listings, as well as within paragraphs to refer to program elements such as variable or function names, databases, data types, environment variables, statements, and keywords.

Constant width bold shows commands or other texts that should be typed by the user.

Constant width italic shows texts that should be replaced with the user-supplied values or with the values determined by the context.