To help you develop the skills to create new Android apps and maintain existing ones, we’re excited to announce the fifth edition of our popular guide to Android programming. While there are only four authors officially listed in the book, the making of this fifth edition was a group effort at Big Nerd Ranch. We consulted heavily with the entire Android team here (and also reached out to other experts in the field) to provide the best learning experience possible for someone looking to dip their toes in modern Android development. Read on to learn about what’s changing in this latest installation!

What’s New In The Fifth Edition?

In 2019, reactive programming was gaining popularity as a way to architect Android code into maintainable and extensible structures. With the release of Jetpack Compose in 2021, Google poured gasoline onto that flame, supercharging the reactive programming movement. Reactive programming and Jetpack Compose’s declarative framework fit together seamlessly and provide an excellent foundation to build modern Android apps.

While this book still provides readers with all the necessary knowledge to make apps using the best practices of modern Android development, Jetpack Compose is the future of Android development, and the fifth edition of the book is intended to prepare readers for that future. In addition to four new chapters introducing readers to Jetpack Compose, changes throughout the book are intended to ease the transition from developing apps with Android’s existing UI toolkit to developing apps with Jetpack Compose. For example, there are many ways to write asynchronous code on Android, but the book exclusively uses Kotlin coroutines to perform asynchronous operations. Coroutines are baked directly into Jetpack Compose’s API as well as being excellent tools to interact with UI written with Android’s existing UI toolkit. We also reworked many of our projects to follow the unidirectional data flow architecture pattern. The unidirectional data flow pattern is essential to building apps with Jetpack Compose – and it also helps organize code when building apps with Android’s existing UI toolkit.

Other changes in the fifth edition go beyond Jetpack Compose. For example, testing is an integral part of building modern Android apps, and we have rewritten the content around testing from the ground up with practical examples. Also, to reflect how modern Android applications are developed, the book leans on libraries from Google and third parties. Apps in the book now use the Navigation component library to manage navigation between screens and libraries like Retrofit, Moshi, and Coil – as well as the Jetpack libraries – to handle other core features.

On (Virtual) Shelves Soon

Whether you’re trying to create your first Android app or your 50th one, this book provides simple explanations and meaningful dives into the Android platform, helping you quickly harness the platform to create the apps you want and need.

The eBook version for the fifth edition of Android Programming: The Big Nerd Ranch Guide is available for pre-order now and will launch in early May. Printed versions of the book will be available in early June. If you or your team would like the full Big Nerd Ranch experience, we offer instructor-led bootcamps where one of our expert instructors will teach you the Essentials of Android.

You can find more information on our books page or view a recording of our webinar, where we covered what’s new, tips and tricks, and more. Happy coding!

The post Coming soon: Android Programming: The Big Nerd Ranch Guide, Fifth Edition appeared first on Big Nerd Ranch.

One of the things I’ve done recently in my client projects is, in order to make generic types more approachable to a new developer, provide generic types with a descriptive name (ie. <Element> instead of <T>). My thought process here is that, by giving the generic type a descriptive name, I am hopefully demystifying generics and placing them on the same level as classes, variables, and functions. What is a T? It sounds abstract to a fault. But I understand the concept of an Element. I can deal with an Element. Unfortunately, Kotlin inherited Java’s convention for naming generic types with single, uppercase letters, such as <T>. While I haven’t found any explicit mention of the convention (unlike Java), Kotlin’s documentation and standard library are littered with <T>, <U>, and <K>. Now, personally, I’ve never been afraid to challenge convention. The world is constantly changing, and things that felt like common sense choices 5 years ago might not hold up to modern scrutiny. However, the prospect of bucking convention while also teaching students a difficult concept seems fraught with problems.

Give generic types descriptive names.

You shouldn’t name a variable d. I doubt that most Kotlin developers will find that this is a controversial statement. While naming variables is one of the two hardest problems in modern software development (the other two being caching and off-by-one errors), it is widely accepted that clear and expressive variable names help make code easier to read and comprehend. Yet, for some strange reason, generics seem to operate outside this rule. Kotlin is a language that prides itself on being both concise and expressive, but this naming convention, while extremely concise, is not very expressive. It is also not a small, isolated piece of the language. With a robust standard library and heavy reliance on extension functions, generic types permeate everything in Kotlin.

To be clear, I am not arguing against the usage of generic types. Kotlin’s heavy use of generic types shows how this language was meticulously designed. Generic types give Kotlin developers tools to write safe and expressive code and avoid unnecessary duplication. However, generics do add an additional layer of abstraction, and the unexpressive naming convention can be inscrutable and unwelcoming. This additional cognitive load can overwhelm more junior developers.

Most modern languages are using expressive generic type names.

Generic types have been around since the 1970s, showing up in languages such as ML and Ada. For a long time, many popular languages relied on the single letter naming convention (e.g. C++, C#, Java). However, in more recent years, this convention has been challenged on various fronts. C# has incrementally migrated to expressive generic type names, making it the official recommendation for the past few years. When Apple introduced the statically-typed Swift, it almost exclusively used expressive generic type names. While you will occasionally still see a lone <T> in Swift (see: this and this), it is much more common to see <Target>, <Element>, or <Wrapped>. While Kotlin inherited many things from the Java ecosystem, the language should rid itself of Java’s single letter generic naming convention and follow the lead of other modern languages.

Descriptive names make it easier to understand the basics of generics.

Descriptive names remove barriers of understanding for developers of different backgrounds. Within Kotlin, there are scenarios where it is obvious that these single-letter generics do actually stand for specific, full words. Take, for example: Map<K, out V>. It is clear to me that K stands for Key and V stands for Value (the docs even confirm it!), but I am not so sure that either beginner developers without a formal computer science education or non-English speakers would make the same connection. While this translation from K to Key is minor for experienced developers, it still is some cognitive load. Moving to Map<Key, Value> could be hugely beneficial to helping beginner developers understanding the basics of generics and could help them begin to internalize and actually implement generics within their own code.

Descriptive names help to build a deeper understanding of concepts.

By using descriptive generic names, developers can help link related concepts to build a deeper understanding of how entire systems works together. Even for usages of the default <T> name, there are normally more descriptive names available. Kotlin scoping functions are implemented under the hood with generics. For example, the full function definition for .apply is:

inline fun <T> T.apply(block: T.() -> Unit): T

Unlike Key and Value, which are obvious choices to assist in the comprehension of the Map interface, the <T> within .apply does not immediately lend itself to familiar terms. Additionally, .apply requires an unusual function parameter in the form of: (block: T.() -> Unit). While this only applies to a subset of scoping functions (ie. .apply, .run, and with()), if you closely read through the documentation, you’ll see Jetbrains has already provided a definition of that function parameter with the term ‘receiver’.

On its own, much like the terms Component and Module in Dagger, the word ‘receiver’ doesn’t help us understand much about how we should use these scoping functions, but scoping functions isn’t the only place where Kotlin uses ‘receiver’. Along with function literals, the ‘receiver’ is the foundation for creating domain-specific languages (DSLs) in Kotlin. For code that looks as strange and alien as some DSLs, the repetition of the term ‘receiver’ would give new developers a helpful foothold into fully comprehending what is happening under the hood. It would start connecting disparate concepts and give developers context to start to process scary phrases, such as “functions as builders,” “function literals with receiver,” and “type-safe, statically-typed builders”. By using single-letter generics instead of descriptive (albeit jargon-ey) names, Kotlin is missing out on an opportunity to assist new developers in building connections between different programming concepts.

Weigh the pros and cons of using descriptive generic names.

There are few objectively correct decisions you will make in software engineering. Everything is a trade-off; each decision has pros and cons. At this point, I believe we have a long way to go before using descriptive generic names in our Kotlin programming-based books and courses would be beneficial for our students. For a tricky concept that students already struggle to understand, I don’t need to bring in the baggage of my “hot take” into their learning process. Most students taking our courses already have experience in other languages where the single letter convention still applies. The unexpressive naming convention won’t hold them back. On the other hand, I’ll continue using descriptive generic names in my client projects. In that context, I think the comprehension and readability wins make it a great choice. Try it out for yourself and let me know what you think.

The post Express Yourself: An Argument for Ending the Single Letter Generic Type Convention in Kotlin appeared first on Big Nerd Ranch.