So, as previously hinted at, I have been working on implementing “always on” interpolation (toggleable in the options menu) – which I have already managed for “this” device – and I have nearly got it sorted for all external devices too.
I’ve just been trying to make the Interface as efficient as possible, not overdoing the number of methods etc. required, but I think I’m just going to bite the bullet and make getters/setters for all the essential variables.
This will be the last “big job” I do before Gee-Oh! Mobile is ready for release. I think I will have a few business decisions to make before then (ie. dividing the business up into smaller companies – one per product – to remove confusion for potential investors etc.), but as far as technical decisions and implementations go, I’m just about done.
I also did some improvements to the map tile pre-loading application (and also to the memory management, how it’s deployed etc.) and I’m now estimating just a further 10 days before the main map tile server pre-load is complete.
Edging ever closer to getting this shit done!
The cheesy title suggests I’m starting to blossom into a caring, generous pillar of the community. Nope 😉 The actual purpose of this post is to talk about the work I’ve been doing in allowing auto-centre to be applied to external devices – not just the device the app is running on – in Gee-Oh! Mobile.
This is a pre-cursor to full integration with Gee-Oh! Server, allowing full tracking and communication between networks/groups of devices. Exciting shit.
Now let’s get into the boring technical detail…
I’ve had to literally rip the guts out of the main class, with all its references to global variables etc. and update this with getters/setters, kept in check by adding additional method references to the device interface. While I “had the bonnet up”, I did a ton of additional fixes, and it ended up being probably the biggest single commit I’d ever be comfortable making, but there you go.
Very pleased with the way it has gone, though. I even snuck in a little “loading” graphic to remove the jerkiness while we wait for interpolation to kick in.
It’s these little details that will make all the difference.
Let’s have a little recap on all the remaining tasks before release:
- Finish pre-loading server with UK data
- Confirm that all “centre on selected device” work is done for now
- Including making sure “test flight” debug mode works with replay etc.
- In actual debug mode, substitute replay or flight devices with “this” device
- Highlight selected device/waypoint, whether or not we have GPS location for “this” device
- Refactor selected waypoint logic to be the same as for selected device
- Look at implementing “always on” interpolation
- Move point pair stack into individual devices
- Each device must have its own interpolation thread running
- Must retain global control of this
- Shrink waypoints as we zoom out
- Replace current waypoints menu with proper pop-up menu
- Look at implementing “proper” double buffered rendering
- Make placenames updatable via server API
- ProGuard builds
I think that just about covers it. I’m not going to add any more features, I just need to clear this list and Gee-Oh! Mobile is getting shoved out the door.
Can’t happen soon enough.
Just a vague update on the commencement of Gee-Oh! Mobile development. Since I got the server back on track and processing squares again last week, I’ve dived right back into the world of Android.
I managed to score a few quick wins from my previous “barriers to release” list, including the rendering of placenames (fading in and out accordingly), and also added the fading out of motorway/main road labels as we zoom out to particular values.
I did a little bit of housekeeping, removing a superfluous ViewThread class that was never really being used as intended, and lots of other little bits, too many to remember fully. Been a busy boy.
My latest venture is a very large refactor to incorporate multiple devices (for now, only a replayDevice and the debug testFlightDevice) and allow auto-centering on these also whilst preserving our actual location indicator on screen. I’ll do a separate blog on this, actually – ’tis a big ol’ topic.
And so this ends.
Got round to doing a bit of re-branding this week – I have officially discontinued MakingTracksGPS and will be going forward as Gee-Oh! Mobile, which brings the Android application in line with the rest of the Gee-Oh! system.
While I’m here, I may as well summarise the remaining tasks before release:
- Pre-load all UK map data (in progress, currently ~25% complete)
- Improve sanity check for GridSquares on level above, kick-starting if required
- Kick-starting null squares (for current level and level above)
- Fix “zoom out too fast” issue, where we see background grid when we shouldn’t
- Implement ability to auto-centre on any provided device, not just device installed on
- Put Gee-Oh! button just above auto centre button
- Render placenames
- ProGuard build
- Website improvements/alterations
And that’s about it, really. Looking forward to getting v1.0 released ASAP.
I’ve just replaced GOTSLoadBalancer (a SpringBoot application) with LoadBalancerApplication, which I wrote in Node/Express and I’m very confident that I made the right decision.
Deployed live some moments ago.
I fully expect Node’s natural qualities to shine through as a load balancing application, especially since I’ve recently tried hammering Node with JMeter and it’s held up perfectly.
It will certainly handle more load than the services it is load balancing for, so that’s fair enough.
Anyway, it’s 1.32am, I’m knackered and I’ve got to go. Happy Easter.
Borne out of the need to get some kind of visual understanding of how GeeOhTileServer is performing/being used, I decided to start implementing heat map images for the various zoom levels.
Aside from indicating any potential issues (because I will be plotting errors/failures also), this will be a great help in identifying general locations of users and getting a literal picture of the overall use of MakingTracksGPS.
It will look damn pretty too 🙂
A few related tasks that I’ll be working on tonight are:
- Auto-expanding images
- Re-sizing and re-applying existing data when new data is outside bounds
- Rendering a grid or some sort of scale indicator
- Store update events for the heat maps, and apply them periodically as a batch, in synchronized code block
Watch this space!
Oh my God, finally. I’ve been chasing after a bug – on and off – for months now, and at last I cracked it today.
In the new MakingTracksGPS, there was this minor but very irritating bug where the location marker would periodically jump back a little bit during a pinch/zoom event. I tried so many fixes for this, absolutely none of which made a blind bit of difference. Until today.
I noticed that the rendering jump occurs quite reliably if you zoom in/out, then just keep your fingers still on the screen. So it wasn’t due to the actual zoom event, but rather something that wasn’t being reset until you let go.
Upon examining the ACTION_UP code block, I noticed a variable tempDisableInterpolation being set to false, so I followed its behaviour and – lo and behold – when this remains true, it results in incorrect calls to centre display on (effectively an incorrect) location.
I did a bit of refactoring, altered (ie. improved) the general behaviour of interpolated zoom, and now there is zero trace of this tacky, jumpy display error.
Now I’m down to four things on my “Barriers To Release” list:
- UniqueID DB table(s) and handling/monitoring the recording of usage stats
- Placenames rendering
- Pre-population of map tiles on GeeOhTileServer
- Need to be conscious of storage limitations
- ProGuard builds
And that will be it, I’ll be shoving the v2.0 Beta out the door ASAP.