Learning the Repository pattern, MVC architecture, and Unit testing

The second sprint continued to introduce some broad concepts, but did tie them more directly to Android development. During this sprint I began to plan the Fitness Explorer app more directly as we covered entities, the Repository pattern, the MVC architecture (Model View Controller), and Unit testing. When tasked to make an app you're usually given a base idea of what the client wants, and the translation and storage of data is extremely important; this is where entities come in. We use entities as a way to group data referring to a single object. Below is the requirement given for the Fitness Explorer app.

Entities

As you can see there are four pieces that display different sets of information. One for calories burned for the day, one for the activities done during the day, one for calories burned every day for the week, and another for activities done for the entire month and the associated calories lost with the activity. Based on that we'll need four different entities. For the first entity I needed a way to represent calories burned for the day. Since that's all that was needed I created the Calorie entity. This entity has an integer value representation for calories burned, and obviously the necessary getters and setters.

The second entity embodied any activities done over the course of the day. To encapsulate this I needed a start and end time using a java Calendar object, a String which represents the name of the activity, and the calories lost performing each activity. This is where the CalorieActivity entity comes in. It's going to extend the Calorie object so it doesn't need it's own field for calorie and just needs the dates and activity string.

For the third entity, I needed a way to represent all of the calories lost in the past week. So I need a start time, end time, and the calories lost during that start and end time. I called this the CalorieDate entity. It has a start and end date using the java Calendar object, and extends the Calorie object from above.

The final entity I needed was to represent all of the activities done, associated with calories, for a month. This one was a little tricky because there can be multiple activities in a day. So I decided to create an ArrayList of CalorieActivities to represent the activities the user performed during a given day, along with a start and end date. This is the DayActivities entity.

Repository pattern

Now with my entities finished I needed a way to load the user's Google Fit data into those entities. I knew eventually I would be interacting with the Google Fit API to query and aggregate the user's data, but in the meantime I could get by with an in memory data source for development / testing. This is where I would use the Repository pattern to hide the details of my data source behind an interface, thus allowing my to swap out a development MemoryFitnessRepository for the production GoogleFitRepository. See my IFitnessRepository interface below.

See the temporary MemoryFitnessRepository below, which would only be used during development and testing.

MVC Architecture

WE used the MVC architecture for this app and it has three parts, the Model, the View, and the Controller. The Model manages the data and logic of the app, the View is what the user sees and interacts with, and the Controller accepts input and converts its commands for the Model or View. The final piece of the puzzle is the Repository, which is where the data comes from. The Model interacts with the Repository (which further interacts with the Google Fit app) to collect the user data and parse it to get it ready for the rest of the app to display. The way the Model, View, and Controller interact with each other can be slightly different across applications. In the Fitness Explorer app the Model and View can interact with each other, the Model interacts with the Controller, and the Controller interacts with the View. Since the Model interacts with the Repository this allows the Controller to update the View only when the Model is ready to be updated.

Unit Testing

Unit testing is an incredibly important part of software development, and it was a crucially important piece in the development of the Fitness Explorer app. Unit testing allows for the testing of individual units of code that you would otherwise need to test at a later time. This is useful because it allows you to be certain that everything is working perfectly before you move on to another task. For the Fitness Explorer app I did unit testing for all of the entities, as well as the repository, which allowed for easy integration of the Google Fit API into the app. Mock testing is another very important part of unit testing. Since some objects you're testing may have dependencies on other, more complex, objects, you need to find a way to simulate the behavior of the real objects. For the Fitness Explorer app I needed a repeatable test to ensure the correct methods were being called to display the data for the dashboard view. I created a test class called MockDashboardView to simulate this so that I was confident the correct methods were being called at the correct times.

Next Sprint

After a two sprints that mostly introduced me to some high level concepts, the next sprint actually gets into the Android architecture. In the next article I'll cover my introduction to Android Views, Layouts, and the Object Pooling pattern.