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.
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.
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.