In the last two days, we made a ton of progress. First we went and met with a friend of Will’s, an Android developer with Raizlabs. He explained the way that UI, data management and API calls are handled in three different classes… the UI, the presenter and the repository. He also explained that data types should be modeled with classes, especially when the are being passed from an API as JSON because then they can get converted into an instance of a Java class by GSON. Not to be confused with the Minimum Viable Product acronym, this is referred to as Model View Presenter in best practices.


As of now, we have the data that we got from Jump Off Campus in Firebase, fifty housing listings near the Tufts’ campus. We also have built the screen containing the map and, as of today, it populates with the data stored in Firebase. When clicked, popups appear with the capacity, address and per person rent of the given house.

We added some new tools to our belt as well. Postman & Espresso are great tools for API and UI testing (respectively) that we hope to take advantage of in the future. We were recommended to adopt Retrofit if and when we choose to integrate third party APIs, and RxJava for handling asynchronous tasks.


We had a lot of trouble with an error where a class was apparently not specified in the AndroidManifest.xml.

We also struggled with the return type from the request to Firebase. We now understand that it is a HashMap that maps addresses to Hashmaps that mapfrom each field ie rent, latitude… to its value. Anyways, we were eventually able to get the data casted to its appropriate type.

Moving Forward

We are feeling really good about our the work that we’ve done and now feel like we have a much better sense of how to not overload the UI level while getting data from a server. The next step is to make a post request wherein users can upload listings.

Having built out the full stack, we also need to take a step back and evaluate what features of our app our the most important. The skateboard works – students have access to off campus housing listings in a map view.

But how do we get to the bicycle? Do users want feedback of properties and landlords from previous tenants? Do they want to filter options based on criteria (cost, capacity, etc.)? Would they appreciate being able to populate the map with the addresses of their friends?

Before the code, we need to poll students, however informally, to determine the perceived value of these features.



Steps Toward a MVP


We accomplished a lot this week. First and foremost, we reached out to Kyle at Jump Off Campus and he graciously allowed us to use their data as a jumping off point for the Tufts’ Area. Further down the road we are going to need to make a decision regarding whether or not we’d rather make our own functionalities that JOC does not have or talk to Kyle about making a mobile product for JOC. However, right now the focus is one the basic functionality necessary to show users the listings.


  • Created a Firebase account and integrated it with our app
  • Used Chrome Developer tools to download fifty housing listings into a JSON file
  • Centered map on Tufts’ campus
  • Spoke to Kyle from JumpOffCampus, received his blessing to use a subset of their data to build our initial app.


While the map view appears in our app, the onCreate() function is not being called for unclear reasons. This makes the normally painless process of placing markers on the map unexpectedly difficult.

After the class demo, we decided to ditch hosting PostgreSQL on Heroku in favor of Firebase. We just need to make sure that down the road, we will not require server-side callback functions. We also remain unsure of how we are going to format our data in the database.


Moving Forward

We have a clear goal for our MVP; a single view of Tufts campus, populated by our JSON file of housing listings, where clicking on a marker reveals basic information about the listing. All of the building blocks are in place, but we need to write a function that iterates through each listing in our database and creates a corresponding marker.

We have also slated Saturday as a HackDay with a member of the Raizlab’s Android development team. We are hoping to learn a lot by shadowing his workflow from the start to finish of developing a basic app.


Week 1 Update


Most of our time was spent playing around in the Android Studio environment. It took a while to understand the code behind widget, view and text interactions. We ironed out the kinks in version control, simulation and API integration, and are ready to dive into building UI elements and database interaction.


  • Set up a PostgreSQL database on Heroku, to be populated with our housing listings.
  • Obtained an API key for Google Maps, and embedded the default layout into our application. We felt that our app has enough dependence on this API that the headache of integrating it was worthwhile early on. Had we not been successful, identifying another maps service would have taken some time.
  • Created a basic user interface, where clicking a button in the main view moves the app into the maps view.
  • Instantiated a git repo that pushes to an ‘experimental’ branch.


It proved difficult making heads or tails of the various files necessary to integrate the Google Maps API. Two separate xml files must be stored in the layout and values folders, as well as writing a file. The activity_maps.xml file was our first exposure to a fragment.

The AndroidManifest.xml file often incorporates unspecified changes, which can create issues in merging code on github. Using git stash before pulling changes has been essential in avoiding these merge conflicts.

The Google Maps API forced us to adopt API Level 23 (Marshmallow).

Java has some idiosyncrasies we are still coming to grips with. The difference between == and variableOne.equals(variableTwo), for instance (the first being a reference comparison, the second a value comparison) challenged our intuition of the syntax.

Moving Forward

Customizing the user experience (creating a signup/login process) is not a priority for this app. We will instead focus on creating widgets that successfully convey housing information, running informal user testing to iterate on our design.

Before we commit to populating our own database with housing listings, we are going to reach out to JumpOffCampus and express interest in using their API, if it exists, to build a mobile version of their platform. If this doesn’t pan out, we have three extra steps; find sources of current listings, populate our database with those listings, and build an API that our app can receive POST/GET requests.

Google Maps is not enabled on any of the stock simulators in Android SDK. While this forces us to test on physical devices, it does limit our development. We are considering creating two branches, one that deliberately excludes APIs, to facilitate development without a device on-hand.

Notebook Entry 1


A mobile app to facilitate conversations between college students about the housing process. This would include a directory of houses with information (ideally provided by the landlord) and reviews from Tufts students who have lived there. The way that we would verify that the reviews are from Tufts students would be through an email authentication system. In other words, a student must click a confirmation code sent to a address.



Both Tufts students and landlords could stand to benefit from this app. The landlords could distribute listings to their houses driving up demand on their houses. Tufts students would benefit from seeing information about houses all in one place. Currently, students must look at realtor’s (who charge an extra month’s rent, a cost incurred by the students) websites to see their options or craigslist. The lack of a centralized system makes it hard for students to not overpay.







Core Functionalities


-A map with information about the houses that are available around Tufts.

-The ability to add a listing

-The ability to review an existing listing


Different types of accounts

-Student (verified with a .edu email), thus their reviews are given priority

-General account


Information about the housing process

-Varying by school (because so does the housing process), this section will have the perspective of upperclassmen on housing. This section will include a summary of the process. Ex. at Tufts people generally figure out their first off campus housing in September or October of their sophomore year, be sure you understand your rights as tenant to…, and the best way to find houses is….

Secondary Functionalities

It would be nice to add a location based system (placing where the user is on the map)

Features of the Phone

GPS (if we choose to incorporate that)


We will need to be very aware of is the security and liability of an app like this. The reviews of a landlord must not be defamation/libel. Furthermore no sensitive information (phone numbers) can be put on the system without the consent of the person who owns that phone.


Users we Need to Market to

People looking for housing

Students looking for housing will most likely be the easiest to bring on. The idea will be to provide them resources about housing at Tufts (or in theory, their respective schools) such that the app initially serves as a guide. We believe that many first and second year students will eagerly seek out the input of upperclassmen.


People to List and Review Houses

Ideally, landlords would list their houses and would want to provide contact information for inquiries.

Another key group of users will be students that have already lived off campus. They can provide reviews of their apartments and give an account of their interaction with their landlord. Furthermore, they can list their houses if their landlords do not.