jbv's blog

Final Update

jbv — Thu, 16 May 2013 01:07:42 +0000

The application is finally done. We had a final meeting to share all results that we have accumulated. The nutritional team shared the information from the user surveys, and we discussed improvements to the application that could be considered for future works.

Overall, the application seems to have been well received. There are still a few bugs, but as it was a prototype, the users were comfortable with this.

As the semester is over and several of us are graduating, there is not time to make these improvements. However, this process has taught me a lot. I've been able to work with a mentor teaching how to research computer science subjects, and been able to interact with people that don't necessarily know computer science, which is new to me.

Attached is a sequence diagram of the application, so that others can understand how the application works.

http://www.cs.arizona.edu/~jbv/foodtracker_sequence.pdf

Updates (Part 4)

jbv — Tue, 23 Apr 2013 09:22:10 +0000

Since the previous wave of updates, updates have continued to be made for the app. Many of the categories generated by the automatic parser have been combined into more human-friendly categories. Using a web interface that I created, recommendations were input into the database by the nutritional team and show up in the application without actual updates to the application on the phone.

My advisor and I have also discussed scalability and performance issues that may occur with the current design, as well as possible solutions. For example, for reduced data use or (slightly) faster lookup times of previously viewed menus, most of the network calls that the app is making could be cached into local storage on the phone.

App Pictures

jbv — Tue, 23 Apr 2013 09:17:12 +0000

Here is a link to the promised application pictures!

http://www.cs.arizona.edu/~jbv/ftpics/

Semester Progress (Part 3)

jbv — Mon, 01 Apr 2013 23:13:27 +0000

The application also had many usability tweaks as well. Any long operations were moved such that they work in the background while the user can navigate other portions of the application.

The layout for each page is now generated using the same methods for each screen, so that the layout is uniform between different screens. Uniform styles were also applied to each page of the application, to improve the appearance.

Minor tweaks were made as my understanding of Android increased -- layout optimizations that make the page load faster for the user were quite welcome.

The end result is a fairly user friendly application that should be ready for user testing. The results of our meetings up till now has been developing the app until this point, and now we are ready to test its usefulness to others. The rest of the team is giving me feedback on any remaining quirks or bugs in the app, and I am making the changes. Like it was mentioned in the database post, these changes can be made without physically updating the application on the device. I also created webpage forms for the other team members to use to update the database without me -- if, for example, they are struck by a sudden inspiration on health advice for a hamburger, they can navigate to a webpage and enter that in rather than open a terminal and be overwhelmed. I believe it is important that developer tools are developed alongside user programs, so that people other than computer scientists can be involved in development (or just so that development is quicker and easier).

The next post will have pictures of the application thus far, and will be posted when I have access to the necessary resources to take the screenshots.

Semester Progress (Part 2)

jbv — Mon, 01 Apr 2013 23:06:23 +0000

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.

Semester Progress (Part 1)

jbv — Mon, 01 Apr 2013 22:56:50 +0000

The blog may have been a little neglected these past few weeks, but great process has been made. I will split up the work into several topics which will be the subjects of the next few posts.

First, the database for the foods had to be updated with actual food information. To accomplish this, a parser was built that scrapes data from online restaurant databases in order to populate a database for our use. Although the parser needs to be tweaked and configured for each restaurant, this greatly simplifies the process of adding restaurants to the application. And since the restaurants exist on a server independent of the app, it enables restaurants to be added at any time without updates having to be made to the app. Among other things, this enables the user testing to get under way even without a completely populated database.

The database also handles a lot of calculations for us. For example, it takes care of classifying the foods into different nutritional categories, since it already has access to the nutritional information.

The database also allows for string searching of restaurants -- a function was added to the database that calculates the Levenshtein distance between two strings. Thus, when asking the database for a restaurant based on user input, we can also display restaurants that have a short Levenshtein distance from whatever the user typed in.

The database is not exposed to the public, as that is obviously a security risk. The only interface to the database are servlets of my creation that return predefined queries -- this way, there is no risk of the database being compromised.

Weeks 13 & 14

jbv — Tue, 18 Dec 2012 21:41:36 +0000

The final two weeks of the semester were spent fixing the current prototype. Due to some feedback from the rest of the team, the appearance of the application will likely be changing, but we wanted to make sure the basic functionality was complete.

I added information to the database to allow for tips for different food categories -- for example, how hamburgers (in general) can be improved, and added this to the prototype. With this, the prototype is functionally complete (or near complete), and next semester can focus on improving the appearance, as well as testing the application with users. Then we can improve the application based on the feedback we receive.

Week 12

jbv — Mon, 19 Nov 2012 15:32:02 +0000

This week was spent configuring the servlet and the database to respond to real queries from the phone. The phone application also had to switch over from using the placeholder data that was being displayed thus far, to parsing and displaying information from the web server.

Since querying the web server can take some time, it was also a challenge to ensure that the application is responsive at all times, even when waiting for a response from the remote server.

Although everything is configured to display real restaurant information, we don't have much of a restaurant database built yet. It is my hope that we can have a modest one built in a few weeks. In the meantime, I've inserted a few restaurants manually, just to ensure that the prototype is working.

Weeks 10/11

jbv — Mon, 19 Nov 2012 15:28:26 +0000

Weeks 10/11 were mostly spent implementing UI changes that the nutrional science team contributed at our last meeting. The servlet that is handling the phone queries was also rehauled exensively to allow for the type of restaurant menu requests that we are going to need to handle.

I've decided to have the servlet reply to queries using JSON. This has the advantage that it is relatively small compared to Java's built in serialization of objects. In addition, this allows the server to be used for platforms that aren't running Java. Even though it is not in the scope of the project, this means that developing applications for other platforms (such as a webapp, a desktop application, or another phone OS) would be trivial.

Week 9

jbv — Mon, 19 Nov 2012 15:24:09 +0000

During week 9, I got the application to use the Google Places API to search for restaurants within a certain radius of the user. The location is obtained using the GPS of the phone.