End of Semester Reflection

Now that the semester is coming to a close it is a good time to reflect on what has worked well and what we could improve on future projects.

Technically

Technically we learned a lot during this process. First and foremost was proficiency in Java, a language Chris was a little bit familiar in bit Will was new to. Familiarizing the basics of the Android Platform, activities, views, the onCreate method, resources files and layouts were the next. Third was the Android GoogleMaps API which, of the technologies we used, may have been the most intuitive and well-documented issues.

Professionally

The biggest lesson that we took away from developing this app was everything takes longer than expected. We had some unforeseen technical glitches at various stages of the project. We were also pleasantly surprised by the willingness of JumpOffCampus to provide us with data, it seemed to be a case of Tufts Alums looking out for Tufts students.

What Ming could have done differently

Ming was really helpful and we enjoyed all of the characteristics of his courses that we have seen before… independence, project based learning, and collaboration. I think the one thing that I would have done differently, it would be to have a few labs or homework assignments at the beginning of the semester designed to get us on our feet with Android Development. This would have ensured that we were all competent in some of the basics. The examples he provided were very helpful but it would have been nice to even give us a list of ideas of super basic apps to build to understand certain elements of Android or Java (an Async task, a maps app, a fragment…).

What we could have done differently

The biggest thing that we could have done differently would have been to be more decisive about the features that we wanted to add to our app. We sort of teetered between a few ideas in the first couple months, starting with wanting to build a receipt splitting app but we found out that we were a little late to that market (5 Apps that Split the Check for you).

A Proposed Change to the Course

As mentioned we thought that a little bit of hands-on development experience before starting with our big project could have been beneficial. This also would have informed our decision of what app we wanted to build (or maybe give us inspiration). That being said, we understand the importance of starting the project early because of how long mobile development takes.

Overall we had a really good experience working together and working in this class. Thanks Ming!

Advertisements

In a Perfect World

 

Had we infinite time and resources, how would we continue to work on Project Student Housing? Given that this app idea was born of large ambitions, it feels useful to reflect on the vision beyond what we achieved only in this semester:

The long-term goal of PSH is to replace the role of the realtor and empower students to fully arbitrate off-campus housing.

This comes from three realizations during the construction of this app:

1. Students that currently lease are the best-suited to introduce the property to other tenants, yet they rarely interact with them.
2. Students looking for off-campus housing already rely on word of mouth to find potential listings.
3. Realtor fees pose a cost on both tenants and landlords.

This creates an inefficient housing ecosystem. The students looking for housing can either stick to the small pool of options presented by upperclassmen they personally know, or they can use a realtor at greater personal cost to discover more options.

In a perfect world, the tenants would use their current, personal experience with their lease and landlord to market the property to all the students who might be interested. This would a) create transparency between the actions of the landlords and the potential tenants, and b) make realtors unnecessary as all off-campus listings are made public.

There are two questions of incentive that must be addressed. First, landlords don’t have an immediate reason to engage in a platform that has potential to negatively review them. But not only is there precedent for reviews to assure accountability in other high-profile apps (à la Airbnb/Uber), money talks. Landlords also lose money to realtors, and getting a high volume of potential tenants interested in a property is worth ceding some transparency.

The other problem is that current tenants do not receive any benefit for marketing and touring their property for anyone they do not know personally. But if the landlords paid their current tenants a fraction of the realtor fee for securing their replacements, there would be ample reason to provide occasional house tours and maintain a listing on the application.

If the sharing economy relies on removing the friction between consumers and producers, Project Student Housing stands to disrupt the industry of short-term lease agreements.

The platform distinguishes itself from the Airbnb model on the assumption that students trust students first, and that long-term tenants have greater credibility and insight into the property than the landlords themselves. In this model, landlords save money while being held more accountable, future tenants have a greater wealth of housing options, and the current ones pocket the difference.

Keystore Woes

We have taken down the listing for our original app. The current incarnation of Project Student Housing is available here.

Obviously, unlisting an old app only to publish the new version is problematic for all of our legacy users, as they will never receive the bug fixes as an update. They have to navigate the confusing process of uninstalling the original app and download a (seemingly identical) version on the Google Play Store. Far from ideal.

However, we had no choice, having lost the original keystore used to sign the APK. Without understanding the necessity of signing all future versions of the same app with the same keystore, the original was overridden in the process of generating new signed APK with a new keystore with the same name assigned to the same location on our local drive.

After our class on reverse engineering apps from the APK file, the necessity of a unique keystore/app pairing is obvious – to prevent the app from being cloned and launched on the Google Play Store without our authority. However, I personally feel that Android Studio should further highlight the importance of saving keystores in a secure location at the time of generation. It is too tempting to save a keystore within the application itself, which (as is the case for this class) gives anyone with access to our public Github repo to publish a clone. To a beginning developer this vulnerability is not so obvious.

---

The updates themselves were quite simple, if extremely important. The Google Maps API Key has been updated to fix our grey screen issue that was preventing users from viewing listings. As our core functionality, this was a grave problem.

The app also checks that new listings are within proximity of Tufts University, and that all input fields have been filled out. Users were posting incomplete listings incongruous with the rest of our data on Firebase.

The users have spoken, and want two added features head and shoulders above the rest. First, pictures of the listings. Second, contact information for the landlords. We are committed to implementing at least both of these before the end of the semester. A system for rating properties would be great, but demands implementing user registration so that a single individual cannot flood a property with positive or negative reviews.

 

Onto Google Play

Overview

Getting our app onto the Google Play Store was relatively painless. Their approval period feels like the blink of an eye compared to Apple’s. We’ve reached a turning point where moving between views, implementing UI elements, interacting with Firebase, etc. are all well under our fingers. While our app could certainly be more efficient, now the building can happen without constantly referring to Stack Overflow or Youtube tutorials.

Challenges

• For all the ease of integrating and using Firebase, writing to the database is not as flexible as we had hoped. Using push() to create new child nodes, for example, includes an associated timestamp that forced us to change the architecture of our database.
• We also published our app with a ‘low maturity’ content rating, which is not ideal. Apparently requesting location permissions in the manifest file immediately disqualifies an app from an ‘everyone’ rating. While undesirable, it may be unavoidable.
• We have also received feedback that our logo should be changed.

Moving Forward

Now that our functionality is unlikely to change, we need to begin focusing on improving the usability of our app. Both in terms of pure aesthetics and user flow. Material Design best practices and User Interviews are the logical next steps, and requires diving into a relatively untouched skill set.

We need to decide how to best curate our database now that anyone can post a listing. Should a listing be incorrect, should other users be able to report it? Should listings be approved before they are added to the map, or only be taken down upon receiving enough complaints. This is the last big question that we will waste a lot of time building if we don’t settle on a system beforehand.

While the fundamental features of our app are complete, we have a few ideas such as a ratings system, a way for landlords and student to talk to each other through the app (with a way of verifying students are in facts students via a verification sent to a Tufts email), or reconnecting with Jump Off Campus about integrating more of their system into ours that were thrown around as ways to expand the app during development.

Building off of that, we would love to incentivize students to add content, as global advice and specific landlord/property reviews. Hopefully the feedback we receive from leg 6 will guide what we use the last month to build/re-build.

Testing

Lint

Initially we debugged with lint through the Android App Studio’s native inspect tool. We were able to catch hard-coded values, unused dependencies and many similar issues. In order to generate the report we then began to test from the command line. This provided us with tons of warnings and initially 62 errors, as can be seen in our initial report. However, the errors stemmed from what seems to be a bug in lint and we were able to resolve them through the lint.xml file in the project’s root directory. As of right now, there are no lint errors in our project. Moving forward we are definitely going to address many of the errors in the lint report. The reason that the ones that are there now are because we have not had success running the emulator on later versions of the Google Play Store so we have tons of out of date warnings. We also have unused resources that we will need soon on a few of our views that we are currently working on.

Espresso

Espresso is used to do UI testing, meaning it simulates the actions actually performed by the user and makes assertions about how the app responds. We wanted to do this because it is the most detached way of testing… it doesn’t matter if junit tests indicate the backend is working if something the user is trying will not work. We built a test that will testing the logic of the post listing view. The idea of this page is that if a listing already exists at an address then a user cannot post another. In our test, the user tests this out then successfully posts an app.

Crashlytics

Installing Crashlytics was a snap. Fabric provides visual, step-by-step instructions within the plug-in. Our first crash report can be found here.

User Interviews

We interviewed two of our housemates, both of whom have had previous experiences (both positive and negative) in finding off-campus housing. Here are our main takeaways based on both their explicit feedback and general navigation of the app.

1. iOS users are not aware of the back navigation button on Android devices, which may make it useful to supply this feature redundantly within the app’s UI itself. Both users had to ask how to return to the main activity from the listings page.
2. Posting a listing is not seen as a useful feature, which brings up the current lack of incentive for current tenants to participate in the following year’s lease agreement. This will likely continue to be beyond the scope of our app this semester, although it sparked an interesting conversation regarding the possibility of creating contracts between landlords and their current tenants to circumvent the use of a realtor.
3. Having reviews, and having those reviews be made from Tufts students authenticated via email address, would add to the listing’s legitimacy.
4.  Users expect the info window that appears upon clicking on a map marker to have more information, and to be clickable itself. There was expressed interest for pictures of the listings and how many other students were currently looking at a given listing.

 

 

Adding Functionality

Overview

With our app rebuilt under the Model-View-Presenter paradigm, we chose to divide and conquer the next two features of our app. In addition to our map of the Tufts campus that displays the fifty nearest listings for off-campus student housing:

Chris began building a location optimization page, where the user can view the walking distance between a given listing and their most often locations on (or off) campus. The Google Maps API can provide estimated walking distance between two locations on a map.

Will created a page to post listings to our database. This involved creating a UI, checking the proposed listing against our current ones (to avoid duplicates), and pushing to Firebase.

We will cover testing in a subsequent post.

Challenges

The EditText widget was the only UI element which we had no previous experience implementing, and the robust documentation made it a snap to bring online.

Problem #1). In the interest of keeping PostListing to a single view, I decided to programmatically change the visibility of UI elements within the same xml file. For example, clicking on a button appears to move from one view to the next, when in reality it simply makes a new set of UI elements visible while removing the others.

Unfortunately, and as we have already covered in class, Android reloads a view whenever a screen rotation occurs, which meant that the view would revert to its initial state whenever the phone/emulator was turned sideways. We are still considering the best way to rework this. Despite this lost time, the speed of this method makes it a valuable tool for prototyping a user experience within Android Studio.

Problem #2). We lack an elegant solution for cross-checking the proposed new listing with our existing ones. Currently, every listing in the database is converted to lower case, stricken of all non-alphanumeric symbols, and compared to the proposed address that undergoes the same process.

However, this fails to take into account abbreviations (street vs. st., avenue vs. ave) commonly found in addresses. We could solve this problem by refusing new posts within a certain “margin of similarity” with an existing entry. However, that immediately creates greater problems, such as refusing multiple posts from the same street (which would only differ by one or two numbers). This problem is compounded by the fact that the some of the addresses in our database are too vague (simply “Boston Avenue” without a house number).

Solutions clearly exist, but the level of granularity required in the logic is not appealing. It will likely involve splitting the addresses by street and number, and making assigning a different comparative analysis to each.

The rest of the challenges are mainly housekeeping, adapting the code to more strictly adhere to the MVP model and the implementation of asynchronous tasks.

Next Steps

These features encapsulate the core use of our app, and improving both the engineering and user experience behind them will take greater priority than adding anything in addition to what we have made so far. Our hope is to upload our app to the Google Play Store with both of these working, potentially spending the rest of the semester simply improving what we have from there. We are weary of feature creep.

However, if our testing reveals that users have a strong desire for an additional feature, we will strongly consider incorporating it before the end of the semester.

Lightning Talk (The Other MVP)

Model View Presenter (MVP)

A way of separating user interaction, data manipulation, server requests and response handling and updating the UI.

• View is a layer that displays data and reacts to user actions. On Android, this could be an Activity, a Fragment, an android.view.View or a Dialog.
• Model is a data access layer such as database API or remote server API.
• Presenter is a layer that provides View with data from Model. Presenter also handles background tasks.

 

• 

 

Pros

• Separation of Concerns 
  • Asynchronous Tasks
  • UI Testing

Cons

• Learning Curve
• Redundancy

 

Excellent Introduction

Example Repo w/ Google Maps

(credit to Johnil Quezada)