Devember - Road Trip Tracker (Android Application)

Community Blog
, ,
41

Yasss.

Are you using Android Studio?

1 Like
42

Yes, I’ve been using Android Studio for the development.

1 Like
43

Day 28 Getting high … or not

Got a few bits and pieces done today:-

  • Fixed a bug that caused the application to crash when the device was rotated (Something I introduced when working on my MapViewHostFragment helper class)

  • Did some more tweaking of the home fragment UI. I’ve added an overlay to the latest route map view for the “full screen” button (top right hand corner of the map). I also moved the button I had for opening the route detail screen but I didn’t like it so removed it again, then I decided to remove it altogether since it was too close to the new “full screen” button. You can still open the detail for the latest route by clicking the title area of the card view containing the map, but there’s no visual clue now so I need to come up with something better.

  • Added a new MapActivity to display full screen maps (Previously this was MapFragment but since I want it to be full screen without the chrome added by MainActivity it makes more sense for this to be an activity)

Road_Trip_Tracker_000_Day28_Blurred
Road_Trip_Tracker_000_Day28_Blurred.png1650×1060 362 KB

I also braved the cold weather to go out for a short cycle in order to test the code I added yesterday to track the max elevation gain and total elevation gain stats … as you can see in the 3rd screen shot … I failed … there are definitely a couple of hills on that route but the stats were not recorded correctly :thinking:

I had tested the code yesterday outside of the application and it seemed to be working ok so I checked the database to see if the data was being stored and that perhaps it was just a display issue … nope … max_elevation_gain and total_elevation_gain contained 0’s

Anyway, a bit of debugging later and the “undocumented feature” reared its ugly head. Here’s the offending line of code.

val barometricAltitude = SensorManager.getAltitude(
    SensorManager.PRESSURE_STANDARD_ATMOSPHERE, 
    currentAirPressure
)

For accurate absolute barometric altitude measure you need to specify the actual air pressure at sea level at your current location but since I am only interested in relative changes in altitude I use the PRESSURE_STANDARD_ATMOSPHERE value defined by in the Android SDK.

Seems reasonable, however, PRESSURE_STANDARD_ATMOSPHERE is defined as 1013.25f but it turns out that when the currentAirPressure (read from the devices air pressure sensor) is higher than this value, SensorManager.getAltitude() returns a negative altitude.

When I tested the code to get the barometric altitude last week the air pressure here was about 920 hPa and I was getting positive altitude readings so I just assumed that that was always going to be the case. Today it’s closer to 1020 hPa which is why I am getting negative altitudes.

The app doesn’t have a profile for Mining or Deep Sea Diving so I didn’t think about support for negative altitudes :thinking:

The fix is pretty simple though, I just take the absolute value returned from SensorManager.getAltitude() instead. As far as I know this should™️ be ok for now (unless you’re in a sub marine, but if that’s the case you really shouldn’t be relying on an Android app some stranger from the Interwebs cobbled together for #devember2k19 )

At any rate, I won’t be out on a boat until next summer so some more cycle testing tomorrow will have to do :cowboy_hat_face:

Shecks

3 Likes
44

Day 29 Running Cycling up that hill

Just a small update today.

  • Made some small changes to the RouteDetailActivity UI, to carry over the theme from the rest of the application.
  • Did a bit of code cleanup (around the stats calculations and location fix code)

I fixed the issue with the elevation gain stats calculations yesterday and managed to get out short cycle to test it.

Road_Trip_Tracker_001_Day29
Road_Trip_Tracker_001_Day29.png1370×2534 1000 KB

… and it looks like it’s working :+1:

I say a “short” cycle, it was only 3.2 miles but took 42 minutes because I got to watch what seemed like hundreds of tractors and trucks all lit up with Christmas lights driving through the town on my way home.

I didn’t know at the time, but it turned out to be a charity/memorial event for a little fella who passed away earlier in the year shortly before his 6th birthday after a brave battle with cancer. He loved tractors and Christmas lights so the local farming community got together to arrange the event and raise funds for the charities that supported him through his illness.

Life can be cruel at times but it was heartwarming to see a community come together like that and for something good to come out of such a tragedy.

Shecks

2 Likes
45

Day 30 Just a pale blue dot

  • Added code to TrackingService to emit the current location as observable LiveData
  • Added code to TrackingService to emit the running stats as observable LiveData
  • Started work on displaying the live route tracking stats on the TrackingActivity. So far I have the users current position being plotted on the map. Similar to Googles Map app the position is shown as a blue dot with a surrounding circle to indicate the accuracy radius. (I’d like to also display the direction of travel based on the location bearing but I’d like to get all the other stats displayed first)

Shecks

2 Likes
46

Day 31 This is the end…

Did a little more work on the live tracking stats today.

  • Extracted the stats panel layout in the top of the TrackingActivity into a fragment. For the moment I have a TrackingDashFragment (and a base class BaseDashFragment) which displays a generic set of stats for all profile types but this is just a bit of preparation work for future plans where I might want to have different stats displayed based on the current profile type (e.g If you’re walking or running you might want to know the elevation gain but not so much if you’re out in a boat)

  • Created a basic layout for the TrackingActivity when the device is in landscape orientation. The plan is for this layout to behave more like a dashboard where the fonts are larger and the most important stats (for the profile) are highlighted. I am still not sure if I will include access to the full screen map in landscape but for the moment I have dropped it from the layout)

Tracking in portrait mode: -

Road_Trip_Tracker_001_Day31
Road_Trip_Tracker_001_Day31.png1370×2534 865 KB

Tracking in landscape mode (still a work in progress):-

Road_Trip_Tracker_002_Day31
Road_Trip_Tracker_002_Day31.png2596×1258 724 KB

The application is usable at the moment but there’s still lots to finish, a few bugs (ones I know of anyway) and features I haven’t finished.

Some of the things still to do…

  • Display live stats while tracking is in progress
  • Allow the user to delete selected routes from the database (only selection works at the moment)
  • Allow the user to mark selected routes as favourites (again only selection works as the moment). I might even drop the favourites screen altogether and replaced it a “Most recent” list that shows the routes tracked in the last 4 weeks or so.
  • Implement the preferences screen. There will be a couple of global preferences but mainly I need to allow the user to configure the Speed, Distance, Colour and Sampling rate for each of the tracking profiles.
  • Create specific TrackingDashFragment for each profile type (e.g RunningDashFragment, BoatingDashFragment etc)
  • I’d like to add some graphs at some point (Speed, elevation etc)
  • Fix all the existing bugs, clean up the code and fix more bugs.

I’d still like to keep working on the application and try to improve the UI a bit more. At the very least I’d like to get it feature complete but so far it has served its purpose. I’ve got more demonstrable experience with Kotlin and a few more modern Android components and have another demo for my GitHub account.

Happy New Year everyone and cya all again for #devember2k20 …

Shecks

3 Likes