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 simplifying and automating the workflow of collecting driving data in order to achieve more regular contributions of users.

Another drawback of the mobile application is the implementation style and the rather outdated technologies and libraries used. This makes it hard for external developers to contribute to the enviroCar project. For this reason, another aim of the project is to update the enviroCar app to current standards of Android-related development paradigms.

The core tasks and considerations of the first four weeks of the project period can be summerized as follows:

• Migrate the enviroCar application to state-of-the-art paradigms and tools of Android-based development.
• Automatically establish a connection to simplify the required user interactions for the recording of tracks (e.g. automatically connect to a Bluetooth device once it is in communication range, automatically start the recording process.)

I will give a more detailed description on the project’s status below. A more technical description about the changes in the project can be found at the enviroCar light wiki page and its corresponding Github repository.

Migration to Android Studio + Gradle

The enviroCar application heavily relied on the Android Development Toolkit (ADT) for Eclipse. However, Google has recently announced it will cease development and support for its ADT plugin by the end of this year. The plugin is already no longer in active development. New development concepts, library-types (.aar packages), and features for Android-based development are not and may never be supported in the ADT plugin. For this reason, I migrated the project to Android Studio (including Gradle), which is considered the official IDE for Android. Android Studio offers many important and flexible technologies, such as the Gradle build environment, which, for instance, enables the management of app dependencies with maven and provides an improved user interface that is tailored for Android-based development (e.g., advanced Android code completion and refactoring).

Decoupling and Simplifying the Code

In general, as Android applications increase in complexity, ensuring an effective communication between distant parts of the application becomes increasingly difficult. To compensate these problems, the previous implementation of the enviroCar app made heavy use of static singleton classes to enable a communication with distant parts of the app. However, holding information in static singleton classes is, especially in Android-based development, a bad implementation style. These objects are not bounded to any application lifecycle, which could lead to unpredictable concurrency and contention problems.

In order to decouple the communication in the application, as well as to avoid the use of static singleton classes, I have built on the concept of dependency injection using Dagger. Dagger is a fast dependency injector for Java that enables an easy creation of reusable and interchangeable modules. The applied integration of dagger makes use of different Android-dependent scopes. When a class is initiated by Dagger, it lives in memory until its associated scope of initialization is destroyed, i.e., the application, the activity, or fragment gets garbage-collected.

The steady use of the listener pattern is hard to manage and can spiral out of control with other components. Central activity or application classes in particular always implement a lot of interfaces that can easily become an unmanageable task. For this reason, I have further integrated the event-bus system called Otto. It is designed to decouple the code of different parts of the application while allowing efficient and uncoupled communication. Different application dependent aspects (e.g. GPS location updates, Bluetooth activations) are now broadcasted over a central event bus that is injected wherever it is required.

Android Library and Design Changes

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 packages. This allows the use of the latest features for Android and the use of the new Material design introduced with Android 5.  In addition to some adjustments to the new Material design, I have furthermore adjusted and unified the layout of the application (e.g., every layout has the same toolbar with the same color). Some screenshots of the visual differences can be seen on the wiki page.

Improvements to the Usability through Automation

Not only have I made contributions affecting the enviroCar app in general, I have also started integrating some enhancements related to the usability of the app. As a first contribution, I have extended the settings section with further possibilities related to Bluetooth features. An essential feature that did not yet exist is the discovery of and pairing with other devices. Previously, someone had to use Android’s global settings to set up a pairing to the specific OBDII device. This was counter-intuitive. A user first searches the settings for the corresponding possibility of pairing. To enable this, the application makes use of the Java reflection API to invoke the corresponding pairing process that is not marked as public. All the pairings to other devices can now be managed in an additional dialog showing the discovered and paired devices.

As a second contribution to the usability of the app, I have integrated a background service, which is responsible for the (upcoming) automations. This service always gets started for system specific events, e.g., when the device has been successfully booted or when Bluetooth has been turned on. The service then periodically checks whether it is able to connect to the paired and selected OBDII adapter or not. When the adapter is in communication range, it automatically connects with the OBDII adapter and starts the recording a track. The background service only gets started when a paired Bluetooth device (i.e., OBDII adapter) has been selected as the default OBDII adapter. So far, the only things missing for the process of auto-connection are the appropriate settings in the preference fragments and some minor bug fixes according to the dashboard visualization.

As a last contribution, the service provides a proper notification in the notification bar about the current state of the app. This notification not only provides information about the current state of the service, i.e., whether it is unconnected, searching for other devices, or currently recording a track,  but also provides fast interaction possibilities with the service, for instance, starting and stopping a track, discovering the Bluetooth device, etc. This notification, however, is adaptive to the individual settings of the user. The notification will display the possibility of connecting to a device if it is in communication range only when the auto-connect is turned off.

Tasks for the next weeks

The service implemented to handle the different automation aspects for the track recording is in a very early stage right now. There are still a lot of features and cases that have to be considered and implemented. For instance, a user should be able to decide whether or not the mobile device should automatically connect to the OBDII adapter to start a track. Another important aspect is the automatic determination of start and end times of tracks.