Semester Progress (Part 2)

The structure of the application was also greatly retooled to allow for different use cases. Our team decided that in order to better accommodate different types of requests, we should allow for different entrypoints into a restaurant menu -- for example, if a user wants to find restaurants with hamburgers, he should be able to look that up rather than having to guess a restaurant name.

Since many of the network calls were tied directly to the which activity (which screen) was started in the app, this proved harder to finish than expected. The network calls needed to be completely abstracted out in order to allow a screen to be shown without being tied to network calls. In retrospect, this seems fairly obvious, but at the time, it didn't seem like something of great significance. This is a great lesson in how software extensibility should be taken into account at design time, so headaches can be avoided later.

My solution ended up being abstracting the methods of passing data around between different screens of the application. Because of this, the screen is able to display the data it receives, whether it came form a file, the network, another screen that has already done the work, or something else. This had the added effect of reducing the number of trivial network calls -- since the message passing framework was better, the amount of redundant work was vastly reduced.