Designing the Settings Screen

The settings screen must allow the user to configure a number of game settings and save them. Game settings may be text input fields, drop-down lists, or other, more complex, controls. (You eventually want to handle social gaming with friends, but you will deal with that requirement later.) For now, you begin by implementing a simple settings screen with five basic game settings:

► Nickname—The name to be displayed on score listings. This text field should be no more than 20 characters long—an arbitrary but reasonable length for your purposes.


Rough design for the Been There, Done That! settings screen.

Email—The unique identifier for each user. This is a text field.

Password—A mechanism to handle user verification. This is a password text field. When setting the password, the user should input the password twice for verification. The password text may be stored as plaintext.

Date of Birth—To verify minimum age, when necessary. This is a date field but often displayed in a friendly way users understand and can easily interact with.

Gender—A piece of demographic information, which could be used for special score listings or to target ads to the user. This can be set to three different settings: Male (1), Female (2), or Prefer Not to Say (0).

Figure 10.1 shows a rough design for the settings screen.

(20 characters max)

(Will be used as unique account id)

(Password requires entering twice to verify)


(DOB requires entering Month, Day, Year)


(Male, Female, or Prefer Not To Say)

The application settings screen will contain quite a few different controls, so you need to be careful with screen real estate. You begin here, as you have on other screens, with the customary title bar.

Below the title, you add a region for each setting. Because you may add new settings in the future, you should encapsulate the settings area of the screen within a ScrollView control. This way, if all the settings fields do not fit on a screen, the user can scroll. The ScrollView control can have only a single child control, so you can encapsulate the bulk of your settings in another vertical LinearLayout control.

Each setting requires two "rows" in the LinearLayout control: a TextView row that displays the setting name label and a row for the input control to capture its value. For example, the Nickname setting would require a row with a TextView control to display the label string ("Nickname:") and a row for an EditText control to allow the user to input a string of text.

Now you need to determine which control is most appropriate for each setting:

► The Nickname and Email fields are simply different types of single-line text input, so they can be EditText controls.

► The Password setting requires two EditText controls. However, the Password text need not be displayed on the settings screen directly. Instead, you create a Button control to launch a Dialog window to allow the user to change the password (using the two EditText controls). The main settings screen can just display whether a password has been set in a TextView control.

► The Date of Birth setting requires a DatePicker control. Because the DatePicker control is actually three separate controls—a month picker, a day picker, and a year picker—it takes up a lot of space on the screen. Therefore, instead of including it directly on the screen, you can add a Button control to launch a DatePickerDialog control. The user selects the appropriate date and closes the dialog, and the resulting date is displayed (but not editable) on the main settings screen within a TextView control.

► The Gender setting is simply a choice between three values, so a Spinner (drop-down) control is most appropriate.

Figure 10.2 shows the layout design of the basic settings screen.


Layout design for the Been There, Done That! settings screen.

LinearLayout (Vertical Orientation)



TextView (Title)


ScrollView (Vertical)



Implementing the Settings Screen Layout

0 0

Post a comment