The following is the first few sections of a chapter from GraphQL and Android, plus headings for the remaining major sections, to give you an idea about the content of the chapter.

Basic Static GraphQL in Android

Dynamic GraphQL is great for those cases where you happen to need it. More often than not, though, static GraphQL will suffice, as typically you know ahead of time what sorts of data you will be retrieving and modifying through GraphQL.

In this chapter, we will explore how static GraphQL documents can be used by a code generator to give you Java classes that make requests of the server and model the responses, so you can work with the server via a generated Java API. This is in contrast to what we did in the previous chapter, where we used general-purpose APIs (e.g., OkHttp) that were not tied directly to our server and data model.

Android Apps and Code Generation

Ahead-of-time code generation abounds in Android app development. Every Android app winds up with code-generated Java classes, simply as part of normal development. Many developers do not even think of this as “code generation”, just because it becomes such a natural extension of the way that Android apps get developed.

In a typical Android Studio project, your module will have a build/generated/ directory containing generated Java code. If you rummage through what’s there, you will see varying amounts of code, depending on what Android SDK and third-party code generators you wind up employing.

R and BuildConfig

When you write an Android app, any time your Java code wants to refer to a resource, you wind up using some R value, such as R.string.app_name or R.layout.main. The R class gets code-generated by aapt as part of compiling an Android app. aapt is part of the “build tools” (tied to the buildToolsVersion), and one of its jobs is to parse all of the resources, identify all of the necessary symbols, and generate the R class in the manifest-declared package for your use. In a typical Android Studio project, each module will have a build/generated/source/r directory containing your generated R class for each build variant (e.g., debug/).

Similarly, BuildConfig is created by the build tools based on your Gradle build script, with information like your version code, version name, build type, and so on. You can add your own information to the generated BuildConfig class, for all build types or by product flavor, using buildConfigField. This is a popular way of making API keys available to Java code, for example. In a typical Android Studio project, each module will have a build/generated/source/buildConfig directory containing your generated BuildConfig class, again with one for each build variant (e.g., debug/).


If you work with remote services, frequently you wind up writing some AIDL files. These work like IDL files do for RPC systems, providing a language-neutral way of describing an interface between programs. In RPC, the interface is between a client and a server; with AIDL, the interface is between a service and its clients in other apps.

The AIDL that you write results in a code-generated Java class that provides:

Even if you do not have any AIDL, your Android Studio module may still generate an empty build/generated/source/aidl/ directory. If you do have AIDL, your generated Java classes will reside in there.

Data Binding

Google introduced the data binding framework in 2015, trying to make it simpler for you to populate a widget-based UI from your Java code. Given an appropriately-augmented layout resource, the data binding code generator creates corresponding Java classes that allow you to populate those widgets, using binding code expressions written in the layout files themselves. All the Java code needs to do is create an instance of the binding (which also inflates the layout), then supply the objects to be bound to that binding — the generated code and associated library takes care of the rest.

Compiled SQL Queries

Code generation is not just for Google — other developers have gotten into the game.

For example, Square’s SQLDelight takes a file of SQL code and code-generates Java classes that provide a data-access layer for working with SQLite using that SQL code. You add the code generator Gradle plugin to your project, add the SQL file, and SQLDelight takes over from there.

The Staticizer

Implementing your own code-generating Gradle plugin is not that difficult, particularly using Square’s JavaPoet library. JavaPoet is a Java library for generating Java code, using a builder-style API, to minimize the odds of syntax errors and to handle a lot of the dirty work (e.g., adding appropriate import statements) for you.

The Busy Coder’s Guide to Android Development has a chapter on code generation that demonstrates the use of JavaPoet and Gradle plugins. That chapter profiles a Staticizer sample code generator that takes a JSON object and creates a corresponding Java class file, akin to BuildConfig. The idea is that you might get that JSON as part of the build process (e.g., from a server), and so the code generation eliminates the need to manually update some Java source to match the new JSON data.

Introducing Apollo and Apollo-Android

The preview of this section was eaten by a grue.

Using Apollo-Android

The preview of this section took that left turn at Albuquerque.

Names and Apollo-Android

The preview of this section will not appear here for a while, due to a time machine mishap.

Was All of This Worth It?

The preview of this section is unavailable right now, but if you leave your name and number at the sound of the tone, it might get back to you (BEEEEEEEEEEEEP!).