A Note About the State of Mobile Development

At the time of this writing, the state of Android and iOS development is highly volatile, highly fragmented, and highly contentious. New libraries intended as replacements for existing APIs have been added, but some of these releases weren’t necessarily the product of community consensus. Further, nearly every replacement API was substantially more complex than what it replaced. When deciding what information to include in this book—including foundations like libraries and APIs—we decided that we should try to provide the most help we could to the greatest number of people and projects. The great majority of development is feature development and maintenance, versus greenfield (new, blank slate). With that in mind, in almost all cases we default to an existing, vetted library, instead of a new library or practice that’s been available for only a relatively short amount of time (about a year is the arbitrary threshold we decided on).

In addition, we found that many of the replacement APIs took the framework further away from patterns seen in existing technologies. For example, the new Navigation set of components on Android can be used to manage UI in the same basic fashion presented in this book (Fragment instances), but in a very different fashion. Considering the amount of infrastructure required, we found that including additional copy and code to introduce those patterns, compared to the vetted patterns we believe represent the reality of Android development at this point in history, would do more harm than good. Another good example of this is database technology: very recently, Google recommended Android development use its Room library, but SQLite APIs are included in AOSP’s standard libraries. No one would argue that SQLite doesn’t have limitations and that Room is probably a more modern approach—but one of our primary goals with this book is to provide source material that would allow someone conversant in general programming to quickly get up to a productive level of fluency, and SQL generally is perhaps one of the most common, mature, and widely scoped technologies in the world. Room is not; thus, our data persistence references use SQLite APIs. If you choose to use Room, that’s great! And we encourage you to check out these newer recommendations and tools, and we try to mention them whenever appropriate, but don’t be surprised that we use FragmentManager over the list of components needed to use the Navigation API—this is by all means a deliberate decision and one that we believe is the right choice at this point.

Similarly, and again in the interest of leveraging any existing domain knowledge possessed by you, the reader, we may use a less efficient but more readable or common pattern or method. For example, when reading from a stream on Android, we often just use InputStream.read and not use a buffer; while obviously buffers are often appropriate, we can achieve not only very small and digestible sample code blocks, but also free us up from having to explain how a buffer works (on both sides, input and output), what size of buffer is most appropriate in various circumstances, and why having a single buffer preallocated can be more efficient than creating a new one for each read or write operation. A stream buffer might seem like a pretty straightforward concept, but explaining it correctly and in full is nontrivial. For a similar reason, modern versions of Java provide try-with-resources for Closable operations, but in this case specifically, someone familiar with try-catch in another language (e.g., JavaScript) will immediately recognize the standard syntax and be able to focus their attention on the task we’re describing and not need to stop, process the alternate syntax of try-with-resources, and wade through one or two more paragraphs that aren’t serving the goal of getting it done. Certainly, try-with-resources is something that can be very appropriate in a lot of circumstances, and we encourage everyone to learn as much about each language and framework as possible in their own time, but this book is about getting programmers programming, not mastering every technology we touch on this book.

Thanks for listening, and for everyone who expressed opinions that led to this note, we truly appreciate your thoughtfulness.