AdvRoutes, Inc 1

“No Battle Plan survives contact with the enemy.” -Helmuth von Moltke

I’ve managed to carve out enough time to hammer out an initial version of the previously described Android App to help motorcycle route planning (dubbed AdvRoutes). From the last post I refined the requirements as I see them and created a backlog of tasks that will need to be achieved before I reach my product. Using Agile terminology, this marks the end of a Sprint. Using Defense Acquisition terms the initial product would in turn be the first Increment using Spiral Development to incrementally add features in fully functional products.

So for this first development cycle the work tasks were as follows:

  • Display an interactive Google Map
  • Implement an action bar menu in accordance with Android design principles
  • Allow the user to place markers on the map by tapping the screen
  • Define the markers in terms of route planning (0 = Origin; 1 = Destination; 2+ = Waypoints).
  • Allow the user to clear the map data by long pressing the screen
  • Provide an action bar item that, when pressed, fetches and displays a polyline route as returned by the Google Maps API
  • Display the route segment distance and duration on a bottomsheet when the segment destination markers are selected
  • Ensure that Activity interruptions (screen rotation, etc) are recovered accurately
  • Implement methods using an MVC architecture

The source code is located on GitHub. I based a lot of the early work on examples from wptrafficanalyzer.in. However, many of these samples aren’t up-to-date. Nor are they particularly production ready. After ensuring the support libraries were current, the Big issue I wanted to resolve was the implementation of AsyncLoaders to handle to Http data fetching (DirectionsDownloader) and JSON object parsing (DirectionsParserLoader). These classes are called from the main MapsActivity and run as separate threads to not interrupt the UI Thread. As opposed to AsyncTask, the AsyncLoaders are better able to handle Activity interruptions such as screen orientation changes. Additionally, placing them in separate classes makes the source code more readable and saves complications of having the AsyncTask interrupted if it is a subclass of the UI Activity.

While I managed to achieve some success in all the items. There remain bugs associated with the Activity interruptions and data clearing methods. Currently, when the screen rotates the map is recreated but any markers and plotlines are hidden. Additionally, the data fields are not being erased adequately. After some marker placing and clearing tests, eventually the application hits a critical fault and closes.

I’ve conducted static and dynamic analysis of the errors. While I believe additional code review will lead me to the errors I’ve introduced (due to the Android activity lifecycle processes) I want to use this as an opportunity to develop test routines for both unit and integration testing. For the next post I intend to discuss the implementation of JUnit testing and would like to explore using Espresso for automated integration/functional testing. 

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s