Software Engineering

Pocket Beer Reference Application for Android Mobile

Adam Dille
A Project Submitted in Partial Fulfillment of the Requirements for the Degree of Master of Engineering in Software Engineering Department of Computer Science, University of Colorado at Colorado Springs 1420 Austin Bluffs Parkway Colorado Springs, CO 80918
Submitted on 11/5/2010

ABSTRACT Completion of this project will involve the design and development of an Android mashup application that will provide a mobile beer style reference for home brewers of beer. The application will provide several useful methods of mapping widely accepted style guidelines to specific commercial beer examples. In addition, the application will allow user interaction for the purpose of determining the source of an off flavor in a specific beer.

search engine. The results from searches against the API are formatted as JSON and passed back to the application for parsing. 1.2. JSON Parsing in Android Frank Ableson, in his July 2010 IBM technical publication entitled Using XML and JSON with Android, details how to use XML and JSON responses in an Android application. This information was particularly useful to this project after the decision was made to use Googles REST Search API, which returns JSON-formatted data. The JSONArray and JSONObject classes are used in Android to parse JSON responses and convert them into objects which can be queried for their data (Ableson, F. 2010). Googles API responds with a JSON structure containing four top-level objects. Two of those objects contain nested arrays of other objects. With the JSON classes available, and the examples provided by Ableson in his publication, it will be much easier to build a function for parsing these responses and sending them to Views within the application. 1.3. Security Considerations In an October 2008 iSEC Partners publication entitled Developing Secure Mobile Applications for Android, Jesse Burns gives a full run down on the Android Security Model. He explains how, at design time, an Android application must declare explicit permissions for the operations that it needs to carry out. These permissions are then presented to the user when the application is installed, and they can either accept or reject the application based on those permissions (Burns, J. 2008). This paper helped to provide some background into the methods that Android uses to secure its running

1. RELATED WORK At the time of this writing, Android is still relatively new (it turned 2 years old on October 21, 2010). In addition, it is and always has been a community supported platform. Because of this, much of the available research and documentation currently comes in the form of blogs, developer forums and technical publications. Unfortunately, this means that there are currently no published conference papers on Android development that are directly related to this particular project. Instead, a selection of technical publications was chosen for research. These publications are directly related to several of the most vital development topics of this project. 1.1. Web Service Decisions In his 2009 paper entitled Web Service Clients on Mobile Android Devices, Johannes Knutsen discusses the advantages that a client application gains when using a Web Service Gateway. Web service gateways offer the client an interface that is simpler than the web service itself and they convert responses into lightweight packages like XML and JSON (Knutsen, J. 2009). The lightweight responses, in particular, are extremely useful for a mobile application as they cut down on data usage and battery drain. This project will utilize a Google REST Search API that is essentially a web service gateway against the Google

Pocket Beer Reference Application for Android Mobile applications. Armed with this information, this projects application was designed to require a minimum set of permissions to be accepted by the user. Only two permissions are requested: Full Internet Access, and View Network State. Of those two, only Full Internet Access is presented to the user as a possibly dangerous permission. Since most users understand that internet access is necessary for this type of application, these design decisions will ensure that users feel comfortable installing the application, since they wont be bombarded by a list of requested permissions. It also means that the application will be very secure, since it will be prohibited from performing a myriad of dangerous operations on the system such as accessing contacts, reading emails, dialing phone numbers and so on. 1.4. Phonetic Search Certain features of this application will require searches over a table of text strings within a database. Finding a desired string within that list will allow the user to link to that strings corresponding data and read the details that they are looking for. This could be performed rather simply using a full or partial string match where a function would check to see if the users search term matched any part of any string within the database table. However, this would prevent results from being returned when words are misspelled. Since spelling errors are common, it was desired that this feature be developed to find the desired results, even for misspelled words. One of the most popular ways to handle spelling errors is through the use of a phonetic search algorithm. These algorithms, sometimes called sound alike algorithms input a word or name and return an encoded key (Philips, L. 2000). Keys for two words can be compared to determine whether or not they match phonetically. One of the best phonetic search algorithms was published by Lawrence Philips in his 2000 publication entitled The Double Metaphone Search Algorithm. Double Metaphone allows for resultant keys to be of any length specified, which can increase match accuracy for certain words. It also introduces alternate pronunciations, which gives two possible keys for some words, thus increasing potential matches (Philips, L. 2000). The Double Metaphone algorithm implemented in the Apache Commons project is used in this application with great success in thwarting spelling errors during string searches. 2. INTRODUCTION Brewing beer at home, known as Homebrewing, is a hobby for many people around the world. In America, it is estimated that more than 750,000 households brew at least once each year (How many homebrewers are there in the United States? Talking Points). One of the most popular American Homebrewing online forums runs a thread to track its members yearly beer production. In 2009, members of the forum logged roughly 31,000 gallons of beer brewed at home. Members estimate that the tally on that forum thread most likely represents about 1% of the worlds homebrewing production (How many gallons of homebrew in 2009? Forum Topic. Homebrew Talk). If those stats ring true, then homebrewers produce somewhere around 3 million gallons of beer each year. In the world of homebrewing, styles reign supreme. Beer style guidelines provide both beginner and expert brewers with a framework that their creation should fall within. Crafting a quality beer is actually quite difficult because there are many variables that play into the brewing process. A brewer must be conscious of time, temperature, ingredient quality, equipment, cleanliness, procedure and technique. In addition, a typical beer takes around 6 weeks from brewing to consumption, meaning that the opportunity for mistakes is spread out over a long period of time. Even a small mistake can lead to a beer with noticeable off flavors, resulting in a waste of time and money (Palmer, J. 1999). Building a beer recipe to conform to a particular style guideline gives a brewer some level of assurance that aroma, mouthfeel and taste characteristics of the creation will turn out better than they might have if a random recipe had been thrown together with no guidelines. The style guidelines used almost universally by homebrewers are published by the Beer Judge Certification Program (BJCP) (BJCP Competition Beer Styles, 2008), and updated every few years. BJCP styles are used for categorization and judging in just about every homebrew competition in America. These styles come in extremely handy for a homebrewer, as they include ranges for beer gravities, bitterness levels, color, and alcohol level. They also contain descriptions of aroma, feel, taste and other characteristics one would judge when tasting a specific beer. They hold lists of ingredients often used in each style and a few example beers of each style. Whereas most other beer style lists are just names used

Pocket Beer Reference Application for Android Mobile for categorization, the BJCP styles contain a wealth of valuable information for a brewing hobbyist to reference. 3. PROJECT EVOLUTION Originally, this project was going to be devoted to the design of a recipe creation application for Android. The idea was to allow a home brewer to create a recipe from scratch by choosing a BJCP Category, and component ingredients. The app would then tell the brewer how closely their recipe was falling within the chosen style category. Unfortunately, shortly after implementation of this idea began, an application hit the Android market to do just that. Rather than re-invent the wheel it became a priority to find a new idea and shift gears. All of the code necessary to populate BJCP Style tables and give the user details about any particular style was already implemented. With the completed Style List feature in active use, a point of weakness with the styles themselves began to show up. In addition, this area of weakness didnt seem to have any solutions available in the marketplace. Fortunately, creating an app to address this weakness would allow for the reuse of all of the existing Styles List code. 4. PROBLEM STATEMENT As useful as they are, the BJCP styles fall short when it comes to finding popular example beers for a particular style, or the inverse, taking a specific beer and figuring out what style it falls under. These two scenarios actually pop up quite often for the average homebrewer. A brewer will often try a commercial brew, and then decide that he would like to brew his own clone version. Inversely, a brewer might read through the details of a particular style and grow interested in brewing a beer of that style. But, before brewing theyd like to try an example first and see if they actually like it well enough to spend the time and effort on it. Even if a brewer is armed with a great recipe that adheres to a particular BJCP style guideline, there will inevitably be times when things go wrong. In these cases, an individual with an experienced palate will know almost immediately by judging aroma, mouthfeel or taste that something is not quite right. However, tracking down the cause of an off flavor in a beer is not an intuitive process. 5. PROPOSED SOLUTION It was immediately clear, after using the BJCP Styles List, that a mash up application would help the brewer to quickly pinpoint new and useful information related to those styles. Finding the style of a particular beer or a list of example beers for a particular style would be possible by pulling in a data set containing information about commercial beers. The search began for a place on the internet with a comprehensive list of example beers that could be referenced in a mash up with the BJCP Style Guidelines. BeerAdvocate.com immediately showed up in web searches and it proved to be the place for beer on the web. In fact, the #2 result in a Google search of the word beer is BeerAdvocate.com, right after the Wikipedia entry for Beer (Google Search: beer). Fortunately, BeerAdvocate categorizes every single beer on their site into a style that they came up with, separate from the BJCP (Beer Styles Beer Advocate). This categorization would prove to be the most important criteria for connecting BJCP Styles to commercial examples on the market. 6. APPROACH AND GOALS 6.1. Feature Designs Using BeerAdvocates existing categorizations, the plan was to create a simple mapping between BJCP styles and BeerAdvocate styles. With that mapping in place, and given a BJCP style, the application would know exactly which BeerAdvocate style page to visit and poll for top beer examples of that style. Inversely, given a specific beer page on BeerAdvocate, the application would be able to grab the BeerAdvocate style number and use the mapping to return the associated BJCP style. To simplify the process of pinpointing a specific beer on the BeerAdvocate website, a search View will be included to accept a users query and provide results from Googles REST Search API. Those results will be filtered to BeerAdvocate index entries. Adding this search function into the mix will provide a quick method for getting a user to their specifically requested beer page on BeerAdvocate. In addition to these style-related functions, the application will have an interactive feature that will allow a brewer to track down the cause of an undesirable flavor in his beer. This feature will use a database of flavor characteristics, which will be related to causes of those characteristics. Each cause will also have a description of

Pocket Beer Reference Application for Android Mobile things that can be done to make sure that the flavor doesnt show up in future brews and, in some cases, what can be done to remedy the off flavor in the currently affected beer. This feature will employ a search using a phonetic algorithm (Philips, L. 2000). This algorithm will help to catch spelling errors and should prove very helpful in tracking down specific flavor characteristics. 6.2. UI Approach The final design step will involve placing an intuitive UI on top of all of these different sources of data to create a seamless experience for the user. My employment background includes plenty of web design, so an attractive and functional user experience is of great importance when I set out to create any piece of consumer software. With great user experience as a priority, the following list of UI goals was laid out for this project: Centralized, reusable styles should be used as often as possible to create consistency between different Views within the application. All Views should scale gracefully to any screen size that might be encountered on an Android device (anywhere from 2.8 to 10 inches diagonally). All Views should rotate and display gracefully when toggled between portrait and landscape orientations. All Views should display data in an easily readable format. All graphics should feel modern and should be provided in a range of resolutions to accommodate different screen densities and sizes. All lists of data provided by the application (styles, commercial examples, and tastes) should be filterable/searchable using an intuitive search and list View. No general list should be provided that requires the user to browse for what they are looking for. Long-running operations should always be performed on new threads with the UI providing cues to notify the user of that operations status. This will keep the user experience responsive at all times and give the impression of snappy performance. 7. CONFIGURATION MANAGEMENT 7.1. Source Control A Subversion repository was installed and configured on a home server to house all of the artifacts for this project including source code, binaries, graphics and documentation. This server has an associated domain name and was given a public port for Subversion Server access. This allowed check-ins and updates to occur from anywhere with internet access and proved to be very useful during development. Nightly backups of the repository were made to a separate server to ensure the safety of the project artifacts. 7.2. Project Management There are several great tools available for project management and bug tracking such as Trac and Mingle. However, with a single developer and a project lifespan of just a few months, it was simpler to track to-do items and known bugs using Google Tasks. Google Tasks is a simple task list within Google Calendar, which can be synced out to a mobile app called GTasks. This system allowed development items to be tracked at home and on the go and required almost zero set up time. For a larger project, it would most definitely be advantageous to set up a more robust project management solution. 7.3. Development All development was performed using the Eclipse IDE. Google distributes a set of SDKs and plug-ins for Eclipse called the Android Development Toolkit. These packages facilitate native android development within Eclipse. They also provide emulators and drivers necessary for physical device connections. These can be used to run or debug a project in an actual Android environment. Once these Eclipse plug-ins are installed and configured, developing an application using a physical Android device is simple. Projects are continuously compiled as development progresses. A simple click of the Run or Debug buttons installs the latest binaries to the connected device and runs the application. 7.4. Testing Aside from catching obvious bugs, one of the main goals of testing this application was to ensure compliance with the User Interface goals of the project. This meant testing the application for compatibility on different android devices.

Pocket Beer Reference Application for Android Mobile This application was tested on a Verizon HTC Droid Eris, Verizon HTC Droid Incredible, Sprint Samsung Epic 4G, Sprint HTC Evo 4G and Sprint Samsung Moment. In addition emulators were set up to test all versions of Android from 1.5 and up. This covers about 99.9% of Android phones currently in use as of this writing (Platform Versions Android Developers). These phones and emulators represent a variety of screen sizes within the range that the User Interface guidelines specified. resource file. If a strings.xml file is created under an Android projects res\values folder, then any String located in that file can be accessed using R.string.<name> where name is the name given to the string in the XML file. This returns an ID, which can be passed to the getResources().getString() function to get the String itself. For this project, each and every string was placed in the string.xml file, including application name, activity titles, headings, labels, database file name, database table names, database column names, URLs, HTTP request headers and regex search strings. This proved to be absolutely invaluable when database usage began to increase during development. Since all database table and column names were in resource files, supporting database refactoring only required small changes to the resource files. Those changes then rolled automatically into all files using the resources. 8.2. Thread All Data Operations Initially this application was designed using the UIs thread to perform all operations. When a View was shown, it would perform initial set up of the UI, go out and get the necessary data and then perform rendering of those data values onto the View. Initially, this worked well. However, all of the initial development used data from the database to render Views. Once development moved on to querying of web results, this design decision quickly became a problem. When a View was rendered that required web data, it would be initially shown as a blank black screen. While the data was being retrieved from the appropriate URL, the View would remain black, but it would also become impossible to press the back button since the UI thread was blocked waiting for a web response. When the data was finally received, the view would be rendered and shown as expected. However, if the user had pressed the back button during the retrieval, the View would render and then immediately go back to the previous View. The answer to this was to thread all of a Views longrunning operations. Androids built-in solution is called an AsyncTask. Extending the AsyncTask class and including all long-running operations in that Tasks doInBackground() function allows the UI thread to create an instance of that Task and execute it to ensure that all doInBackground() functions will automatically be executed on a thread separate from the UI. Additional functions on an AsyncTask allow certain operations to be performed on the UI thread specifically for
5

7.4.1. The application was tested using Android Virtual Devices for varying screen sizes. This figure shows debugging using a 10 inch tablet in the emulator.

8. LESSONS LEARNED Many lessons were learned about Android development as this project progressed. This was an introduction to Android development and a return to Java after 6 years in a Microsoft world, so the lessons were coming almost nonstop. However, some of the intricacies of development stood out more than others. This section will serve to highlight some of those important experiences. 8.1. Resources Are Your Best Friend Fortunately, the decision was made in the beginning of this project to put every string in the application in a

Pocket Beer Reference Application for Android Mobile onPreExecute(), onPostExecute() and onProgressUpdate() types of UI updates. In addition to creating AsyncTasks for each Views long-running operations, ProgressDialog objects were used to provide the user with a notification about the operations going on in the background. The result was that a View would pop up and immediately show a ProgressDialog containing a message such as Retrieving Top Examples. The progress indicator on this dialog would actively spin while operations of the AsyncTask were happening on a separate thread. When the AsyncTask completed and the View was rendered in the Tasks onPostExecute() function, the dialog would be hidden and the View would be available for user interaction. Even though this didnt change the speed with which these particular Views were loaded and rendered, it gave the application a much snappier feel, since the user had progress notification and no longer lost control of the back button during data retrieval. difficulty arose in the mapping between BJCP Competition Beer Styles and BeerAdvocates own list of styles used to categorize all commercial beers on their site. Since BJCP and BeerAdvocate use different style lists, a mapping between the two had to be created by hand. Most of these mappings were one-to-one, meaning that one BJCP Style mapped directly to one BeerAdvocate Style. However, there were cases where multiple BJCP Styles corresponded to a single BeerAdvocate Style, as well as the inverse where a single BJCP Style mapped to several more-granular styles on BeerAdvocate. For example, BeerAdvocate has a single style called Scottish Ale whereas BJCP actually splits beers of this style into three categories called 9A. Scottish Light 60/-, 9B. Scottish Heavy 70/- and 9C. Scottish Export 80/-. The inverse example would be BJCPs style 11A. Mild which corresponds to two separate styles on BeerAdvocate called English Pale Mild Ale and English Dark Mild Ale. The application would have to be designed to handle both of these unbalanced mappings. There was a separate answer for each case, since they affect different Views within the application. When multiple BJCP Styles exist for a single style on BeerAdvocate (like the Scottish Ale example above), viewing the top commercial examples for any of those three BJCP styles would present the same list of beers, since BeerAdvocate only has one style to provide ratings for. When the details for a specific beer within that BeerAdvocate style are rendered, they contain all of the possible BJCP Styles that the beer might fall under. When multiple BeerAdvocate styles exist for a single BJCP Style category (like the 11A. Mild example above) viewing the top commercial examples for that BJCP Style will actually query all of the corresponding BeerAdvocate Styles and create a roll up of those commercial examples. This requires the app to go out to the top examples page for each BeerAdvocate style, retrieve the results of each, throw all of the results into a collection, sort them by rating, and then present the resulting list to the user. For a BJCP Style such as 23A. Specialty Beer this means going out to ten separate style pages on BeerAdvocate and rolling up the results into a single list of beers. The entire operation takes only a second on a WIFI connection, and no more than 10 seconds on a slow 3G connection. That particular case is

8.2.1. Long running data operations should run on their own thread and provide the user with notifications.

8.3. Mashups Require Some Special Considerations While the end result of a mashup application is often easy to use and provides a seamless view of two or more separate sources of data, it can sometimes be tricky for a developer to get to that end result. In this project that

Pocket Beer Reference Application for Android Mobile an excellent example of how a mashup application can make a complex operation feel seamless for the user. It also shows that mashups often require consideration of edge cases by the developer to cover all possible scenarios. visibility of any of the components, attaching event handlers to the search field and search button, setting the hint text in the search field and grabbing the text entered into the search field. A single static function was created to hook up events that would occur for all instances of the view, such as showing the clear button when any text was entered into the search field, clearing the search text when the clear button was pressed and going to the BeerAdvocate home page when the BeerAdvocate logo was pressed in the footer. All existing List Views were then refactored to use this generic View. Each View was set up to show and hide components of the generic View as necessary and to hook up customized event handlers to the generic Views search components. This strategy worked beautifully once completed. When the late addition of the flavor search feature came up, it was a simple process to add its new View, since it inherited much of its functionality from the GenericSearchableListView. 8.5. Use onRetainNonConfigurationInstance() One intricacy of Android that took a bit of time to understand was the way in which Android renders Views. Any time an Activity is spawned, that Activitys View steps through its onCreate() function. This makes perfect sense. However, a View is also recreated whenever the screen is rotated and orientation is switched. This is not exactly intuitive and it presented some interesting challenges on this project. Luckily, Android provides another built-in piece of functionality to make the problem a non-issue. The problem presented by Views that re-create on screen rotate, is that the views that render their data based on web responses will have to go out and retrieve those responses each time the screen is turned. This adds data usage and battery drain that is completely unnecessary, since the web response was already retrieved and the user never even moved away from the View that displayed that data. Androids answer to this scenario is the onRetainNonConfigurationInstance() function that is part of every Activity. This function is called by the system, as part of destroying an Activity due to a configuration change, when it is known that a new instance will immediately be created for the new configuration (Activity.onRetainNonConfigurationInstance - Android Developers). The

8.3.1. When a beer falls under a BeerAdvocate Style that maps to more than one BJCP Style, all possible BJCP Styles are listed.

8.4. Generalize as Much as Possible By the time development was about halfway complete on this project, it became clear that there would be quite a few ListViews in the completed application. In the end, there turned out to be four: Search Styles, Search Beers, Search Flavors and List Top Example Beers. Ignoring the style differences of each row within these views, the structure is mostly identical. A ListView spans most of the space within the View with search controls sometimes on top and branding for BeerAdvocate sometimes on bottom. To simplify the addition of future List Views, a master view called GenericSearchableListView was created. This view contained a row of search controls with a search field, an icon for clearing the search field, and a search button. Below that row was the List View itself. Finally, attached to the bottom of the view was a row with BeerAdvocate branding (see Figure A.11 in the Appendix for a display with all of these controls in one View). A class was then created with static functions to perform actions on this generic view, such as setting

Pocket Beer Reference Application for Android Mobile function can return any object, which can then be retrieved with the getLastNonConfigurationInstance() function when the Activity is being recreated. For this project, that meant that one dying Activity was able to pass object collections, containing the data retrieved from the web, to the next lifecycle of that Activity. The new Activity was then rendered using the old data, instead of retrieving it all over again from the web. The end result is that all views in the application rotate with no delay and there are no repeated trips to retrieve data that was already collected. 9. FUTURE ENHANCEMENTS 9.1. BeerAdvocate Reviews One popular piece of BeerAdvocate that was not included in this application is the Beer Review feature. BeerAdvocate members enjoy sitting down with a beer and judging its Appearance, Aroma, Taste, Mouthfeel, Drinkability and Overall Impression. Many individual beers on BeerAdvocate have well over 2000 total reviews. These reviews are responsible for the overall score and grade for each beer, both of which are included in this application. The individual reviews provide great insight into individual opinions of specific beers. Reading them is really the only way to determine what interesting characteristics a particular beer has. One of the first future improvements to this application would be the inclusion of individual reviews. This would fit well on the Beer Details View, where reviews could be loaded into a scrollable ListView. With a dataset as large as the set of reviews on most BeerAdvocate beers, lazy loading of reviews would provide the best performance. As a user nears the end of currently loaded reviews, the application would spawn a thread to go out to the web and load more. A design like this is used in Googles own Gmail application, and it performs quite well. 9.2. BeerAdvocate Brewery Details BeerAdvocate maintains a list of breweries and associates each reviewed beer with its brewer. The breweries themselves can then be reviewed and the list of all beers that the brewery offers can be browsed. This data would be utilized to create a couple of additional enhancements. Since almost all breweries have an address, the application would be modified to grab the users current location and show breweries that are close by. The user would be able to open a given brewerys details, see available beers, and link from that list to some of the currently available actions such as beer details and associated styles. From the Browse Styles action, a function for Find Nearby Examples would allow the user to find beers of a particular BJCP style that are brewed nearby. Again, the users location would be used to find local breweries. The beer offerings of those breweries would then be scanned to find matches of the given BJCP style. This would provide the user with a quick method of finding fresh local examples of a style that he is interested in. In both of these cases, Brewery details and reviews would provide the user with some information about the brewerys food offerings and the quality of service received. This would aid in making decisions when visiting an establishment for a meal. 9.3. Caching of Web Data An important consideration when designing any web application is the amount of data that the application consumes. Many carriers are moving to tiered data plans, which require their users to keep closer tabs on the amount of data that they use during each billing cycle. While this application was designed with data usage in mind, there are some improvements that could be made to make it even more efficient. The Beer Search, Top Examples and Beer Details Views all make web requests each time the user asks them to start. The Top Examples and Beer Details could definitely be modified to cache their data. For Top Examples, the beers returned would be cached by BeerAdvocate Style ID. For Beer Details, the details would be cached by BeerAdvocate Beer ID. For both of these, the cache entries would be given an expiration date based on a configuration setting. Any time cache data exists for a requested BeerAdvocate Style or Beer, the application would bypass the web request and render the View based on the cache. If cache data exists, but the entries are expired, they will be dropped from the database and new data will be downloaded from the web. This caching would help to cut down on some unnecessary data usage, especially for Top Examples, which are likely to be shown more frequently than specific beers. 9.4. Phonetic Search Improvements Currently the phonetic features of the Flavor Search work well, and serve the purpose for which they were developed. Misspellings by the user are caught and handled using phonetic matching. However, results from

Pocket Beer Reference Application for Android Mobile that search are simply returned in the order that they come out of the database. Some improvements should be made to the Flavor Search to provide an ordering that is based on relevance of matches. For example, currently a search for harsh returns three taste matches. The first match contains the word harshness, the second contains two occurrences of the word harsh and the third contains one occurrence of the word harsh. With improvements to ordering, these results would be reordered to have the multiple exact matches appear first and the single partial match appear last. 10. CONCLUSION This project provided me with an excellent gateway into mobile development and a return to the Java programming language after years of developing C# and ASP.NET code. I thoroughly enjoyed developing for the Android platform, and I found Googles tools and APIs to be easy to work with and well architected. I have learned more in the three months that I have spent developing this application than I ever have on any other single project. I feel fortunate to have had the opportunity to learn these new skills, as I hope to have some involvement in mobile application development in my future career activities. The result of this project is an application that functions well and is architected to easily accommodate future enhancements. This new mobile application will no doubt prove to be extremely useful and attractive to homebrewers and beer connoisseurs alike. 11. REFERENCES 11.1. Published References
Speckmann, B. (2008) The Android Mobile Platform. MSCS Masters Candidacy Review Paper. Department of Computer Science, Eastern Michigan University. http://www.emich.edu/compsci/projects/Master_Thesis__Benjamin_Speckmann.pdf Knutsen, J. (2009) Web Service Clients on Mobile Android Devices. A Study on Architectural Alternatives and Client Performance. MSCS Masters Candidacy Thesis. Norwegian University of Science and Technology Department of Computer and Information Science. http://ntnu.divaportal.org/smash/get/diva2:348784/FULLTEXT01 Ableson, F. (2010) Using XML and JSON with Android, Part 1: Explore the benefits of JSON and XML in Android Applications. Technical Library. IBM DeveloperWorks. http://public.dhe.ibm.com/software/dw/xml/xandbene1/x-andbene1-pdf.pdf Burns, J. (2008) Developing Secure Mobile Applications For Android. An introduction to making secure Android applications. Technical Publication. iSEC Partners. https://isecpartners.com/files/iSEC_Securing_Android_Apps.pdf Philips, L. (2000). The double metaphone search algorithm. C/C++ Users J. 18, 6 (Jun. 2000), 38-43.

11.2. Web References

How many homebrewers are there in the United States? Talking Points. American Homebrewers Association. http://www.homebrewersassociation.org/pages/government-affairs/talkingpoints How many gallons of homebrew in 2009? Forum Topic. Homebrew Talk. http://www.homebrewtalk.com/f14/how-many-gallons-homebrew-2009-a99440/index184.html Google Search: beer http://www.google.com/search?q=beer Beer Styles. Beer Advocate. http://beeradvocate.com/beer/style BJCP Competition Beer Styles. (2008) Beer Judge Certification Program. http://www.bjcp.org/2008styles/catdex.php Palmer, J. (1999) Is My Beer Ruined? Common Off-Flavors How to Brew http://www.howtobrew.com/section4/chapter21-2.html Platform Versions Android Developers http://developer.android.com/resources/dashboard/platform-versions.html Activity.onRetainNonConfigurationInstance - Android Developers http://developer.android.com/reference/android/app/Activity.html#onRetainNo nConfigurationInstance()

Pocket Beer Reference Application for Android Mobile APPENDIX A. - USER GUIDE I. Product Installation

Figure A.3

At the security warning screen, choose Install and the application will be installed onto the device.

Figure A.1

Open the Android Market and search for Pocket Beer

Figure A.4 Figure A.2 Select the Pocket Beer Reference Application from the resulting list of selections.

A new program icon will appear in the app drawer under Pocket Beer Reference.

10

Pocket Beer Reference Application for Android Mobile II. Main Activities View

Figure A.7 Figure A.5 When the application is launched, the activities view is shown. Here, the user can choose between the applications three main functions.

Styles List View showing filtering function. Typing Stout into the search box filters styles down to only Stout Styles.

III.

Browse Styles Activity

Figure A.8

Colored boxes next to each style indicate the average color that a beer of that style will be.

Figure A.6

Choosing the Browse Styles activity brings the user to the BJCP Styles List, displaying all BJCP Style Categories.

11

Pocket Beer Reference Application for Android Mobile

Figure A.9

Choosing a particular style from the BJCP Styles List beings the user to a View showing all of that styles details.

Figure A.11 Pushing the Go to BeerAdvocate Examples button on Figure A.9 pulls the top 50 beers of the chosen style from BeerAdvocate.com and displays them in a ListView.

Figure A.10 Style details are shown in a scrolling panel with a text format that is easy to read and pleasing to the eye.

Figure A.12 When a specific beer is selected from the list, the user is presented with that beers details.

12

Pocket Beer Reference Application for Android Mobile

Figure A.13 Pressing Go to BeerAdvocate Details takes the user to the beers home page on BeerAdvocate.com.

IV.

Beer Search Activity

Figure A.15 Entering a search term (beer name, brewery name, beer characteristic) will populate search results from a Google API search. Results are filtered by the application to include only links directly to specific beers, rather than news articles or forum topics. Beer name and, when possible, brewery name are shown in the list.

Figure A.14 The initial Beer Search View presents the user with a search box prompting them to enter a beer search term. Figure A.16 When a specific beer is selected from the list, the user is presented with that beers details.

13

Pocket Beer Reference Application for Android Mobile V. Whats That Flavor? Activity

Figure A.17 Pressing Find Similar Beers on the Beer Details screen will take the user to the top examples for that style.

Figure A.19 Flavor Search initially opens with a search view populated with all 22 flavors prompting the user to enter a flavor search term.

Figure A.18 As in Figure A.13, pressing Go to BeerAdvocate Details takes the user to the beers home page on BeerAdvocate.com.

Figure A.20 As a user types a search term, the results are filtered down to flavors with characteristics that match the search term, using phonetic matching to catch spelling errors. Words that were matched in the search are bolded and underlined directly within the results.

14

Pocket Beer Reference Application for Android Mobile

Figure A.21 Another example of the phonetic search feature.

Figure A.22 Choosing a specific flavor from the search view, shows that flavors details including causes and remedies.

APPENDIX B. REQUIREMENTS

Features
Activity Navigation
1. o The application shall provide an opening navigation screen to allow the user to choose between Beer Search, Browse Styles and Flavor Search. This will provide a location for future activities to be located, such as a Brewery Search.

BJCP Style Listing

2.

The application shall provide a complete list of BJCP Beer Style Guidelines for reference and comparison. o The Style List will have a search field, allowing the user to filter the displayed styles. Style name will be searched. So, stout would filter the results down to Dry Stout, Sweet Stout, Oatmeal Stout, etc. Style category will be searched. So, 13 would filter the results down to styles 13A through 13F. o Follow latest (2008) published style guidelines located at: http://www.bjcp.org/docs/xmlstyleguide.zip o Obtain permission for usage from communication_director@bjcp.org.

15

Pocket Beer Reference Application for Android Mobile

BJCP Style Details

3.

Selecting a specific style from the BJCP Style Listing shall provide the full set of that styles details, which includes the following items: Name Category Number Style Letter Designator Original Gravity Range Low Original Gravity Range High Final Gravity Range Low Final Gravity Range High International Bittering Units Range Low International Bittering Units Range High SRM Color Range Low SRM Color Range High Alcohol By Volume Percentage Range Low Alcohol By Volume Percentage Range High Aroma Appearance Flavor Mouthfeel Impression History Comments Ingredients Examples: The few example beer names included with the BJCP style listings should be eliminated, since this applications purpose is to map styles to a live view of related beers on BeerAdvocate.com. o Each styles SRM color range should be averaged and shown in its details view. A mapping between SRM color units and HEX color values can be found here: http://www.homebrewtalk.com/f84/ebc-srm-color-rgb-78018/#post1874887 4. From a given styles Details View, a button or link shall provide the top rated beers for that particular style. o The top beers for that style will be fetched from BeerAdvocate.com using an available data connection. o The tops beers for a style should include the following information about each beer: Rank Beer Name Brewery Name 5. o o o The application shall provide a View that allows the user to search for specific beers by beer or brewery name. Using an available data connection, Google will be polled using the search term, with results isolated to pages on BeerAdvocate.com. From the Google search results, links that lead to specific beer pages on BeerAdvocate.com will be listed for the user. The listed links themselves will be displayed as beer and brewery name, rather than raw URL. From the Beer Search View, pushing the link for a search result shall take the user to a view with details about that specific beer. This action shall also be

Top Beers of BJCP Style

Beer Search

Beer Details

6.

16

Pocket Beer Reference Application for Android Mobile

o o o

accessible by choosing a beer from the Top Beers of BJCP Style shown in Requirement #4 above. The following information should be shown for the beer: Beer Name Brewery Name Brewery State (if an American beer) Brewery Country Average Rating Letter Grade Alcohol By Volume Physical image of beer BJCP Style(s) that the beer falls under The BJCP Style(s) displayed for the beer will be links that will take the user to the BJCP Style Details View for that style if pressed. A button or link on the view will take the user to the BeerAdvocate.com page for that beer if pressed. A button or link will take the user to the Top Examples that are similar to the beer being viewed. The application shall provide a View that allows the user to search for common off flavors by providing a flavor characteristic term. The search should take spelling errors into account to allow users to find characteristics despite misspelling or partially spelling their search terms.

Flavor Search

7. o

Flavor Details

8.

From the Flavor Search, pushing the link for a flavor result shall take the user to a View that provides the details of that specific off flavor. o The following information should be shown for the off flavor: Flavor / Compound Name Flavor characteristics Causes Remedies

User Experience
Color Scheme Device Compatibility Orientation Logos Third-Party Branding
9. The application shall employ a common Android theme using a black background with white and grey content text.

10. All Views should scale gracefully to any screen size that might be encountered on an Android device (anywhere from 2.8 to 10 inches diagonally). 11. All Views within the application shall be rendered correctly in portrait, square and landscape orientations. 12. The logo and branding for the application shall be custom designed by the application developer. 13. Views that contain data from third-party providers such as BeerAdvocate and the BJCP, shall contain logos and/or text descriptions crediting the owner.

17

Pocket Beer Reference Application for Android Mobile

Graphics

14. All other application graphics shall be custom designed by the application developer.

APPENDIX C. SPECIFICATIONS Part 1 Data Specifications

Database
BJCP Styles
o BJCP styles will be downloaded on the first launch of the application, parsed, and stored in a local database. This will allow the application to be used as a style reference in situations where a data connection is unavailable. BeerAdvocate styles will be downloaded on the first launch of the application, parsed, and stored in a local database. Mapping BJCP Styles to example beers will still require an internet connection. However, storing BeerAdvocate styles, which very seldom change, will cut down on the data required to retrieve from the web when example beers are requested. A mapping of BJCP Style Categories to BeerAdvocate Style Numbers will be created by hand at design time. This mapping will be downloaded on the first launch of the application and stored in a local database. This mapping will allow the application to find associated beers when given a BJCP style and, inversely, BJCP styles when given a specific beer.

BeerAdvocate Styles

BJCP to BeerAdvocate Style Mapping

o o o

Part 2 Feature Specifications

Features
Navigation
1. o o Requirement: The application shall provide an opening navigation screen to allow the user to choose between Beer Search and Browse Styles. Use graphics for each navigation option. See Twitter for Android for a good navigation screen example. Android has no Layout type that wraps contents. Therefore, showing two rows of activity icons in portrait and one row in landscape will require manual movement of activity icons when the view is created. Check the orientation and, if in landscape mode, move the second row icon to the first row. Requirement: The application shall provide a complete list of BJCP Beer Style Guidelines for reference and comparison. Parse BJCP Styles XML files on first run and move all data from the XML files into the database. Define a generic list view with search box. Can be reused for Beer Search View and Style Top Beers View.

BJCP Style Listing

2. o o

18

Pocket Beer Reference Application for Android Mobile

BJCP Style Details

3.

Requirement: Selecting a specific style from the BJCP Style Listing shall provide the full set of that styles details. o Displaying Style Color: At design time, define a table of hex color values associated with SRM integer values. After populating the Details View, retrieve the SRM Low and SRM High values. Average the Low and High values, convert to Integer and retrieve the corresponding color value from the color table. Set the background of the beer color view (graphic) to the resulting hex color. 4. o Requirement: From a given styles Details View, a button or link shall provide the top rated beers for that particular style. The view will be handed the BJCP Style ID. The BJCP-to-BA style mapping table in the database can then be used to get the associated BA style number. Using the BA Style Number, a URL to that styles top beers can be polled and scanned to generate the list of top beers. RegEx searches should be used to pull out beer names, brewery names, beer rating values, and beer urls. If only a single style page is polled from BeerAdvocate, beers will be retrieved already in ranked order. However, certain BJCP styles will actually map to multiple BA styles. In those cases, beers from all associated BA style pages should be retrieved and the result set should be sorted based on beer rating points. Requirement: The application shall provide a View that allows the user to search for specific beers by beer or brewery name. Use specific Google URL used for searching a particular sites results: http://www.google.com/search?q=<SEARCHTERM>+site:beeradvocate.com&amp;num =100 Use RegEx to pull necessary information from results. Requirement: From the Beer Search View, pushing the link for a search result shall take the user to a view with details about that specific beer. Use RegEx to pull necessary data from the beers page on BeerAdvocate. Pull image link and use secondary InputStream to download image of beer for displaying with details. Pull BeerAdvocate style number from page and map to associated BJCP Styles. Requirement: The application shall provide a View that allows the user to search for common off flavors by providing a flavor characteristic term. Populate off flavors data to database on first run of the application. Use Apache Commons implementation of Double Metaphone algorithm to encode all flavor characteristics on database population. Double Metaphone encode each search term and compare to the values in the database. Return associated off flavors for the matches.

Top Beers of BJCP Style

o o

Beer Search

5. o

Beer Details

6. o o o

Flavor Search

7. o o o

Flavor Details

8.

Requirement: From the Flavor Search, pushing the link for a flavor result shall take the user to a View that provides the details of that specific off flavor. o The following information should be shown for the off flavor: Flavor / Compound Name Flavor characteristics Causes

19

Pocket Beer Reference Application for Android Mobile

Remedies

User Experience
Color Scheme
9. o Requirement: The application shall employ a common Android theme using a black background with white and grey content text. Use XML styles file to centralize and standardize styles.

Device Compatibility

10. All Views should scale gracefully to any screen size that might be encountered on an Android device (anywhere from 2.8 to 10 inches diagonally). o ALWAYS use device independent pixels (dip or dp) for sizing objects. This is Androids primary way of ensuring identical viewing experience on different devices. 11. Requirement: All Views within the application shall be rendered correctly in portrait, square and landscape orientations. o Avoid use of AbsoluteLayout. These layouts are deprecated as they make it too easy to create discrepancies in layouts between devices. o ALWAYS use device independent pixels (dip or dp) for sizing objects. This is Androids primary way of ensuring identical viewing experience on different devices. 12. Requirement: The logo and branding for the application shall be custom designed by the application developer. o Application logo will be derived from mask used to show beer colors on Beer Details View. 13. Requirement: Views that contain data from third-party providers such as BeerAdvocate and the BJCP, shall contain logos and/or text descriptions crediting the owner. o Credit logos will be included in the GenericSearchableListView for easy application to any View. 14. Requirement: All other application graphics shall be custom designed by the application developer.

Orientation

Logos

Third-Party Branding

Graphics

20