Parsing XML with SAX

There are a few ways to parse XML. The first you maybe familiar with is the DOM parser. The DOM is a tree based structure which makes up XML's structure. You can traverse the DOM to find a tag, attribute or value you are seeking. The other method I will be talking about is SAX or Simple API for XML.

Typically the difference between DOM parsing and SAX parsing is that SAX parsing reads the file as a stream, whereas DOM parsing constructs the complete structure in memory. The advantage of SAX parsing is on mobile devices with limited memory or slow connection speeds. It's also really good at parsing very large XML files that can be gigabytes in size. A disadvantage is that you cannot traverse or backtrack. SAX parsing is also a little more complicated.

In order to setup your program to work with SAX you need to understand a little bit about event handling and a quick big picture. When the stream starts reading in data, certain handlers that you setup to are called via SAX's callback methods that look for tags, attributes and values which will be called if they match the criterium that you specified. Handlers in SAX are basically method overrides that allow you to take control over what happens. There are 3 methods you typically override in SAX, the startElement method, the endElement method and the characters method. When you instantiate your Handler class and feed it your XML stream, startElement is called. You conditionally check the tag that is passed into your method. With each tag that is passed into startElement and matched to a conditional statement, you flip boolean flags that you setup to keep track of which element was traversed.

Once startElement is finished executing (the length of one tag) the characters method is called to extract the values or attributes out of that tag. Keep in mind, these methods are called by the SAX library, not you, so you are simply catching values and flipping booleans to determine if you are in a location you want to subscribe to. Inside characters you receive a String containing the values you are looking for. Typically this looks like the startElement and endElement methods, which the exception that the string is passed to an class through public mutator method that you could name ParsedData. ParsedData would contain fields such as Title, Author, ISBN for example.

Once the tag has been passed over, the endElement is called. This method does the same as startElement with the exception that the booleans you flipped to true in startElement are now flipped to false. The next element in then streamed through and the process continues.

A Diagram Representing SAX's Possible States

In my project WattDroid (my first Android application) I've implemented SAX handlers with documentation to get you started.

Some more information is located here.

WattDroid GUI Improvements and Settings Added

Recently I talked about adding a settings feature to allow any WattDepot server to be queried for data. This has now been implemented and the settings will be saved once set. Here is a screenshot of this feature:

As you can see the top field is where you type the URL of the WattDepot server and the bottom image is what will pop up if you don't have that set when you first start the application. If the URL in invalid, meaning it does not link to a WattDepot server, then you will get an error message and it will tell you to enter the correct URL.

Beyond those necessary additions, we started to style our application to make it more visually pleasing. Here is a screenshot of a temporary placeholder image. It will change once we go over a few more designs. We have added transparency to each listview item so the background is visible.

We also added a feature where if the menu button is pressed it displays our settings panel. This is useful if the user would like to make changes to the WattDepot URL and also houses a placeholders for future settings.

We still have some pending issues to resolve. These issues are creating test cases and a continuous integration system. We also would like to add locational awareness that will be used to sort the list by closest proximity.

While Android is quite a fun framework to work with, getting to learn the libraries, like any framework, can be quite a task; so I recommend spending a lot of time read others code, it has helped me a lot.

WattDroid with Hudson and Unit Testing

Over the last few days I have been studying all the options for Android Continuous Integration and Unit Testing and well there is a plethora of choices to review.

Here are a few that I have reviewed:

Ant Related:

http://code.google.com/p/autoandroid/wiki/AndroidAnt

Hudson Related:

http://www.facebook.com/note.php?note_id=499519075367

JUnit Related:

http://mylifewithandroid.blogspot.com/2008/11/junit-in-android.html

http://marakana.com/tutorials/android/junit-test-example.html

http://code.google.com/p/robotium

What I have found is that Android requires its own unit testing libraries to perform tests that use Android libraries. Normal JUnit testing will work, however, it will not replicate actual functions the user will encounter. For example, it will test that a method returns the correct value given input, but it will not test if the user presses on a certain button and a result is shown in an Activity.

The classes that deal with specific Android testing are:

ActivityUnitTestCase and ActivityInstrumentationTestCase2

(ActivityInstrumentationTestCase is now deprecated)

The android.jar file also contains normal JUnit tests. I'm in the middle of evaluating a tool called Robotium ( http://code.google.com/p/robotium/ ) as well and it provides a simpler way to test Android applications, but this is mainly geared at the blackbox perspective, otherwise the users actions and the applications responses.

Robotium offers some interesting features and members of the Android community also say it is a valuable tool to learn. Here are a few of its features:

• You can develop powerful test cases, with minimal knowledge of the application under test.
• The framework handles multiple Android activities automatically.
• Minimal time needed to write solid test cases.
• Readability of test cases is greatly improved, compared to standard instrumentation tests.
• Test cases are more robust due to the run-time binding to GUI components.
• Blazing fast test case execution.
• Integrates smoothly with Maven or Ant to run tests as part of continuous integration.
• The Syntax is quite easy to understand as you can see in these examples.

Some others have recommended EasyMock as well. I am starting to feel all these extras are becoming a distraction and will stick to learning the standard Android test case classes and look further into Hudson CI after that.

Back to WattDroid...

Currently we are working on GPS integration and theming out application. The book we have doesn't really talk much about these two topics so we ordered a more advanced book Pro Android 2. However, in the meantime I have been trying to decipher and wad my way through some of the documentation and decent progress.

Until next time...

Remy

WattDroid Beta

The first beta of WattDroid is ready to explore. It's bare bones right now, but soon there will be a lot more functionality. Currently the WattDroid application displays information about specific sources when you select the source from a list. For those of you who are wondering, "What's a Source?" well it's just a node or sensor that contains data about anything you desire. WattDroid simply finds the list of sources and displays the XML of that source as of now. We have a lot in store for this application.

Here are some screenshots to give you a good idea:

WattDroid has a Watson Icon, taken from WattDepot.



















WattDroid's old intro screen.
















About WattDroid




















Source List


















Source Info










The next features we have planned are:

Add functionality

• Incorporate GPS (locational awareness for closest dorm)
  
• Add ability for user to specify WattDepot source URL
• Add ability for user to specify refresh interval in settings

Incorporate Android Unit Testing

• Research Android Unit Testing
• Research Integration with Hudson
• Better coding standards
  

Improve the look and feel of the application

• Needs to be more graphically enticing for the target audience (freshman, sophomores)
• Develop Killer Icon (Merge Android with Watson)
• Work with Themes
• Look into transition effects
  

Make the interface more user-friendly

• Add settings when standard menu button is pressed

Check out the project and follow the User Guide or Developer Guide Wiki to Try it out.

Android Ahoy!

After a long time wishing I had the time to develop an Android application, I finally got the chance. We are calling this app "WattDroid." The idea is quite simple, we will be pulling data from WattDepot to display energy usage data from specific dorm floors at the University of Hawaii at Manoa.

When the user launches the application he or she will see a main menu where they can enter (through the settings) a URL that the application will pull the data from. Currently this will work only with WattDepot servers. Then the user will see a list of sources to choose from (sources are dorm floors). When they choose a location, the app will display a meter reading with various other data readouts.

The idea here is to keep it intuitive and consistent with other Android applications and of course fun for the users. I see this application as a way to bypass the need for an expensive energy meter as every student can now have their own meter display for free.

So far we have read the first 5 chapters of the excellent book Android and Me (A Pragmatic Bookshelf publication) and are thoroughly enjoying working tidbits of examples into our application. Some of the difficulties we have are the networking aspect, but that should be resolved shortly after this writing. We have already been able to get a list of sources (not from the server yet) into a list that displays a Toast type message. The next step will be to create another activity (Android view) to display the updated readings.

The development cycle is quite fun as well. I simply plug my Android phone into my computer and place it into debug mode, when I hit Run in Eclipse, it sends the APK over to my Android device instead of the AVD (Android Virtual Device/ the emulator), this keeps my Macbook at a lower temperature (sometimes it can get up to 180 degree Fahrenheit).

I will post screenshots next Tuesday of this application.

Brainstorming the Next Phase

We've taken a bit of a break from working on the HEEP widgets for a little while and decided to focus our time on creative ideas for the next round of design. Kevin and I had a few brainstorming sessions over Spring break to come up with ideas that would benefit the users of the HEEP website, the people of HEEP and the students who will be using the larger aspect of the project my team is working on The UH Dorm Energy Competition.

The Dorm Energy Android Application
The idea here is to make the competitors visually see how their dorm and floor is doing compared to other dorms and floors.
Let's put this into a story/scenario:
Sally grabs her Android phone and presses the UH Dorm icon on her home screen.
She sees a layout that displays many floors of a particular dorm. She swipes the screen to change which dorm that she wants more information about. When she gets to the dorm she wants to view, she sees numbers 1-6 on a building representing the floors. She wants to find out how her friend Mark is doing on the 4th floor of Freer (a Dorm at UH). She taps the number 6 on a vertical structure that represents a building. A pretty layout with live energy consumption and a simple one week graph is displayed.

The idea here is to not push too much information on the students and allow an alternative mobile vector for the competition. We believe a simple mobile application has that potential.

A Visual Javascript Application to Display Household Energy Data
This idea is still under the works. So far our idea is to create an application that can visually demonstrate a graphical depiction of Honolulu energy usage based on household data. There are many possibilities with this and we intend to explore them when the data becomes available. Currently we are looking forward to seeing what kind of infrastructure we can obtain to house the 1TB+ of data on a SQL server that obtains fresh data nightly. I predict the model will be based on OLAP and contain highly detailed information in the form of a Google Map overlay. More to come on this exciting project.

Milestone 2

We have completed 3 of our gadgets. I'd like to share what we have so far.

First off, let me mention that these gadgets are Google Gadgets for placement of your iGoogle homepage. They report information by querying a Google Spreadsheet from javascript and then displaying the appropriate visualization or dynamic content.

Our Don’t Waste Money iGoogle Gadget displays the HEEP Rebate + Money Saved. It gives the consumer a birds eye view of how much they will earn by choosing an EnergyStar model.

When you select a certain brand, it queries the spreadsheet for the relation between the brand, rebate and savings.

Our NegaWatt iGoogle Gadget displays the amount of watts saved for certain types of appliances.

The following graph displays the HCEI (Hawaii Clean Energy Initiative) goals for the projected years. It also shows real statistics for given years that have passed.

Here are two of them together on the iGoogle Page:



There are some things we would like to continue to work on in order to perfect them. Most of these have to do with white space surrounding the visualizations and other CSS refinement.

You can search for these gadgets on Google Gadgets Search or simply visit our project page:

http://wiki.github.com/remyb/heepoverflow/