Introduction

The collection of driving data using the mobile application for enviroCar requires a number of manual user interactions. This is unpleasant and tedious over the long run and poses a major obstacle for using the app regularly. To tackle these problems, the enviroCar light project aims to enhance the usability of the enviroCar application by improving the general appearance and by simplifying the workflow of collecting driving data to achieve more user contributions.

The previous blog post discussed the work done in the first few weeks. It covered the optimization of used technologies to state-of-the-art concepts of Android-based development. This blog post, however, reflects the overall achievements gained during the project with special attention to the second half of the GSoC project. The core tasks and considerations during the GSoC period can be summarized as follows:

• Migrating the enviroCar application to state-of-the-art paradigms and tools of Android-based development.
• Decoupling and simplifying the source code to ensure extensibility.
• Simplifying the general progress of starting and stopping a track, including the auto-connection to the desired OBD adapter.
• Re-implementing and improving the user interface using novel Android Material design patterns.

The following will give a detailed description of the previous achievements in more detail. More information about the things I have changed, as well as a compiled apk of the current state can be found in the corresponding wiki page of this project.

Improvements to the Development Environments

The first achievement accomplished was the migration of the source code to Android Studio with the Gradle build automation tool. Previously, the enviroCar application depended on the Android Development Toolkit (ADT) for Eclipse, which is, according to Google’s announcement, no longer under active development. Many important technologies for Android-based development are not and may never be supported by the ADT. The official Android Studio IDE offers many important and flexible technologies, such as the Gradle build environment. This enables the management of app dependencies with maven and provides an improved user interface that is tailored for Android-based development. Previously, all the app dependencies were delivered as local project references, which is not the state-of-the-art of development.

One of the core principles I followed during the developments is extensibility. Before GSoC, the enviroCar application was tightly coupled, i.e., many classes and functionalities were highly dependent on one another. This bears some problems, since changing a single part of a class may affect many other dependent functionalities, making it very hard to handle. To counteract this tendency, I introduced the event bus technology, as well as, dependency injection during the first period of GSoC. This allows publish-subscribe style communication between different components without requiring explicit registration. For instance, app specific changes and events like OBDII state changes, new measurements, OBDII delivered speed values and setting changes are now delivered as events over a central event bus without using the nasty listener pattern. Thus, two components need not be aware of each other. Together with dependency injection, the management and extensibility of the new enviroCar application is significantly increased.

In addition to the migration to Android Studio and to the decoupling of the source code with concepts of dependency injection and event bus systems, I have further raised the targeted version of the app to Android 4.1 (API 16) and integrated the newest android-support-v7 and android design support packages. This allows the use of the latest Android features and the use of the new Material design introduced with Android 5.

Functional Improvements

The first functional improvement of the enviroCar app is the use of a background service for the collection of driving data from the OBDII adapter. The previous version also used a background service for the collection of data, but the main activity always needed to be active in the foreground. Once the application is closed, the track recording does not work anymore. In general, I have reworked the behavior of the background service, such that the app does not need to be “visible” anymore. This enables the app to be started and closed arbitrarily often without affecting the recording of the track. Previously, the app always had to be active in the foreground.

In addition to the new background service, the interaction with the track recording can now be managed by a notification in the notification bar, which is handled by another background service. This service is always initiated when some system specific event occurs, i.e., when the device has been successfully started or when Bluetooth gets activated. This notification shows the current state of the tracking process (i.e., it is unconnected, connecting, or started) and provides quick and uncomplicated interactions to the user (i.e., start Bluetooth discovery, start track, stop track) without starting the app itself.

This background service is also able to periodically check whether a selected OBDII adapter is in its transmission and, if so, it is able to automatically connect in order to start a new track. This behavior, however, depends on the individual user settings. It only auto connects to the OBDII adapter when the corresponding setting in the settings section has been turned on.

Aside from these functional improvements, I have also fixed a lot of the bugs in the previous enviroCar version. I will not going into detail here, because this is far too technical and requires a general understanding of the system. To get an overview of all the changes that happened during the GSoC project, please refer the to the wiki page of this project.

Rework of the User Interface

In addition to the functional enhancements and improvements related to the user interaction of the app, I made some changes related to the user interface. I always tried to follow the Material design standards of Android 5 as a design guideline for the application.

The first thing I completely redesigned is the general dashboard. The dashboard fragment is now a compound fragment consisting of a complete new cruise control view, a live map that shows the driven track, and a header fragment that shows some current track details (e.g. the distance, the elapsed time, the Bluetooth and GPS state, and the average speed). The view that renders the speed is a quite generic implementation and can be easily extended to show other attributes of interest. All these views are only visible when the track recording is in progress. When no track recording is in progress, the dashboard displays a startup view, where a user can make the most important settings related to the recording of a track (e.g. selecting the car/OBDII adapter).

The list representation of tracks is another aspect of the enviroCar application I redesigned. Previously, the list representation was only shown when the data of each track stored in the database had been completely loaded by the app. This is not the optimal solution, especially when the number of tracks stored in the local database is large. For this reason, I redesigned the existing list view and used newer Android-based technologies that are better suited for the representation of tracks. Instead of using a standardListView of items, I used the advanced version of a RecyclerView combined with the CardView widget. Each track is now represented by a card that shows some of the most important characteristics, such as a rendered map representation. By using these technologies, large and CPU intensive data sets can be scrolled efficiently by only maintaining a limited number of visible track items. This significantly decreases the amount of information (e.g., distance, duration, fuel consumption) that needs to be computed.

In order to show the details of a track, the previous enviroCar version made use of expandable listview items. However, this is quite counter-intuitive and contradicts the design guidelines provided by Google. For this reason, I have outsourced the details of a track to another activity that shows not only the most important statistics, but also the track itself in a map representation. The previous version of enviroCar used Mapsforge for the map representation of a track. This library is quite outdated as the dynamic tile services are not part of the actual Mapsforge library anymore. For this reason, I integrated the MapBox SDK for the map representations of a track.

Summary

In general, the enviroCar project is a quite interesting and nice project that has a great potential and is a perfect playground for the Google Summer of Code. However, while the server part of the enviroCar architecture meets all the needs, there is still much room for improvements in the mobile application.

Concerning my goals, I was able to achieve most of the goals of and some goals beyond the initial project description. Further automation of the app (i.e. dynamic track finishing) has not been targeted, because of the OBDII circumstances in my car. The OBDII adapter in my car seems to be active even when the car is not started. This seems to be another difficulty that the application has to consider for further automations in the future.

A major obstacle in the project was the tightly coupled code in some parts of the app and the lack of some documentation in the code. This made it hard to dig into the code and was the reason for the many re-implementations. But my mentors were very helpful and spent considerable time giving help and directions for further developments. Thanks for this!

Overall it was a nice experience and I had the time to deepen my knowledge in Android-based development, especially in state-of-the-art Android programming.