MP0: Location

Before starting MP0 you should make sure that you have completed installing Android Studio, and have either an emulator or real device that you can run Android apps on. If you don’t please contact a course staff member immediately.

Next, work through our instructions on installing and using Git. We will provide time during lab this week to review how to use Git to submit MP0, but you are welcome to go through our instructions beforehand if you are raring to get going.

First, sign up for a GitHub account if you haven’t already. Then use this GitHub Classroom invitation link to obtain your copy of MP0. Once your repository has been created, import it into Android Studio following our assignment Git workflow guide.

All of the core app code is in MainActivity.java in the app directory. That’s the scary stuff—although we have tried to comment it heavily to help you understand what’s going on.

But to work properly the app relies on three helper functions from Locator.java in the lib directory that process location data:

We have provided test suites for all of the helper functions. Our test suites contains both simple tests for each method for you to use during development and then a more rigorous set of tests.

Your goal is to correctly implement the missing methods so that all of the tests pass. Doing so will earn you almost full credit on the assignment—but see the section on style below.

A core task when approaching any programming assignment or task is to identify what you need to do. To finish the MP0 library there are three—and only three—functions that you need to change. Begin by identifying those functions and understanding their requirements. This will go a long way to helping you complete the MP. Once you are done with the library then you can tackle the more daunting change to MainActivity.java.

Your initial clone of MP0 will receive 0 points. That’s intentional! But once you start working you’ll find that your score will go up quickly. You only have to finish one of the helper functions and correct the checkstyle error to get to 30 points by Friday.

Use Android Studio to help you here. It can intelligently identify problems with your MP and guide you toward solutions.

We have provided you with testing suites that you can use to perform iterative test-driven development. You should integrate this process into your normal CS 125 Git workflow. Here’s how that works:

In general the fewer lines of code you write before running a test, the better. When you are starting out, it is easy to introduce bugs into your code. Bugs are easiest to catch one-by-one, and so the fewer lines of untested code the more likely you are to identify errors in your logic or implementation.

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.

Like any other computer program, an important part of developing on Android is generating debugging output. On Android, our familiar System.out.println doesn’t quite work the same way we’re used to.

However, Android has a simple yet powerful logging system. Unlike System.out.println, logging systems allow you to specify multiple log levels indicating the kind of output that you are generating. This allows you to distinguish between, for example, debugging output that might only be useful during development and a warning message that might indicate a more serious problem or failure. The Android logger also allows you to attach a String tag to each message to help separate them when you are debugging or developing. So the final syntax of the call to generate a debugging message, for example, is Log.d(TAG, message).

For more information Android’s official logging documentation.

The Android Activity class corresponds to a single screen that the user can interact with. Our simple app contains only one activity, but most apps consist of several: maybe an activity corresponding to the app’s main screen, another for a settings dialog, and still others for other parts of the app.

As you might expect, there are a few important moments for an activity: when it is created, when it appears on the screen, and when it leaves the screen. Android provides functions that you can override to handle both of these events: onCreate, onResume, and onPause. It is typical for on onCreate method to perform tasks required to make the activity ready for a user to use, such as configuring buttons and other UI elements.

For more information review Android’s official Activity information.

Why does code in your app run? In many cases it’s because a user interacted with an activity—clicked a button, entered text into a dialog box, or adjusted an on-screen control. Android provides a way for each app to register handlers: functions that run when various user interface (UI) events take place.

Our app uses these to:

If your app won’t build, try the following steps:

We’ll add things here as we go, but please check the forum first.

Follow the instructions from the submitting portion of the CS 125 workflow instructions. Note that the first time you do this you’ll want to pay careful attention to the common submission pitfalls, particularly if your submission doesn’t show up when you think it should.

You should carefully review the test cases in LocatorTest.java. The MP0 library testing suite tests your code using random inputs and pre-computed correct outputs. So, for example, when testing beenHere, we have pre-computed the correct answer for a small subset of test cases and use this to determine whether your solution works in all cases.

In contrast, testing the user-facing parts of Android apps is notoriously difficult. This semester we’ll be using Robolectric to write lightweight interface tests. For MP0 all we are testing is that you’ve hooked up the "Center" button properly, but in future MPs these tests will become more comprehensive.

Automated testing is a hugely important part of modern software development. Just like computers are good at running programs, they are also good at running programs to debug other programs. Independently developing a method and the function that tests it allows the two to support each other. The test may find errors in the method, and, the method may also identify errors in the test.

For all three library functions we provide you with both simple test cases using a small number of select inputs and exhaustive test cases that use many randomly-generated inputs. The former should be used during iterative development. For MP0, both are used during grading—but on future MPs there will be few to no points for the simpler test suites. The local autograder we provide will be able to help you estimate your score before you submit.

We have provided you with an autograding script that you can use to estimate your current grade as often as you want. Your Android Studio project contains run configuration called "Grade" that will run the autograder for MP0. You can also run the grader by installing our plugin and then pressing the button that looks like the CS 125 shield.

Unless you have modified the test cases or autograder configuration files, the autograding output should approximate the score that you will earn when you submit. If you modify our test cases or the autograding configuration, all bets are off. You may also lose points if your solution runs too slowly and exceeds the testing timeouts.

90 points on MP0 are for correctly implementing the required functions. The other 10 points are for style. Writing readable code according to a style guideline is extremely important, and we are going to help you get into this habit right from the start. Every software development company and most active open-source projects maintain style guidelines. Adhering to them will help others understand and integrate your contributions.

We have configured the checkstyle plugin to enforce a variant of the Sun Java coding style. Android Studio should naturally generate code that meets this standard. So you should not have to fight with IntelliJ too much to avoid checkstyle violations.

However, the checkstyle plugin does require you to add Javadoc comments, and also avoid the use of so-called magic numbers. You may find these requirements a bit annoying at first, but we trust that you will get used to them. Once you build good style habits, you won’t have to think about it anymore, and will just go on with your business writing beautiful code.