The following is the first few sections of a chapter from The Busy Coder's Guide to Android Development, 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/).

AIDL

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

A GraphQL client-side code generator would take a GraphQL document and generate a Java class that hides all of the HTTP and JSON stuff behind a fairly straightforward API. Along the way, it might create POJOs that mirror the results that we are requesting from the server, so that we can work with ordinary Java objects, rather than having to mess with a nested series of Map and List objects.

Apollo-Android is such a code generator. It is created as part of the Apollo Data suite of libraries and tools for GraphQL development. Apollo Data, in turn, is part of the Meteor Development Group, creators of the Meteor Web development stack.

A typical Android Studio project would use com.apollographql.apollo:gradle-plugin, which is a Gradle plugin that adds the code generation tasks to the standard Android Studio and Gradle build process. Given that, what you need to do is:

The Gradle plugin takes it from there, generating your Java classes for you, which you can then use to make requests of the GraphQL server.

This sounds easy. In truth, it is rather complicated to set up and get working.

NOTE: These are early days for the Apollo-Android project. As a result, while the instructions shown in this chapter are up to date for when this book version was published, Apollo-Android may have changed since then. You may encounter some issues when trying to follow these instructions. Future updates to this book will update these instructions to the then-current edition of Apollo-Android.

Using Apollo-Android

The preview of this section is sleeping in.

Names and Apollo-Android

The preview of this section is out seeking fame and fortune as the Dread Pirate Roberts.

Was All of This Worth It?

The preview of this section is [REDACTED].