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.


Objects, Fields, and Types

GraphQL queries and mutations do not follow syntax conventions that you are used to. In some respects, they look a bit like function calls. In other respects… well, GraphQL is strange.

That being said, its foundation lies in the same sorts of objects, fields, and data types that you may be used to from other forms of programming, such as Java. However:

In this chapter, we will explore how the objects, fields, and data types work in our GraphQL requests, and we will examine some of the idiosyncrasies involved with GraphQL.

Introducing the GraphQL Schema Definition Language

When we create databases in Android with SQLite, we define a schema by means of SQL statements like CREATE TABLE. When we define an bound service interface, we define a “schema” of sorts by means of AIDL, if we are delivering that service across process boundaries.

Similarly, with GraphQL, we can define the different types that a server exposes by means of the GraphQL schema definition language.

That language is used on the server, not on the client. However, when describing GraphQL, often times it is useful to show snippets of GraphQL schema language, as this is a compact way of depicting these types. Hence, while you may never wind up needing to write GraphQL schemas, it will be helpful if you can read them, which is why they are presented in this chapter.

This “cheat sheet” provides a capsule description of how the schema language looks and works.

Objects

Let’s start by going back to the generated documentation in GraphiQL that we saw earlier in the book:

GraphiQL Documentation, Showing Query
Figure 15: GraphiQL Documentation, Showing Query

Specifically, we see:

allTrips: [Trip!]!

The Trip is a type of object, one that is custom to our demo server. Server can define all sorts of object types, modeling the sorts of data that the server can return and/or manipulate.

For the moment, ignore the square brackets and exclamation points, as we will get into those later in this chapter.

The first page of that generated documentation, though, was a bit odd:

GraphiQL Documentation, As Initially Opened
Figure 16: GraphiQL Documentation, As Initially Opened

This lists “Root Types”, a Query named query, and a Mutation named mutation.

When we use the query or mutation keywords on our operation, we are telling GraphQL that we want to work with that Query object or that Mutation object. These are special objects, registered by the server, that serve as our entry points into the data that this server returns and/or manipulates.

On most pages of the generated documentation, the name that you see centered at the top is the name of the type for which you are examining documentation. So, the first screenshot shown in this chapter shows the Query definition, while this one shows the definition of Trip:

GraphiQL Documentation, Showing Trip
Figure 17: GraphiQL Documentation, Showing Trip

On the server, Trip can be defined as a custom type via the GraphQL schema definition language:

type Trip {
  
}

Of course, we need a bit more in that schema snippet… starting with some fields.

Fields

The preview of this section is in the process of being translated from its native Klingon.

Data Types in GraphQL

The preview of this section is en route to Mars.

Type Modifiers

The preview of this section was accidentally identified as an Android 'tasty treat' by the Cookie Monster.

Trip, In Schema Definition Language

The preview of this section may contain nuts.