Add AI Spinner to Player List Items

Given that we’re making a game here, it’d be helpful to have a way for people to play against computer-controlled players. To do that, we’re going to create some AI players, then give users the ability to choose which of those AI players they’re facing. In this part, we’re only going to worry about giving the AI players names, and we’ll leave the actual logic for Chapter 4, ​Update LiveData with Conditional Game Logic​. We’re going to create an AI class with a number of possible AI players, then update the player items to include these AI players. Whether a user is shown a name text field for a player or the AI Spinner will depend on the state of the SwitchCompat on that player item. Before we get to the UI, let’s create the AI class.

Create the AI Class

Our AI will be another data class, this time living in the game package. For the time being, it’ll only contain one property, name, a toString method that returns that name, and a companion object with a List of AI called basicAI. In here, we’ll declare eight AI players to be used in the Spinner. The code looks like this:

This class doesn’t have too much, but a few things may be new for you. The companion object syntax denotes an object that is associated with a given class. There’s only one instance of this object per class (meaning it’s a singleton) and functions/values/variables in here can be accessed in a similar way to how we would reference static types. In this case, we can get basicAI elsewhere by referencing AI.basicAI.

Since the new toString function is just going to return the name value on the AI instance, we can use expression syntax to directly assign name to toString. That is equivalent to this:

The last piece that may look weird is the @JvmStatic annotation on basicAI. Adding this annotation tells the compiler to create an additional static get method for basicAI. This will allow us to reference basicAI in a static way within a player list item, which we’ll see in a bit. Since this is all we need in the AI class currently, we’re going to add the Spinner list inside player_list_item.xml.

Add AI Spinner in player_list_item.xml

I keep mentioning the <Spinner> tag, which is what we sometimes call a “drop-down list” or “select” in HTML. A <Spinner> contains some number of items and allows the user to select one of those items. Our AI <Spinner> is going to live in the same spot as the name <EditText>, and we’ll toggle which one we’re displaying using the <SwitchCompat> associated with the player item. As a result, the constraints for the <Spinner> will match up with the <EditText> on all four sides. We’ll also need another android:visibility attribute on both the <EditText> and <Spinner> based on the player’s value for isHuman.

Finally, once we get the conditional logic completed, we can handle the AI items themselves. Normally, we’d need to create some kind of SpinnerAdapter to include our items, but we’re going to take a different approach thanks to the Data Binding library. The android:entries attribute will allow us to bind an object as the list of items in the <Spinner>.

In our case, we could use AI.basicAI or AI.getBasicAI() for that android:entries attribute. The reason there are two options is because the former value is the Kotlin property while the latter is a getter method that’s generated for use with Java. Now, we normally want to go with the Kotlin approaches all over, but if you use AI.basicAI, Android Studio will complain (even though it works). Instead, you can avoid the error by using the Java getter syntax in our binding.

No matter the approach you take with the list of AI objects, we need to update NewPlayer to include a new Int variable—selectedAIPosition.

This will track the index of the selected AI (retrieved from AI.basicAI or AI.getBasicAI). In our XML, we’ll use the android:selectedItemPosition attribute with selectedAIPosition. All these pieces together will look like this in the layout file:

We established that we can use AI.basicAI or AI.getBasicAI to get our list of AI options, but we haven’t established why they’re available yet. It’s because we added the @JvmStatic annotation in the AI class. Without that, the Data Binding library wouldn’t have been able to figure out how to send in the data. To use AI.basicAI or AI.getBasicAI, we also need to import the AI type inside our <data> block:

Also of note is that android:selectedItemPosition is a two-way binding expression to our new selectedAIPosition property on NewPlayer. Otherwise, this item is similar to the <EditText> we created earlier. Speaking of that <EditText>, don’t forget to include the android:visibility attribute there:

Since we’re now getting an AI from the front end (or at least the index for one), we can get the currently selected AI object via a new function called selectedAI. This function will return null either if the isHuman is true or the AI at the given index can’t be found.

Now the form works as we need it to for the game, but we could make this a bit prettier and user friendly. Let’s go ahead and add a couple of nice-looking UI features: disabling excluded players and iconography for the <SwitchCompat>. Both changes will give the app a more polished feel.