It’s been some fun time working on the enviroCar Android App. In this midterm blog post, I will give an overview of the achievements I’ve reached since the start of the coding phase to the work done until the start of the midterm evaluation.

Introduction

The overarching goal of the project is to improve the car selection process in the enviroCar Android app by integrating previously defined datasets of vehicles. This is app side implementation. For more information about this project, feel free to read the introductory blog post. The following blog post highlights the core tasks and achievements during the first four weeks of this project.

Setting up the database layer

The enviroCar Android app currently fetches the data from the REST API. In order to improve the car selection process, we intend to provide the local database consisting of predefined vehicles with the app. We used the powerful Android library called “Room” to implement this. The Room persistence library provides an abstraction layer on top of the built in SQLite database. It decreases the amount of boilerplate code and verification of SQL queries at compile time. The main challenge is to pre-populate the database on the app.

To get the database ready on application start, I have followed the proper workflow. This gives the flexibility to update the database in the future. In this workflow, I have imported a .csv file added in assets consisting of vehicle type and attributes. I then added Room and Room RxJava support to the enviroCar app and created a class that represents an SQLite table and defines a DAO (Database Access Object) interface consisting of a query.

The next step was to define the Room database class and most importantly add the callback to pre-populate the database. The Room database callback is circularly dependent on the Room database object. The callback uses the defined .csv reader method to insert the data imported from the .csv file into the app’s Room database. I used the Dagger dependency injection. When an object is injected in a fragment or activity in the Room database, it locates the singeltons in the dependency graph and tries to mind match the return type and provide the Room database object instance defined in database module.

During the development, I tried to stick to a test-driven development approach as much as possible. Therefore, I integrated proper unit tests for Room DAO classes and workflows, e.g. a test to initialize the database as well as a test for inserting, fetching, and deletion loops. A more technical report about the changes in the project can be found at the enviroCar wiki page and its corresponding PR (GitHub).

Integrating database with the UI

The next task is to integrate the local database created with the car selection UI. The old car selection UI consists of the manufacturer, model, year ,fuelType and engine displacement fields. The UI updates on the data fetch from the REST API. To improve the car selection process, we need to integrate a newly created database with the UI. This is acheived by replacing the REST API call with a local Room database call using Room RxJava support and updating the autocomplete text view based on database and selection by the user. We also need to map the database car fuel type onto enviroCar fuel types. In order to avoid the creation of an artificial car type, we only allows the user to select or type in values contained in the list.

We previously created and integrated the local database with the enviroCar Android app’s old UI. We now need to design a new UI to fit our selection process. The users have two possibilities to select a car type. The first is based on using the HSN/TSN of the manufacturer/model, which can usually be found in registered cars’ official documents. The second approach is based on selecting car attributes consisting of manufacture, model and construction year. To switch between different modes of car selection, I have used the segmented group that fits better to the current app and fulfils our needs.

The implementation consists of view pager and fragment created according to selection in a segmented group or simply swipe change. To accomplish the swipe change and select change fragment for car selection, I created the pager adapter. This provides the fragment to be attached according to the swipe or selection in the segmented group.

                                

                 Car selection new UI (screenshot from real device)

The first group (HSN/TSN) consists of a card with two auto-complete text views. Users can directly select the vehicle type based on HSN/TSN. HSN consists of 4 digit numbers, whereas TSN consists of 3 digit numbers or letters. Based on the selection, an overview of car attributes is dislpayed.

                           Modal bottom sheet overview selection based on HSN/TSN
(screenshot from real device)

The second group (Attributes) also consists of a card with three auto-complete text views to select a vehicle type based on the manufacturer, model and construction year. This is helpful in case the user didn’t find the HSN/TSN value of the car. After entering the appropriate information, the user sees a list of card views of vehicles in the modal bottom sheet and selects his/her car type.

       

                          Modal bottom sheet overview selection based on attributes
(screenshot from real device)

A more technical report about the changes in the project can be found at the enviroCar wiki page and its corresponding gsoc/new_UI_car_selection(GitHub)

Tasks for the next weeks

I will be working on an idea to re-implement an existing track database based on SqlBrite. Since square has been deprecated and archived in the SqlBrite repository, there will be no more support.