MP2: ConnectN

Use this GitHub Classroom invitation link to fork your copy of MP2. Once your repository has been created, import it into Android Studio following our assignment Git workflow guide.

At this point you should be familiar with the requirements from previous MPs. See the grading description below.

To complete MP2 you must understand the specification. That’s your starting point, and your returning point when you get confused.

Writing code to a specification is an important skill to learn. In many software companies, designing code and implementing it are not always done by the same group. A project manager or program manager may write a specification, which is provided to developers to implement. Or a team of developers may come up with a specification, and then divide up the implementation work between them.

Regardless of where it comes from, writing code in groups almost always requires a specification to be successful—unlike when you do independent projects and can make up things as you go. A lot of the design work and high-level decisions end up going in to the specification, so by the time the implementation begins the hard and interesting choices have been made. That’s not to say it still isn’t fun at that point—even developing to a spec provides huge opportunities for simultaneous creativity and correctness in that unique programming way.

MP2 requires you to implement some simple getters and setters (just return or change the variable), and some ones with more complicated behavior. Be sure to read the documentation carefully.

You will need to do a bit of work to implement the game board. ConnectN is a Connect-4-like game. Tiles fall in the top (large Y values) and sit at the bottom. We’re in the proper first quadrant of 2D space, with X values going left to right and Y values going down to up:

A ConnectN game ends when either player plays N consecutive tiles in either a single row or column 3. Tiles always have to be played at the lowest possible location in each column—in a real Connect-4 board they fall downward and rest on the tiles below them. Consult the Wikipedia page for more details.

The course staff is ready and willing to help you every step of the way! Please come to office hours, or post on the forum when you need help. You should also feel free to help each other, as long as you do not violate the academic integrity requirements.

Until this point all of our MP apps have only had a single activity (or screen). In MP0 that single screen showed location data. In MP1 that single screen showed your transformed image and background.

But a typical app has multiple screens which a user can navigate to, each displaying different information. For example, a chat app might have a contacts screen and a settings menu along with the main chat display. An email app might have a screen for navigating between different folders or labels, a settings screen, and the main inbox or folder screen.

In Android each screen is typically represented by a separate Activity, each in its own class. In the screencast above we walk through how activities are launched, can launch other activities, and can pass information to launched activities using Intents.

Our previous MP apps also had a single static layout per activity, which we created using Android Studio’s UI designer. This is fairly normal for many apps when core components of the layout don’t change. You set up a layout using the designer and then populate each field with appropriate content depending on the data available to the app.

MP2, however, has different requirements, because configuring the game differently can and should produce different board views. To accomplish this we create a layout programmatically—using code in our app—rather than statically. The screencast above walks you through how this is done. If you are considering creating a game for your final project you may be curious in exploring this further, since many games need various kinds of dynamic layouts.

Finally, a common way to interact with the user is to modify the properties of existing UI elements. You might create a text view using the layout designer when you are creating your app, but then have the text shown in the view be determined and modified when the app runs. Alternatively, apps can modify the visibility of UI elements to react to changes in the app state—for example, to display or hide a warning message appropriately.

The screencast above uses an example from the MP2 configuration activity to show how this is done. You’ll need to do something similar in the board activity to earn full credit on MP2.

As in previous MPs, we have provided exhaustive test cases for each part of MP2. Please review the MP0 testing instructions.

Like MP0 and MP1, we have provided you with an autograding script that you can use to estimate your current grade as often as you want. Please review the MP0 autograding instructions.